Эмуляция аппаратного обеспечения бортовых навигационных комплексов для разработки компонентов программного обеспечения авиационных систем

Размещено на http://www.allbest.ru/

Эмуляция аппаратного обеспечения бортовых навигационных комплексов для разработки компонентов программного обеспечения авиационных систем

Введение

эмулятор программный вычислительный

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

Необходимость разработки технологии эмуляции при проектировании комплексов программ на высокоуровневых языках определяется несколькими условиями. Во-первых, аппаратное обеспечение вычислительной системы авионики на начальных этапах проектирования либо отсутствует (еще не изготовлено в производстве), либо изготовлено в единичном (опытном) экземпляре и используется различными группами разработчиков, находящимися в состоянии «взаимной конкуренции» за обладание временным ресурсом использования образца.

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

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

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

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

1. Обоснование разработки программы-эмулятора

В начале 2000-х годов в Санкт-Петербургском ОКБ «Электроавтоматика» было принято решение о начале разработки новой отечественной операционной системы (ОС) реального времени для изделий интегрированной модульной авионики (ИМА), соответствующей отраслевому стандарту ARINC 653, но отсутствие готовой аппаратной платформы могло привести к необходимости написания большого объема низкоуровневого кода, работающего со сложной высокоинтегрированной аппаратурой. При этом отсутствие аппаратных средств для отладки ПО на целевой платформе предвещала множество незабываемых часов, потраченных на его отладку.

Классическим решением в данной ситуации является использование для разработки ПО эмулятора целевой аппаратной платформы. Доступные на тот момент эмуляторы имели существенные недостатки [9, 10]: отсутствие эмуляции уникальных устройств (контроллеров) собственной разработки, входящих в состав заданной целевой платформы; отсутствие удобного графического интерфейса пользователя; отсутствие развитых интеллектуальных средств отладки ПО. Разработчики ОС осознали потребность не просто заменить аппаратный «черный ящик» целевой платформы на программный «черный ящик» эмулируемой целевой платформы, но превратить его в «белый ящик», т.е. получить полную информацию о состоянии системы и ее компонентов, причем в удобном экранном представлении. Таким образом, разработчики ОС пришли к выводу о необходимости разработать специализированную программу-эмулятор целевой аппаратной платформы для отладки и тестирования ОС .

Целевая аппаратная платформа представляла собой базовый вычислительный модуль авионики -- процессорную плату, реализованную на основе микропроцессора IDT 79RC64574 архитектуры MIPS4. Функциональная схема базового вычислительного модуля авионики приведена на рис.1. В состав аппаратных средств модуля входили:

- цифровой процессор ЦП 1;

- цифровой процессор ЦП 2;

- контроллер-коммутатор памяти, реализованный на базе элементов программируемой логики;

- контроллер RS-232;

- системный таймер;

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

- постоянное запоминающее устройство ПЗУ общего доступа, в качестве которого использовалась FLASH-память;

- несколько оперативных запоминающих устройств (ОЗУ), объединенных по схеме независимых «банков ОЗУ»;

- ОЗУ общего доступа (ОЗУОД);

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

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

- управляющий микроконтроллер (МК), имеющий доступ к ПЗУ процессоров через свою внешнюю шину;

- ОЗУ общего доступа ЦП 1 и МК;

- ОЗУ общего доступа ЦП 2 и МК.

Рис.1. Функциональная схема базового вычислительного модуля

Эмулятор должен был представлять собой совокупность программных средств, исполняемых на инструментальной ЭВМ в диалоговом режиме. В задачи эмулятора вычислительного модуля входили:

- эмуляция работы следующих аппаратных устройств: процессоров, шины адрес/данные, ОЗУ (в том числе режим общего доступа для процессоров), ПЗУ, контроллера RS-232, системного таймера, аппаратных средств взаимодействия между процессорами;

- эмуляция выполнения программного обеспечения на двух процессорах одновременно;

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

- загрузка файлов в ячейки памяти ОЗУ/ПЗУ эмулируемого модуля и чтения ячеек памяти ОЗУ/ПЗУ с сохранением данных в файле;

- реализация окна консольного терминала интерфейса RS-232;

- дизассемблер содержимого ячеек памяти;

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

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

- отображение полного состояния всех устройств модуля и возможность изменения состояния любого устройства во время отладки программного кода;

- возможность установки пользователем точек остановки по событиям, возникающим в процессе работы эмулируемой аппаратуры (исключение, переполнение, изменение, обращение по адресу, обращение к ОЗУ и пр.);

- возможность отслеживать данные в памяти в соответствии с их типами (низкоуровневая отладка), возможность устанавливать точки остановка при изменении данных в памяти;

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

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

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

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

При разработке эмулятора были учтены все положительные и отрицательные стороны известных эмуляторов, а также особенности разрабатываемого продукта прикладного характера (см. рис 2).

Рисунок 2. Рабочее окно программы-эмулятора в режиме отладки ПО для базового вычислительного модуля целевой платформы

2. Совместная (взаимосвязанная) разработка ОС и эмулятора

Разработка эмулятора предполагала, во-первых, создание программы, эмулирующей работу функциональной модели вычислительного модуля, во-вторых, дополнение эмулятора функциональными возможностями для отладки ОС ЭОС [4,5].

Таким образом, на начальном этапе была создана модель эмулятора процессорного модуля, соответствующая функциональной модели вычислительного модуля (см. рис.1), способная выполнять код программы и выводить программные сообщения, направляемые на консоль, в окне терминала инструментальной ЭВМ [2]. На этом этапе были разработаны несколько отдельных тестовых программ, выполнение которых на эмуляторе и на аппаратуре показало полную идентичность исполнения инструкций и приемлемую близость рассчитываемого на эмуляторе времени выполнения программы к реальному времени выполнения той же программы на физической аппаратуре. Таким образом, была подтверждена правильность предложенных разработчиками моделей.

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

В результате экспериментов за довольно короткий срок (2 года) разработчики ОС смогли реализовать и исследовать несколько вариантов архитектуры ядра ОС (из которых затем была выбрана наилучшая), реализовать интерфейс ОС и приложений, соответствующий стандарту ARINC 653, и набор тестов для проверки соответствия ОС этому стандарту -- суммарно около 250 тестов. Необходимо отметить, что весь объем работ проводился на эмуляторе практически без использования целевой аппаратной платформы.

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

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

При разработке тестов разработчики ОС столкнулись с неожиданной проблемой. В отличие от прикладного ПО авионики, которое разрабатывается для конкретного изделия, операционная система, являясь универсальным ПО, должна выполняться на разных аппаратных платформах, обеспечивать работу с разными конфигурациями прикладного ПО и аппаратных средств. Оказалось, что протестировать работу ОС с конфигурациями, в которых некоторые параметры имеют максимальные проектные значения, на физических аппаратных платформах не возможно в принципе из-за недостатка аппаратных ресурсов. Например, из-за недостатка физической памяти невозможно провести тестирование конфигураций, в которых количество объектов некоторого типа равно максимальному значению, заданному в требованиях к операционной системе. Решение проблемы лежало на поверхности и заняло несколько минут - разработчики эмулятора «добавили» в эмулируемый модуль несколько сотен мегабайт оперативной памяти.

Одновременно появилась необходимость портирования ОС на другую целевую платформу. Поскольку процессорные ядра обоих платформ реализуют одну архитектуру MIPS (хотя и разные ее версии) решено было обойтись «малой кровью» и не разрабатывать модель для нового процессора, но зато разработать модели внешних устройств новой целевой платформы. В результате появилась эмуляция нескольких гибридных модулей, не существующих в природе, каждый из которых позволял отрабатывать специфические компоненты ПО. Интересной особенностью портирования ОС с одной целевой платформы на другую, ощущаемой программистом, явилась плавность перехода, выражающаяся в постепенном замещении устройств одной платформы другими, что позволило выполнить переход поэтапно и с гораздо большим комфортом, чем при выполнении портирования без использования эмулятора. Например, в исходную эмулируемую целевую платформу была добавлена эмуляция контроллера RS-232, входящего в состав новой целевой платформы. Разработчик драйвера нового контроллера получил возможность отлаживать новый программный код, пользуясь старым контроллером для выдачи диагностических сообщений на терминал. Когда отладка драйвера для нового контроллера была завершена, старый контроллер был удален из эмулируемой платформы.

Примерно в это же время функциональность эмулятора была расширена возможностью просмотра внутренних структур данных ОС. Если возможность просмотра переменных отлаживаемой программы, в качестве которой в данном случае выступает ОС, была и ранее, то теперь в эмуляторе появилось средство удобного просмотра сложных структур данных, формируемых ОС динамически на этапе инициализации. Примером такой информации являются структуры данных, используемые ОС для организации виртуальных адресных пространств приложений и управления аппаратными устройствами отображения виртуальной памяти (TLB). Такое расширение функциональности привело к значительному сокращению времени отладки системного программного обеспечения, поскольку устранило необходимость для программиста «вручную» проходить по цепочке указателей, отыскивая нужный объект в памяти операционной системы.

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

Рисунок 3. Технология разработки ОС с использованием программы-эмулятора

3. Архитектура эмулятора

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

Базовым классом для всех эмулируемых устройств является класс Device, реализующий интерфейсы, необходимые как собственно для эмуляции выполнения программ, так и для обеспечения выполнения сервисных функций по отладке ПО. Все потомки класса Device подразделяются на три основные группы. Классы, эмулирующие устройства, выполняющие программы, реализуют дополнительный интерфейс ICPU. Классы, эмулирующие функциональность шины данных, реализуют дополнительный интерфейс IBus. Большую часть в иерархии классов, эмулирующих аппаратуру целевой платформы, составляют потомки класса BusDevice, эмулирующие устройства, подключаемые к шине данных. Для этого класс BusDevice реализует дополнительный интерфейс IBusDevice. Потомками этого класса являются классы, эмулирующие память, системный таймер, контроллер RS-232 и др.

Класс Board описывает вычислительный модуль целевой платформы, содержащий заданный набор устройств, реализуемых классами, порождаемыми от Device. Класс Simulator отвечает за процесс эмуляции выполнения программы, включая сброс и останов процессоров, анализ активности установленных событий отладки и вычисление времени выполнения программы. Класс Debug реализует механизмы трассировки выполнения программ и работы с событиями отладки. Класс Watcher обеспечивает возможность просмотра состояния всех устройств, в том числе предоставляя внутреннюю структуру этих устройств в виде набора переменных различных типов. Наконец, класс Terminal обеспечивает протоколирование и подыгрыш взаимодействия с целевой платформой по интерфейсу RS-232.

Рисунок 4. Диаграмма классов эмулятора

4. Перспективы применения эмулятора для отладки функционального ПО

Использование эмулятора целевой платформы при разработке функционального ПО может обеспечить те же преимущества, что и при разработке системного ПО:

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

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

3. Комфортную высокоуровневую отладку приложений с возможностью сохранения «следов» деятельности, и возможностью повторения выполненных действий.

4. Автоматизацию тестирования.

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

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

1) развитие возможностей отладки отдельных приложений, выполняемых под управлением ОС, просмотра состояния объектов, созданных приложением

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

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

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

5) дополнение эмулятора средствами динамического анализа выполняемого кода, обеспечивающими анализ глубины вызовов, использования стека, анализ структурного покрытия кода, анализ покрытия условий/ветвлений, определение мертвого кода и т.д.

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

Заключение

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

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

Литература

1. Благодатских В.А. др. Стандартизация разработки программных средств / Под ред. О.С. Разумова. - М. : Финансы и статистика, 2005. - 288с.

2. Богданов А.В., Кирсанова Ю.А., Уткин С.Б., Шек-Иовсепянц Р.А. Некоторые вопросы создания и использования виртуальных и физических моделей при разработке аппаратных и программных частей управляющих цифровых комплексов // Мир авионики, 2001, №1, стр.36-39.

3. Брауде Э. Технология разработки программного обеспечения. - СПб. : Питер, 2004. - 655с.

4. Гатчин Ю.А., Жаринов И.О. Основы проектирования вычислительных систем интегрированной модульной авионики: монография, М.: Машиностроение, 2010, 224 с.

5. Гатчин Ю.А., Жаринов И.О., Жаринов О.О. Архитектура программного обеспечения автоматизированного рабочего места разработчика бортового авиационного оборудования // Научно-технический вестник Санкт-Петербургского государственного университета информационных технологий, механики и оптики, 2012, №2, с.140-141.

6. Макконнелл С. Профессиональная разработка программного обеспечения. - Пер. с англ. - СПб.: - Символ-Плюс, 2006. - 240 с.

7. Парамонов П.П., Жаринов И.О. Интегрированные бортовые вычислительные системы: обзор современного состояния и анализ перспектив развития в авиационном приборостроении // Научно-технический вестник информационных технологий, механики и оптики, 2013, №2, с.1-17.

8. Хопкрофт Джон, Мотвани Раджив, Ульман Джефри Введение в теорию автоматов, языков и вычислений // Издательский дом «Вильямс», 2002г.

9. QEMU Emulator User Documentation [Электронный ресурс]. URL: http://qemu.weilnetz.de/qemu-doc.html (дата обращения: 17.03.2015).

Размещено на Allbest.ru