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

• Автор: Долбня, Николай Алексеевич
• Шифр специальности: 05.13.12
• Научная степень: Кандидатская
• Год защиты: 2012
• Место защиты: Ульяновск
• Количество страниц: 220 с. : ил.

ВВЕДЕНИЕ
1. АНАЛИЗ ПРОЦЕССОВ ПРОЕКТИРОВАНИЯ ДРАЙВЕРОВ БОРТОВЫХ ИНФОРМАЦИОННОУПРАВЛЯЮЩИХ СИСТЕМ
1.1. Анализ бортовых информационноуправляющих систем реального времени авиационного применения

1.2. Анализ драйверов БИУС.

1.3. Анализ инструментальных средств разработки драйверов БИУС

1.4. Анализ жизненного цикла драйверов БИУС и методик проектирования ГО БИУС

1.5. Анализ методов проектирования ПО на базе паттернов

1.6. Выводы

2. РАЗРАБОТКА МОДЕЛЕЙ И МЕТОДИКИ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ДРАЙВЕРОВ БИУС

2.1. Разработка моделей типовых драйверов БИУС.

2.2. Разработка иерархической системы паттернов проектирования драйверов БИУС.

2.3. Разработка методики проектирования драйверов БИУС с использованием базы паттернов
2.4. Разработка методики виртуализации стенда БИУС
2.5. Выводы.
3. РАЗРАБОТКА ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ДРАЙВЕРОВ БИУС
3.1. Разработка информационного обеспечения средств автоматизированного проектирования драйверов БИУС.
3.2. Разработка лингвистического обеспечения системы автоматизированного проектирования драйверов БИУС.
3.3. Разработка программного обеспечения системы автоматизированного
проектирования драйверов БИУС
3.4. Разработка программного обеспечения виртуализации стенда БИУС
3.5. Выводы
4. АНАЛИЗ ЭФФЕКТИВНОСТИ МЕТОДИКИ И ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ДРАЙВЕРОВ БИУС.
4.1. План и цели экспериментов.
4.2. Определение множества объектов проектирования и их свойств для
проведения эксперимента
4.3. Оценка эффективности инструментальных средств и методики
автоматизированного проектирования драйверов БИУС
4.4. Оценка эффективности методики виртуализации стенда БИУС
4.5. Общий анализ полученных результатов экспериментов.
4.6. Выводы
ЗАКЛЮЧЕНИЕ.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК.
ПРИЛОЖЕНИЕ 1. АКТ О ВНЕДРЕНИИ
ПРИЛОЖЕНИЕ 2. ПЕРЕЧЕНЬ РАЗРАБОТАННЫХ ДРАЙВЕРОВ УСТРОЙСТВ БИУС.
ПРИЛОЖЕНИЕ 3. ПРИМЕР ПАТТЕРНА ПРОГРАММНЫЙ МОДУЛБ.
СПИСОК ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ


v i
iv v i
X xi
i
iii ii
i ii v

i
ix
i iv i
X xi
БИСК бортовая информационная система контроля
БИУС бортовая информационноуправляющая система
БКС блок концентратор сигналов
блок преобразования сигналов
БРЭО бортовое радиоэлектронное оборудование
ИСРГ индикатор системы резервных приборов
КИСС комплексная информационная система
сигнализации
КСЭИС комплексная система электронной индикации и
сигнализации
ЛВС локальная вычислительная сеть
МДЦ модуль дисплейный цветной
мипп
МПА
мпи
ОСЖРВ
пдк
по
СПАДИ
сэи
модуль измерения аэрометрических данных модуль измерения пространственного положения
модуль лицевой панели
модуль приема аналоговых сигналов
модуль приема дискретных сигналов
модуль питания индикатора
модуль управления подсветом
операционная система жесткого реального времени
общесамолетное оборудование
программнодиагностический комплекс
программная модель вычислителя
программное обеспечение
план программных аспектов сертификации
система преобразования аналоговой и дискретной информации
система управления общесамолетным оборудованием
система электронной индикации
ВВЕДЕНИЕ
Актуальность


Все эти организации главным стандартом для сертификации бортового авиационного Г полагают 8В 7 или его европейский аналог 8. В России используется его полный аналог КТ8В. ПО понадобился потому, что подход к сертификации ПО существенно отличается от подхода к сертификации любого агрегата самолета, поскольку методы проверки надежности оборудования неприменимы для ПО. Поэтому для сертификации ПО предлагается другой подход необходимо определить жизненный цикл ПО, входящие в него процессы, установить их цели, виды деятельности, условия переходов между ними, доказать сертифицирующим органам, что все они соответствуют стандарту и что разработчики следуют им на всем протяжении жизненного цикла НО. Стандарт КТ8В содержит всю эту информацию. Сертификация начинается с классификации рассматриваемого Г с точки зрения безопасности. Классификация напрямую связана с тяжестью состояния отказа, которое ПО может вызывать. Состояние отказа определяется как воздействие на летательный аппарат или на лиц, находящихся на его борту, привносящее существенный вред в операционные условия и окружение летательного аппарата. Л. Катастрофическое состояние, не совместимое с безопасным полетом и посадкой. В. Опасное состояние, при котором функциональные способности летательного аппарата или способности экипажа справляться с неблагоприятными условиями управления достигают нижних пределов безопасности. Экипаж не может выполнять свои задачи аккуратно и полностью. С. Существенное состояние, при котором функциональные способности летательного аппарата или способности экипажа справляться с неблагоприятными условиями управления снижены до существенных пределов. О. Несущественное состояние, не приводящее к значительным потерям безопасности управления летательного аппарата. Е. Не влияющее состояние, никак не влияющие на способности управления летательным аппаратом. Исходя из этой классификации и сертифицируются ПО очевидно, что для программ, сбой которых приводит только к состоянию Е, сертификация не требуется, а программы, способные привести к катастрофе, проверяются гораздо тщательнее остальных. Чем выше уровень ПО от Э до Л, тем более жесткие требования предъявляются к нему, к детальности и объему необходимой документации, и, как следствие, требуется больше ресурсов для процесса сертификации. Уровень ПО зависит от уровня других программных компонентов, использующихся в системе, а также аппаратного обеспечения, на которое предполагается установить это ПО. Если аномальное поведение ПО может приводить к различным категориям состояния отказа, то уровень ПО выбирается в соответствии с самым серьезным состоянием отказа. Ключевым понятием КТ8В является понятие жизненного цикла программы. Стандарт определяет жизненный цикл ПО как период времени, который начинается с решения о производстве или модификации программного продукта и заканчивается тогда, когда продукт перестает поддерживаться причем под продуктом здесь понимается не только сама программа, но и связанные с нею документация и данные. КТ8В жестко не устанавливает каких либо моделей жизненного цикла, поэтому любые модели, будь то каскадные, итерационные или какиелибо другие, могут быть использованы, но он требует, чтобы они были описаны или чтобы были указаны источники их описаний, а также показано, что жизненный цикл следует этим моделям. Все, что производится в течение жизненного цикла для планирования, управления, объяснения, определения, контроля, доказательства проведения определенных действий, относится к артефактам жизненного цикла ПО, и без этих артефактов сертификация невозможна. Для всех процессов жизненного цикла стандарт определяет их цели в соответствии с уровнями ПО. Процесс содержит в себе один или несколько видов деятельности, каждое из которых представляет собой набор действий для решения конкретной задачи или группы тесно связанных задач. Конкретный проект может определять один или несколько жизненных циклов и выбирать виды деятельности для каждого процесса, их последовательность и решаемые задачи. Общая схема процессов, составляющих жизненный цикл ПО БИУС, приведена на рисунке 1.