Теория и принципы построения
датчиков, приборов и систем
Представляет Ульяновский государственный
технический университет
УДК 681.3. 068:629.7.05
АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ ДРАЙВЕРОВ ИНТЕГРИРОВАННЫХ ПИЛОТАЖНО-НАВИГАЦИОННЫХ СИСТЕМ, СЕРТИФИЦИРУЕМЫХ ПО СТАНДАРТУ КТ-178B1
В. В. Шишкин, Н. А. Долбня, В. А. Мишин
Рассмотрен подход к автоматизации проектирования драйверов авиационных бортовых информационно-управляющих систем, сертифицируемых по стандарту КТ-178В, на основе паттернов. Предложены модели драйверов, методика проектирования и инструментальные средства, обеспечивающие автоматизированное проектирование сертифицируемых драйверов. Приведена оценка эффективности разработанных инструментальных средств и методики.
Ключевые слова: автоматизированное проектирование, пилотажно-навигационная система, драйвер, паттерны проектирования, методика проектирования.
Постоянно повышающиеся требования практически ко всем характеристикам пилотажных и навигационных систем летательных аппаратов (ЛА), в особенности к их массогабаритным и надежностным характеристикам, вызывают необходимость разработки систем нового класса. Перспективным в этом направлении стало создание интегрированных пилотажно-на-вигационных систем (ИПНС). Назначением таких систем являются:
— измерение высотно-ско-ростных параметров движения
1 Работа выполнена в рамках реализации ФЦП "Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007—2013 годы", государственный контракт № 14.527.12.4001 от
11 ноября 2011 г.
летательного аппарата (ЛА) в связанной и земной системах координат;
— измерение параметров пространственного положения ЛА в земной системе координат;
— определение местоположения ЛА по информации от приемников сигналов спутниковых группировок космических аппаратов (СГКА) и счисления координат при отсутствии сигналов СГКА;
— решение навигационных вычислительных задач с применением информации аэронавигационных баз данных;
— отображение пилотажно-навигационной и сигнальной информации, информации о состоянии силовой установки и бортовых систем;
— ввод, хранение и выдача информации, введенной с органов управления индикатора и сопряженных систем ЛА;
— прием и отображение информации от метеонавигационной радиолокационной станции, информации от системы раннего предупреждения близости земли, информации от обзорных систем;
— прием и отображение информации от бортовых телевизионных установок;
— осуществление информационного взаимодействия с бортовым оборудованием (БО) ЛА посредством приема и выдачи цифровой информации по кодовым линиям связи и приема и выдачи дискретных сигналов.
Системы этого класса могут применяться в ЛА как в качестве
2
вепвогв & Эувгетв • № 6.2013
резервных, так и в качестве основных информационных. Применение ИПНС позволит:
— уменьшить массогабарит-ные характеристики за счет объединения в один моноблок на базе многофункционального индикатора таких приборов, как авиагоризонт, курсовая система, барометрический высотометр, указатели приборной и вертикальной скоростей, указатель числа Маха и т. п.;
— отображать большой объем необходимой пилоту информации в одном информационном поле, включающем в себя пилотажно-навигационную информацию, информацию о параметрах силовой установки и общего бортового оборудования, метеоинформацию, картографическую и видеоинформацию;
— повысить надежность пи-лотажно-навигационного комплекса за счет резервирования функций;
— обеспечить требуемые точностные характеристики определения параметров;
— обеспечить высокие эксплуатационные характеристики.
Большой объем обрабатываемой и вычисляемой информации, значительная часть которой должна обрабатываться в режиме реального времени, и требования по надежности и отказоустойчивости системы обуславливают ее построение на основе высокопроизводительного процессорного модуля, функционирующего под управлением операционной системы жесткого реального времени (ОСЖРВ) [1, 2]. При этом выполнение функциональных задач, а также надежность и отказоустойчивость ИПНС будут в значительной степени определяться ее программным обеспечением (ПО). Данный подход позволяет говорить о разработке класса систем с разными наборами функций.
Он согласуется с требованиями современного рынка авионики по обеспечению широкой номенклатуры ЛА пилотажно-на-вигационными системами, различающимися своей функциональностью и работающими с разными оконечными устройствами, функционирование и надежность которых определяется соответствующими драйверами.
В современном авиаприборостроении характеристики качества ПО для процессов его жизненного цикла подтверждаются по одному из стандартов сертификации. Наиболее часто при разработке ПО авиационных бортовых систем используется стандарт КТ-178В [3], регламентирующий критерии качества ПО на всех этапах его жизненного цикла.
Особые требования по надежности и отказоустойчивости предъявляются к низкоуровневым компонентам ПО, таким как драйверы устройств и драйверы протоколов межмодульного и межблочного обмена. Драйверы устройств функционируют на самом высоком уровне привилегий центрального процессора и сбой в них особо критичен, так как может повлечь за собой отказ всего вычислителя, даже несмотря на использование программно-аппаратных платформ с использованием виртуальных машин по АИШС 653 [4]. То же самое касается и драйверов протоколов. Даже с учетом того, что драйверы протоколов обмена чаще всего реализованы в виде статически подключенных библиотек объектного кода и являются частью прикладного ПО, разрыв связи между многофункциональными вычислителями и датчиками ИПНС чреват отказом всей системы.
Имеющиеся в настоящее время средства для автоматизированного проектирования драй-
веров жестко привязаны к конкретной аппаратной платформе и используемой целевой операционной системе. Кроме того, они не позволяют автоматизиро-ванно разрабатывать сертификационные артефакты драйверов. К таким артефактам в соответствии со стандартом КТ-178В относятся требования высокого и низкого уровней, описание архитектуры компонентов драйвера, специальным образом оформленный исходный код составных частей драйвера, таблицы трассируемости и т. п. [3].
Сертификационные артефакты, порождаемые в процессе проектирования драйвера по КТ-178В с учетом реальной практики проектирования, можно представить следующей структурной моделью (рис. 1):
Б, =
= <ЛБ,, ББ,, БС,-, ТБ,-, ТЕ,, ТИ,),
где / — идентификатор драйвера; ЛБ,- — архитектурные требования к поведению драйвера; ББ,- — требования низкого уровня к поведению драйвера; БС,- — исходный код драйвера; ТБ,- — типовые решения, используемые в требованиях и коде драйвера; ТЕ,- — тестовое окружение драйвера (модульные и комплексные тесты); ТИ,- — результаты тестирования драйвера.
Данная модель позволяет выделить типы артефактов, процессы преобразования артефактов одного типа в артефакты другого, возможные переходы между процессами и критерии этих переходов.
Для автоматизации проектирования требований низкого уровня, исходного кода и модульных тестов сформируем классификацию существующих драйверов по таким критериям, как: тип обслуживаемого устройства; режим функциониро-
Рис. 1. Модель типового драйвера как множества артефактов
вания драйвера; уровень обслуживаемого устройства в общей топологической иерархии; уровень обслуживаемого устройства в логической иерархии; спецификация целевой операционной системы; спецификация целевой процессорной архитектуры; уровень реализуемого драйвером протокола. Классификация драйверов и типов внешних устройств легли в основу спецификации драйвера в виде кортежа:
(EP, IH, RS, MS, IS, RV>,
где EP (Entry Points) — точки входа драйвера; IH (Interrupt Handlers) — обработчики прерываний; RS (Register States) — состояния регистров обслуживаемого устройства; MS (Memory States) — состояние памяти обслуживаемого устройства; IS (Internal Statuses) — поля управляющей структуры драйвера; RV (Returned Values) — возвращаемые точками входа значения; PT (Processing Time) — время нахождения управления в драйвере.
Полная классификация точек входа EP драйвера состоит из точки входа инициализации устройства и драйвера; точки входа настройки режимов работы отдельных составляющих обслуживаемого устройства; точки
входа чтения данных; точки входа записи данных; точки входа установки обработчика событий. Точки входа драйвера представляют собой реентерабельные функции независимого выпол-
нения, что подразумевает возможность передачи управления в асинхронном и отложенном режимах.
Множество значений полей управляющей структуры IS имеет вид:
IS с I х M х P х E х T,
где I (Initialization Status) — степень инициализированности (по отдельным составляющим устройства); M (Modes) — режимы работы отдельных каналов устройства; P (Thread Priority) — приоритет выполнения кода драйвера; E (Errors Statistics) — статистика событий, определяемых, как неожиданное поведение устройства; T (Processing Time) — множество значений времени нахождения управления в драйвере.
Прикладной уровень (реализация API)
,L „1..
Выдача буфера данных
Прием буфера данных
I Сигнал о | завершении выдачи
Уровень регистровой модели
. 1
I тт II,-, II Установка I I тт I
, Чтение зоны . Запись зоны, , „ „ , . Извещение о,
I II I I обработчика I I I
I адресов t t адресов t ( t f прерывании t
Уровень физической среды
Протокол
Устройство
Платформа
Чтение адреса
Запись адреса
I Прерывание I
Аппаратура (шина доступа к устройству)
Рис. 2. Структурная модель типового драйвера
4
Sensors & Systems • № 6.2013
При этом спецификация используемой ОСЖРВ определяет однозначное соответствие элементов множества Р элементам множества Т, т. е.
р = до, V е е Т 3 {р} С {Р}: |{р}| - 1.
Спецификация драйвера позволила построить функциональную модель драйвера как конечного автомата, состояниями которого являются элементы множества ИБ х МБ х 1Б, воздействиями — элементы множества ЕР х 1Н х ИБ х МБ, реакциями — элементы множества ИБ х МБ х ИУ. С учетом особенностей автом
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.