CC BY
36
Анализ современного состояния и подходов к разработке бортовых комплексов
управления
Л.А. Чижикова
Аннотация— Современные бортовые комплексы управления разрабатываются, как правило на принципах взаимозаменяемости модулей как программных, так и аппаратных -интегрированной модульной авионики. Как правило, математическое моделирование, симуляция аэродинамики полета ЛА выполняется на начальных этапах ЖЦ. Данная работа является обзорной современного состояния и подходов к разработке БКУ. Рассматриваются западные и российские подходы к созданию БКУ. В работе предложен подход к описанию данных и интерфейсов БКУ, как частично решающий проблему комплексного подхода к проектированию БКУ. В настоящее время выбор конструктивных решений и аппаратной части для автоматизации управления предшествует информационно-логическому управлению и проектированию БКУ. Несмотря на новаторские решения в области аппаратной части и модульного подхода к разработке программно-алгоритмического
обеспечения, авиационные и космические катастрофы происходят из-за неправильно работающего комплекса систем управления ЛА, как показывает статистика. В работе показаны основные аспекты потребности проектирования и разработки БКУ, начиная с логического и информационного составляющих систем
управления. Данная работа имеет аналитико-обзорный характер современных подходов к разработке БКУ, как результат предоставляющий читателю способ организации данных потоков информации БКУ
Ключевые слова— бортовые комплексы управления, системный анализ, авионика
Статья получена 11 июня 2021. Работа подготовлена как часть диссертационной работы аспиранта каф. 604 МАИ Л.А. Чижикова, ведущий инженер-программист, АО НПО Лавочкина, аспирант Московского Авиационного института
(email: ludmilachizhikova@yahoo.com)
I. Введение
С точки зрения системного анализа бортовые комплексы управления (БКУ) являются сложной искусственной системой, состоящей из взаимосвязанных элементов [1].
Бортовые комплексы управления базируются на синтезе основ теории автоматического управления, положенной в основу функционирования и взаимодействия программно-аппаратных частей всего комплекса. В данной статье представлен обзор современных подходов к разработке БКУ ЛА, а также его ПО, даны рекомендации по систематизации данных для отслеживания корректности обмена потоками данными и как этап к усовершенствованию походов к разработке ПО БКУ ЛА*.
Данная статья дает критический анализ и оценку современных научных достижений, генерированию новых идей при решении исследовательских и практических задач, в том числе в междисциплинарных областях.
Источники для исследования использовались вторичные, также был учтен собственный опыт автора. Результаты исследований для данной статьи были получены с использованием современных информационно-коммуникационных технологий
Данная работа имеет аналитико-обзорный характер современных подходов к разработке БКУ, как результат, предоставляющий читателю способ организации данных потоков информации БКУ.
II. ОСНОВНАЯ ЧАСТЬ
Наблюдается все более возрастающая потребность в создании и совершенствовании автоматического пилотирования и управления. Предполагалось, что разработка таких систем снижает стоимость обслуживания всего комплекса: система проверки и управления обеспечивает автономную работу экипажа и обеспечит низкую стоимость технического обслуживания и ремонта. Специалист НАСА Мюллер описал основу для такой системы в мае 1969 года на брифинге для подрядчиков шаттла. Он рассказал о массиве датчиков и бортовых компьютеров, которые могли бы диагностировать состояния двигателей и других подсистем шаттла, возвращая такие сообщения,
как «Я в порядке» или «я иду на посадку» «здоров» или «я скоро сломаюсь» [14]
В настоящее время системы управления разрабатываются с учетом целевой решаемой задачи ЛА, путем определения режимов работы и функций ЛА, но нет полного взаимодействия и учета специфики разрабатываемого ЛА на всех этапах разработки в комплексном подходе. При рассмотрении задания создания системы управления БПЛА и его программно -алгоритмического обеспечения, решаются задачи построения заданных маршрутов и формирования управляющих воздействий для тяговых двигателей с
важной задачей для точного определения дальности и выносливости миссии. Как обычно в процессе проектирования любого летательного аппарата, инерционные и аэродинамические свойства аппарата играют роль в балансе сил и моментов во время динамики полета. Но настоящей проблемой является оценка вторичных факторов, которые влияют на точность анализа характеристик, т.е. пропеллера, электродвигателя и аккумуляторной батареи [11].
Унификация в подходах сейчас наблюдается только со стороны добавления специфики к уже существующим методологиям разработки [12].
[ifion ii7NpM*q I hl ■
Процессы определений требсаажН ]. Оп эдздле - фуницчечМехык. не^ЧчсциОмЫъыых тре&абЛыкн Ï. Определение тезипыческик ppiifcfmW-i Опии» Бз^г'К'.одей flint
Првч»«к<- опрцшннчи тшничкнш реилвмнЕ ■!, АтмсникАишкпчИ' 4, Определит прмнтнегв 1__рЦфд*_
Процесс таи. _____
г Процесс«
PIIIMUHHH
^^ Нрсщукп
10, ТО 4t4«4Û* П
Прсцасс п L релодл
продух"
3. Период пред*»"
ttniHVntlD ноигрилг
11. M Е ^¿укмент tpetiüaäHHÜ
13. «хмичикия аистам Процессы оценки
14. М?ИЦДЖЯМ1ЧТ piL^lrf
15. ihVh^iAïift'.n io> ■'KHfcv rix e ii Ö-
ствие Верфи** лраду™
Ii, eqtHU
Првцкгы ре&л-цнцын л рмНПф<МП*М
ij. ИЧТ^пичра flpoAW* Ь. РнЛийцт ПрОфкИ
flpc^c« лнллн» принятии рвшснин
17. АНЛЛИ! рвИ1»ЧНЙ
Рис. 1. Процессы разработки
учетом формы и размеров исследуемых участков, рельефа местности, внешних возмущений и динамики используемого БПЛА. В большинстве случаев такие задачи решаются посредством структурного синтеза, где процесс создания заключается в определении набора элементов - режимов и функции, влияющих на выбор программно-алгоритмической и аппаратной частей. Таким примером могут служить работы [10]
Продолжая анализ создания бортовых комплексов управления для БПЛА, следует отметить, что основной проблемой для разработчика этих легких автономных транспортных средств является очень ограниченный доступный энергетический бюджет. Поэтому оценка потерь на управление и контроль с помощью моделирования, т.е. прогнозирование мощности, затрачиваемой на подъем и ускорение во время фаз автономного полета, является жизненно
В целом, процессы разработки можно представить, как описано в [13]. На рисунке 1 мы можем видеть три группы процессов разработки:
1. Процессы системного проектирования Четыре процесса проектирования системы складываются из определения генерирования и определения базовых технических требований, разложения требований на логические и поведенческие модели и преобразования технических требований в проектное решение, которое будет удовлетворять базовым ожиданиям заинтересованных сторон. Эти процессы применяются как к системе в целом, так и к каждому блоку (подсистеме)
2. Менеджмент технических процессов
Данные процессы используются для планирования разработки системы, управления взаимодействием подсистем и интерфейсов. Данные процессы предназначены для контроля технического исполнения проекта до его завершения, а также для помощи в процессе принятия решений.
3. Процессы реализации продуктов
Процессы реализации продукции применяются к каждому продукту структуры системы, начиная с продукта самого низкого уровня и до интегрированных продуктов более высокого уровня. Эти процессы используются для создания проектного решения для каждого продукта (путем покупки, кодирования, создания или повторного использования) и для проверки, утверждения и перехода на следующий иерархический уровень тех продуктов, которые удовлетворяют своим проектным решениям и соответствуют ожиданиям заинтересованных сторон в качестве функции применимой фазы жизненного цикла.
Рассмотрим несколько зарубежных примеров разработки БКУ ЛА.
На примере всемирно известного центра НАСА мы можем увидеть, что за два года был создан БКУ MUSTANG. Данная технология, применяемая при разработки БКУ , название которой сокращенно от Modular Unified Space Technology Avionics for Next Generation (Модульная Унифицированная Технология Космической Авионики для Следующего Поколения), действует как мозг и центральная нервная система миссии, управляя всеми функциями, необходимыми для сбора научных данных с миссий типа Маленький исследователь (Small Explorer). Сюда входит все - от командования космическим аппаратом и обработки данных до управления положением, мощностью и движением, и это лишь некоторые из задач. Команда также разработала вариант системы - iMUSTANG - для электроники приборов и, как и ее брат, она позволяет пользователям выбирать различные возможности в зависимости от потребностей прибора. Как сообщает официальный источник НАСА[2] , "Ключом к успеху MUSTANG стала интеграция аппаратного и программного обеспечения, - сказал заместитель директора Управления прикладного проектирования и технологий Годдарда и бывший руководитель проекта MMS Крейг Тули, который возглавил эту работу. "Она обеспечивает максимальную производительность обработки и отличается высокой гибкостью".
Согласно официально известным открытым данным, вычислители модульной авионики MUSTANG имеют следующие характеристики:
Processor: GR740, Quad Core LEON4 SPARC V8 Processor and 250MHz-Rev 1 • FPGA: RTG4 •SUROM 64KB •SDRAM 256MB(+128MB FEC) • DDR2 4GB(+2GB FEC) • MRAM 2X16MB • Oscillator QT194(50MHz)+QT2020 •Peripherals: - SpaceWires: 20(8 GR740,12 RTG4) - 1553B: 1(1 GR740) - RS422: 16 TX and 16RX - UART: 3 (2 GR740,1 RTG4) - Debug ports:
SPW Debug port and RTG4 JTAG
Другой зарубежный пример разработки БКУ, являясь новатором и ведущим поставщиком передовых авионических систем, компания Honeywell предлагает своим заказчикам из аэрокосмической отрасли проверенные технологии, услуги по проектированию и интеграции. Группа Avionics компании Honeywell в настоящее время предоставляет свой многолетний опыт работы, как в наземной авиации, так и в пилотируемых космических полетах, чтобы продолжить проверенную революцию интегрированной модульной авионики или "Ориона" и будущих космических исследований НАСА. Снижение риска по мере того, как летные системы со временем становятся более зрелыми, они также усложняются, при этом перед многочисленными конкурирующими системами ставится все более широкий круг задач. В процессе эволюции бортовых систем Honeywell создал комплекс интегрированной модульной авионинки - БКУ. Подход к разработке БКУ с технологией модульности дает возможность масштабируемости системы, гибкость замены аппаратных компонентов, соединённые между собой с интеллектуальным программным обеспечением. Такая замена бортовых компонентов не затрагивает работоспособность всей системы БКУ
Как сообщает разработчик, эффективность такой архитектуры БКУ приводит к значительному сокращению сроков разработки и снижению затрат.
Вся доступная для вычислительных задач память отображается в реальном времени в средствах разработки ПО БКУ, модификации являются простыми и надежными, что устраняет необходимость переделывать целые сборки, когда обновляются только дискретные функции. Для ускорения кодирования и отладки БКУ, решение на модульной авионике включает полный набор скоординированных инструментов системного уровня. Интегрированная модульная авионика "Орион" от компании Honeywell является кульминацией научно-исследовательских и опытно-конструкторских работ на сумму более миллиарда долларов, с приложениями от ракет-носителей до мониторинга и управления системами, включая автономные робототехнические операции. Такое решение от Honeywell применяется на 70% всех Американских космических кораблях. Внедрение интегрированной модульной авионики на 777ER позволило:
- 20% снизить затраты на разработку ПО
- 50% снизить затраты на жизненный цикл программного обеспечения
- 50% снизить SWaP
Honeywell's Orion Avionics включают в себя:
- Компьютер для управления транспортными средствами (VMC)
- Инерциальная единица измерения Ориона (OIMU)
- Баро-высотомер (BALT)
- Ручные контроллеры
- Система изоляции дисплея
- GPS-приемник (GPSR)
- основное навигационное судно Ориона
- Дисплейные блоки
- Детерминистическая сеть Ethernet с временным интервалом (сеть TT-GbE)
Известно, что в западных космических исследованиях и созданиях КА также используется модульная авионика и такие авиационные стандарты как ARINC 653, стандарты к критическим по отказам систем DO-178 и пр. [3] . В рамках программы «Созвездие» США создало многоцелевой КА в середине 2000гг, БКУ которого использовало технологию модульной авионики В российских примерах разработки БКУ мы также видим преобладание модульной авионики. Как отмечают исследователи, [4] «перспективным направлением развития комплексов бортового оборудования (КБО) воздушных судов (ВС) является концепция интегрированной модульной авионики (ИМА). На этом принципе построены бортовые комплексы современных самолетов Boeing 787, Airbus А380, Sukhoi Superjet100, F-35, Т-50, МиГ-35» Как отмечают российские исследователи [5], большинство БКУ стараются разработать также по принципу модульной авионики
С другой стороны, несмотря на достижения современных подходов к разработке БКУ ЛА мы можем видеть неутешительную статистику, связанную с отказом в работе ПО БКУ:
Например, Boeing перепроверит все программное обеспечение на своем корабле коммерческого экипажа Звездного лайнера CST-100 после того, как в ходе ведущегося расследования были обнаружены "многочисленные" проблемы в процессе первоначальной разработки.
Программное обеспечение играет центральную роль в БКУ, автоматизации всего ЛА, а также, согласно статистике [6], играет все большую роль в авиационных инцидентах и авариях. Как отмечают исследователи [6], ошибки, связанные с программным обеспечением, имеют отличительные механизмы отказа, и их вклад в последовательность авиационных происшествий не понимается должным образом или не фиксируется традиционными методами анализа рисков. Тематические исследования также выявляют критическую роль дефектных входов датчиков в качестве ключевого определяющего фактора или триггера "спящих" дефектов программного обеспечения. В некоторых случаях мы обнаруживаем, что особенности программного обеспечения, созданные для устранения определенных рисков при номинальных условиях эксплуатации, являются теми, которые приводят или способствуют возникновению аварий в не номинальных или необдуманных условиях. Примеры из практики также показывают, что программное обеспечение может соответствовать требованиям, но при этом подвергает воздушное судно опасности или способствует возникновению неблагоприятного события.
Российские исследователи [7] предложили математическое решение задачи проектирования БКУ КА при формировании режима работы КА. Такое математическое описание проектирования работы КА «показало возможность формализованного
представления информации, используемой в процессе
проектирования, в виде компьютерных математических моделей»
Как мы видим из примеров аппаратной архитектуры БКУ, каналы связи и передачи информации разные, при этом потоки информации, как правило, регламентируются стандартом ARINC 653. Как отмечают исследователи [8], проблемы при разделении на программные блоки для обработки информации в БКУ возникают на двух уровнях: внутри одного процессора и в распределенной системе Проблемы разбиения на модули также взаимодействуют с проблемами отказоустойчивости. Как было сказано ранее, основным стандартом, который в отечественных разработках БКУ ЛА и КА применяется редко, является ARINC 653.
Общая идея разделения заключается в том, что данные из одного раздела можно записать в другой. При этом память вычислителя может быть визуализирована как одномерна либо двумерная сетка. В операционной системе ядро распределяет выполнение процессов следующим образом: программное обеспечение в одном разделе выполняется некоторое время, затем другому разделу передается управление и т.д.; когда один раздел приостанавливается, а другой запускается, ядро ОС сначала сохраняет содержимое регистров разделов в ячейках памяти, выделенных под приостанавливаемый раздел, а затем, перезагружает регистры со значениями, сохраненными для раздела, который выполняется следующим.
Еще одним способом разделения и структурирования программного обеспечения БКУ является программная изоляция неисправностей (англ. SFI - Software Fault Isolation). С помощью сложного статистического анализа или методов верификации программы можно минимизировать количество проверок во время выполнения. По данным [8] при оптимизациях такого рода расходы на время выполнения SFI-проверки составили всего 4% (от общего бюджета времени на выполнение вычислительных операций). При применении способа разделения (partition) очевидным решением задачи передачи данных от одного раздела в другой является копирование его данных в буфер памяти, принадлежавший первому разделу в отдельный буфер памяти второго раздела. Так как ядро ОС вычислителя БКУ имеет доступ к памяти обоих разделов, оно должно выполнить копирование и ядро также проверит, переполнен ли буфер, так как копирование происходит, как правило, без защиты памяти. Более эффективной реализацией технологии разделения ARINC 653 является один буфер памяти. Разделы памяти находятся среди тех, в которые может записать посылающий раздел, а получатель может его прочитать. Затем данные могут быть скопированы в общий буфер посылающим данные разделом без активного участия ядра - управляющего программного модуля БКУ. Принимающий же раздел должен предполагать, что посылающий может записывать произвольные данные где угодно в свои общие буферы всякий раз, когда у него есть контроль, и его проверка должна производиться в соответствии с этим предположением. Наиболее чистым кажется использование отдельных буферов для каждого направления передачи, но двунаправленные буферы
также могут быть приемлемы. Однако, важно, чтобы для каждой пары разделов использовались отдельные буферы (в противном случае, раздел A может перезаписать данные B в единственном входном буфере
C).
Данное описание актуальной технологии подчеркивает необходимость оценки информации и потоков данных БКУ при разработке. Данная работа направлена на снижение неопределенности объема потоков данных, прогнозирования загрузки вычислителей при обработке информации БКУ.
Опять же, даже при применении способа разделения -стандарта ARINC 653 проблема отказоустойчивости решена не до конца.
Как было отмечено в сообщении о проблемах программного обеспечения на борту Звездного лайнера CST-100 (Boeing) , НАСА отмечает, что проблема кроется в полностью подходах к разработке. Цитируя источник, [9], две проблемы с программным обеспечением - признаки более фундаментальной проблемы. "Реальная проблема заключается в том, что у нас было множество запусков в цикле проектирования, разработки и тестирования программного обеспечения", - сказал Дуг Ловерро (Doug Loverro), помощник администратора НАСА по исследованиям и операциям с человеком. "По мере того, как мы будем двигаться вперед, это то, на чем мы собираемся сконцентрироваться". Программное обеспечение, говорит Малхолланд, должно пройти "довольно стандартный" процесс разработки, в ходе которого код будет написан и пройдет экспертную оценку, а также серию тестов, которые приведут к формальным квалификационным тестам. "На этом пути существует ряд проверок, призванных выявить и исправить ошибки в коде как можно раньше", - сказал он.
Тем не менее, в этом процессе были обнаружены "поломки в нескольких областях", которые были обнаружены независимой группой по рецензированию, сказал Ловерро. "Для каждой из этих двух проблем, о которых мы знаем, некоторые из них были в разных местах, а некоторые - на одном и том же месте процесса".
III. ЗАКЛЮЧЕНИЕ
Анализ показал, что, в общем виде, применяемые технологии разработки БКУ требуют модификации и совершенствования. В настоящее время нет однозначных алгоритмов выбора каналов связи и комплексных алгоритмов и критериев разработки архитектуры программно-алгоритмического
обеспечения сложных технических систем. Анализируя современные подходы к разработке БКУ можно сделать следующие выводы:
Как программно-алгоритмическая, так и аппаратная части БКУ выполняются на основе модулей для лучшей интеграции и взаимозаменяемости. Рассмотренные же результаты исследований и, прежде всего проблематику статистики происшествий из-за некорректно работающего ПО БКУ, подтверждают мою гипотезу о необходимости структуризации
информационного обмена между модулями, управление и контроль интерфейсов всех уровней - как между программными модулями БКУ, так и между физическими модулями БКУ ЛА.
С точки зрения системного анализа из рассмотренных примеров БКУ, построенных на технологии модульной авионики мы видим, что задача разработки операционной модели может быть несколько упрощена, поскольку для правильного представления БКУ, модели его построения мы можем уже выбрали модульную технологию как для аппаратной части БКУ, так и для программно-алгоритмической.
Операционная же модель БКУ должна быть построена, прежде всего, опираясь на законы управления и теорию информации, так как в современных БКУ используется цифровой обмен информацией.
В заключение отметим, в комплексном, системном подходе при использовании подхода модульной авионики, на основе которой разрабатываются современные БКУ ЛА необходимо четкое распределение потоков информации - интерфейсов, как между программными модулями, так и между аппаратными блоками.
Функциями системной инженерии, входящими в состав программного обеспечения, являются разработка требований, верификация системы и интеграция и управление системной инженерией. Для программного обеспечения, системного анализа и проектирования поддерживается только разработка системных требований, конфигурация системы включает в себя разработку программного обеспечения.
Важность управления интерфейсами обусловлена следующими аспектами:
- Сложные системы имеют множество интерфейсов
- Общие интерфейсы снижают сложность
системы
- Системная архитектура управляет типами интерфейсов, которые будут использоваться в процессе проектирования
- Четкая идентификация и определение интерфейсов снижает риск некачественной разработки ввиду понимания дальнейшей верификации и интеграции в систему
- Большинство проблем в системах находится в интерфейсах и проверка всех интерфейсов имеет решающее значение для обеспечения совместимости и эксплуатации.
Рассматриваемая проблематика вызывает
необходимость исследования путей совершенствования протоколов информационно-логического
взаимодействия.
Для прогнозирования объема потоков информации, циркулирующих в БКУ необходимо корректно структурировать и описать все интерфейсы взаимодействующих модулей - подсистем: определение каждого интерфейса должно включать предоставляемую услугу - передачу данных, прием, ретрансляцию и др., описание - название, стандарт передачи данных, каналов связи, тип, размер, диапазон и начальное значение. Должны быть описаны следующие интерфейсы:
1. интерфейсы между программным элементом и другими программными элементами;
2. интерфейсы между программным продуктом и аппаратными средствами;
3. требования к интерфейсам, связанные с взаимодействием человека и машины.
4. Должна быть также описана конвенция об именах, применимая к интерфейсу данных и команд. Предлагается при описании данных использовать следующую матрицу данных:
Структура и описание информационно-логического взаимодействия должно создаваться на этапе теоретического решения задачи создания БКУ -математического моделирования с учетом требуемых функций и режимов работы ЛА:
Таблица 2Обмена данными
На следующих этапах создания БКУ следует учитывать такое описание информационно-логического взаимодействия.
При этом, на этапе проектирования БКУ предлагается изначально оценивать объем потоков информации исходя из требуемой функциональности подсистем, и с учетом этого выбирать конкретные аппаратно-конструктивные решения. Предложенный подход дает возможность сделать шаг к оценке объема данных в БКУ ЛА. В следующей работе будет оценен объем потоков информации на примере подсистем БКУ.
Библиография
[1] Основы синтеза систем летательных аппаратов: Учеб.пособие для студентов ВТУЗов/ А.А. Лебедев, В.Н. Баранов, В.Т. Бобронников и др. Под ред. А.А. Лебедева - Москва , Машиностроение, 1987
[2] Brains of the Operation - NASA Team Develops Modular Avionics Systems for Small Missions Feb 23, 2017,
https://www.nasa.gov/feature/goddard/2017/brains-of-the-operation-nasa-team-develops-modular-avionics-systems-for-small-missions дата обращения 25.03.2021
[3] Orion's Command and Data Handling Architecture George Eger Published Online: 15 Jun 2012 https://doi.org/10.2514Z6.2008-7743 дата обращения 23.03.2021
[4] Е. Федосов, В. Косьянчук, Н. Сельвесюк Интегрированная модульная авионика 1/2015 Радиоэлектронные технологии http://tlib.gosniias.ru/pages/d/ret-01-2015_1.pdf дата обращения 23.03.2021
[5] Поляков В.Б., Неретин Е.С. , Иванов А.С. , Будков А.С. , Дяченко С.А., Дудкин СО Труды МАИ. Выпуск № 100 http://trudymai.ru/ Архитектура перспективных комплексов управления бортовым оборудованием
[6] Francesca M.Favaro David W.Jackson Joseph H. Saleh Dimitri N. Mavris Software contributions to aircraft adverse events: Case studies and analyses of recurrent accident patterns and failure mechanisms Reliability Engineering & System Safety Volume 113, May 2013, Pages 131-142
[7] А. А. Калентьев, Ю. М. Сыгуров Разработка информационной поддержки процесса проектирования управляющих алгоритмов бортовых комплексов управления космических аппаратов, Вестник Самарского государственного аэрокосмического университета № 1 (21) 2010 г
[8] DOT/FAA/AR-99/58 Office of Aviation Research Washington, D.C. 20591 NASA/CR-1999-209347 Langley Research Center Hampton, VA 23681-2199 U.S. Department of Transportation Federal Aviation Administration Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance March 2000 Final Report
[9] Jeff Foust Starliner investigation finds numerous problems in Boeing software development process, February 7, 2020 https://spacenews.com/starliner-investigation-finds-numerous-problems-in-boeing-software-development-process/ дата обращения 25.03.2021
[10] Kotov, K. Y., Mal'tsev, A. S., Nesterov, A. A., and Yan, A. P., "Algorithms and Architecture of the Multirotor Aircraft Trajectory Motion Control System", Optoelectronics, Instrumentation and Data Processing, vol. 56, no. 3, pp. 228-235, 2020. doi: 10.3103/S8756699020030085
[11] G. Guglieri Effect of autopilot modes on flight performances of electric mini-UAVs, The aeronautical journal, January, 2013 Vol.117 #1187
[12] K. Wortman, B. Duncan and E. Melin, "Agile methodology for spacecraft ground software development: A cultural shift," 2017 IEEE Aerospace
Таблица 1 Описание параметров
а «
н
о «
о fr «
° §
ït S S
S
<D «
и
л ч
<D g
ч о
X
m
<D
& а
а &
(D
& а
(D
S
о S
а О
а о
S
s -е s
s
S
л «
л н о
H о л F
я
(D
ÎP
<D
S
M
S
3 я F <D
s
ч £
w a
л и
ч H
s s я
л
s а о -е и s
о «
■
ч о Ы
Выходные данные Входные данные
Название параметра Единицы измерения/ значение Тип данных Объем данных Название параметра Единицы измерения/ значение Цена младшего Тип данных Объем данных
Conference, 2017, pp. 1-8, doi: 10.1109/AERO.2017.7943886
[13] SR Hirshorn, LD Voss, LK Bromley NASA systems engineering handbook Rev2 2017
[14] T.A. Heppenheimer The Space Shuttle Decision NASAs Search for a Reusable Space Vehicle
NASA SP-4221, Washington, 1999
Analysis of the current state and approaches to the development of on-board control systems
L. Chizhikova
Abstract - Modern onboard control systems are developed, as a rule, based on the principles of interchangeability of modules, both software and hardware - integrated modular avionics. As a rule, mathematical modeling, simulation of aircraft flight aerodynamics is performed at the initial stages of lifecycle. This work is a review of the current state and approaches to the development of OCSs. Western and Russian approaches to OCS development are considered. The paper proposes an approach to the description of data and interfaces of OCSs, partially solving the problem of a comprehensive approach to the design of OCSs. Currently, the choice of design solutions and hardware for control automation precedes the information-logical control and design of OCSs. Despite innovative hardware solutions and modular approach to software and algorithmic design, aircraft and space accidents occur due to improperly functioning complex aircraft control systems, as statistics show. The paper shows the main aspects of OCS design and development needs, starting from logical and information components of control systems. This paper has an analytical and review character of modern approaches to the development of BCUs, as a result providing the reader with a way to organize data flows of information BCUs
Key words - onboard control systems, system analysis, avionics
REFERENCES
[1] Osnovy sinteza sistem letatel'nyh apparatov: Ucheb.posobie dlja studentov VTUZov/ A.A. Lebedev, V.N. Baranov, V.T. Bobronnikov i dr. Pod red. A.A. Lebedeva - Moskva , Mashinostroenie, 1987
[2] Brains of the Operation - NASA Team Develops Modular Avionics Systems for Small Missions Feb 23, 2017,https://www.nasa.gov/feature/goddard/2017/brains -of-the-operation-nasa-team-develops-modular-avionics-systems-for-small-missions reference date 25.03.2021
[3] Orion's Command and Data Handling Architecture George Eger Published Online: 15 Jun 2012 https://doi.org/10.2514Z6.2008-7743 reference date 23.03.2021
[4] E. Fedosov , V. Kos'janchuk , N. Sel'vesjuk Integrirovannaja modul'naja avionika 1/2015 Radiojelektronnye tehnologii http://tlib.gosniias.ru/pages/d/ret-01-2015_1.pdf reference date 23.03.2021
[5] Poljakov V.B., Neretin E.S. , Ivanov A.S. , Budkov A.S. , Djachenko S.A., Dudkin S.O Trudy MAI. Vypusk № 100 http://trudymai.ru/ Arhitektura perspektivnyh kompleksov upravlenija bortovym oborudovaniem
[6] Francesca M.Favarô David W.Jackson Joseph H. Saleh Dimitri N. Mavris Software contributions to aircraft adverse events: Case studies and analyses of recurrent accident patterns and failure mechanisms Reliability Engineering & System Safety Volume 113, May 2013, Pages 131-142
[7] A. A. Kalent'ev, Ju. M. Sygurov Razrabotka informacionnoj podderzhki processa proektirovanija upravljajushhih algoritmov bortovyh kompleksov upravlenija kosmicheskih apparatov, Vestnik Samarskogo gosudarstvennogo ajerokosmicheskogo universiteta № 1 (21) 2010
[8] DOT/FAA/AR-99/58 Office of Aviation Research Washington, D.C. 20591 NASA/CR-1999-209347 Langley Research Center Hampton, VA 23681-2199 U.S. Department of Transportation Federal Aviation Administration Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance March 2000 Final Report
[9] Jeff Foust Starliner investigation finds numerous problems in Boeing software development process, February 7, 2020 https://spacenews.com/starliner-investigation-finds-numerous-problems-in-boeing-software-development-process/ reference date 25.03.2021
[10] Kotov, K. Y., Mal'tsev, A. S., Nesterov, A. A., and Yan, A. P., "Algorithms and Architecture of the Multirotor Aircraft Trajectory Motion Control System", Optoelectronics, Instrumentation and Data Processing, vol. 56, no. 3, pp. 228-235, 2020. doi: 10.3103/S8756699020030085
[11] G. Guglieri Effect of autopilot modes on flight performances of electric mini-UAVs, The aeronautical journal, January, 2013 Vol.117 #1187
[12] K. Wortman, B. Duncan and E. Melin, "Agile methodology for spacecraft ground software development: A cultural shift," 2017 IEEE Aerospace Conference, 2017, pp. 1-8, doi: 10.1109/AER0.2017.7943886
[13] SR Hirshorn, LD Voss, LK Bromley NASA systems engineering handbook Rev2 2017
[14] T.A. Heppenheimer The Space Shuttle Decision NASAs Search for a Reusable Space Vehicle
NASA SP-4221, Washington, 1999
