ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2016 г.)
2-летний импакт-фактор РИНЦ: 0,493
2-летний импакт-фактор РИНЦ без самоцитирования: 0,389
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,732
5-летний импакт-фактор РИНЦ: 0,364
5-летний импакт-фактор РИНЦ без самоцитирования: 0,303
Суммарное число цитирований журнала в РИНЦ: 5022
Пятилетний индекс Херфиндаля по цитирующим журналам: 355
Индекс Херфиндаля по организациям авторов: 499
Десятилетний индекс Хирша: 11
Место в общем рейтинге SCIENCE INDEX за 2016 год: 304
Место в рейтинге SCIENCE INDEX за 2016 год по тематике "Автоматика. Вычислительная техника": 11

Больше данных по публикационной активности нашего журнале за 2008-2016 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2017

Разработка загрузчика программного обеспечения встроенной системы управления

Статья опубликована в выпуске журнала № 4 за 2003 год.[ 20.12.2003 ]
Аннотация:
Abstract:
Авторы: Домарацкий Я.А. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 6808
Версия для печати
Выпуск в формате PDF (1.06Мб)

Размер шрифта:       Шрифт:

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

При большом числе внешних событий и внутренних состояний системы (сотни или тысячи событий и состояний) и при наличии большого числа связей между обработчиками событий построение программной части встроенной системы управления на основе бесконечного управляющего цикла не представляется возможным. В данном случае необходимо использование операционной системы реального времени (ОСРВ) для организации псевдопараллельного исполнения набора прикладных задач и для организации обмена данными и управляющими сигналами между задачами [1]. Использование ОСРВ позволяет уменьшить число связей между компонентами системы и существенно упрощает модификацию системы в будущем. Кроме того, использование ОСРВ повышает уровень качества программного продукта так как функции ОСРВ могут быть протестированы независимо от прикладного программного обеспечения (ПО) [2].

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

Основные функции системного загрузчика

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

Как правило, выделяют два уровня ПО системного загрузчика: уровень драйверов устройств целевой аппаратной платформы и уровень программных модулей. Пример программной архитектуры системного загрузчика представлен на рисунке 1.

Примером системного загрузчика для встроенных программных систем может служить RedBoot монитор [3].

Основными функциями системного загрузчика являются:

-         предварительная инициализация целевой аппаратной платформы;

-         определение режима работы системы;

-         загрузка и запуск прикладного ПО;

-         средства отладки прикладного ПО;

-         средства тестирования и отладки целевой аппаратной платформы;

-         средства обновления прикладного ПО и системного загрузчика.

Функции системного загрузчика усложняются при усложнении целевой аппаратной платформы и прикладного ПО, приближаясь по своему набору к функциям системы BIOS персонального компьютера. В отдельных случаях, например при запуске системы Linux, выделяют несколько независимых этапов загрузки и соответствующих программных загрузчиков: загрузочные блоки (первый и второй этапы начальной загрузки) и загрузчик (третий этап процесса начальной загрузки) [4].

Подпись:  
Рис. 1
Предварительная инициализация целевой аппаратной платформы и определение режима работы системы

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

-         инициализацию центрального процессора (ЦП);

-         инициализацию подсистемы внешнего ОЗУ;

-         инициализацию устройств ввода-вывода;

-         подготовку системы к сеансу связи с пользователем или к загрузке прикладного ПО.

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

Загрузка и запуск прикладного ПО

Размер прикладного ПО в системах управления узлами автомобиля может достигать нескольких мегабайт. Размер прикладного ПО в современных телекоммуникационных системах может достигать десятков мегабайт. Таким образом, загрузка прикладного ПО обычно проводится во внешнее ОЗУ из внешних носителей. В качестве внешних носителей могут использоваться внешняя память, построенная на основе отдельных flash-микросхем, flash- simm-карт либо Compact flash-карт. Дополнительные интерфейсы (например Ethernet) также могут быть использованы для загрузки прикладного ПО с сетевых носителей.

Средства отладки прикладного ПО и целевой аппаратной платформы

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

-         просмотр и изменение содержания памяти;

-         передача управления по заданному адресу;

-         механизм остановки исполнения программы по заданному адресу.

Реализация вышеперечисленных функций обычно не требует существенных временных затрат. Наибольшую трудность может вызвать реализация механизма остановки программы по заданному адресу с использованием так называемого механизма программных точек останова. Однако большинство процессоров для встраиваемых систем (например, процессор MPC7450 компании "Моторола" [5]) предоставляют аппаратную поддержку реализации механизма остановки исполнения программы по заданному адресу.

Набор функций отладки прикладного ПО может быть расширен добавлением следующих функций:

-         остановка исполнения программы при обращении к заданной ячейке памяти;

Рис. 2

-         пошаговое исполнение программы;

-         показ отладочной информации и полей структур данных программы;

-         отладка программы в терминах команд ассемблера;

-         управление режимами работы ЦП.

Низкоуровневый отладчик DINK32 компании "Моторола" [6] может быть использован для получения полного списка функций низкоуровневой отладки ПО. В случае сложных (например многопроцессорных) аппаратных систем и при использовании нестандартных системных контроллеров применение системного загрузчика является неизбежным при отладке подсистемы внешней памяти, межпроцессорного взаимодействия, PCI интерфейсов и других интерфейсов ввода-вывода. Но вопрос совместной отладки системного загрузчика и целевой аппаратной платформы требует отдельного рассмотрения.

Системные загрузчики многопроцессорных систем

Пример аппаратной структуры многопроцессорной системы с общей шиной представлен на рисунке 2.

В данном примере три ЦП имеют доступ к общей памяти (банк памяти 1 и банк памяти 2), шине ввода-вывода (flash-память, последовательный порт, устройства световой индикации) и к двум PCI шинам. Представленная система может быть построена на базе процессора MPC7450 компании "Моторола" [5].

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

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

Процесс разработки системного загрузчика

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

-         разработка архитектуры системного загрузчика;

-         разработка и интеграция модулей системного загрузчика;

-         предварительная отладка системного загрузчика;

-         отладка системного загрузчика на целевой аппаратной платформе;

-         выпуск конечной версии системного загрузчика.

Разработка архитектуры системного загрузчика

Как правило, требования по производительности к системному загрузчику отсутствуют (за исключением ограничений, связанных со временем запуска ОСРВ). Таким образом, уровневая архитектура системного загрузчика, представленная на рисунке 1, является оптимальной с точки зрения изолированности программных модулей и переносимости ПО системного загрузчика. Вопрос выбора ОСРВ является ключевым. В большинстве случаев системный загрузчик может быть построен без использования ОСРВ. Применение ОСРВ требуется в тех случаях, когда библиотеки связи с внешними устройствами (например, библиотека поддержки TCP/IP протоколов) используют функции ОСРВ либо когда требуется организация псевдопараллельного исполнения задач системного загрузчика для сокращения общего времени загрузки системы.

Предварительная отладка системного загрузчика

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

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

Отладка системного загрузчика на целевой аппаратной платформе

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

Выпуск конечной версии системного загрузчика

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

Требования к качеству кода системного загрузчика могут варьироваться. Обычно требования по качеству выше чем 5 Сигма (0.2326 оставшихся дефектов на 1000 строк исходного кода). Иногда требования по качеству достигают 6 Сигма (0.00339 оставшихся дефектов на 1000 строк исходного кода). Для обеспечения заданного уровня качества рекомендуется применять технику независимого системного тестирования программных изделий [7].

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

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

Список литературы

1.        Get by Without an RTOS, Michael Melkonian, Embedded Systems Programming Magazine, vol. 13 no. 10 September, 2000.

2.        Никифоров В.В., Домарацкий Я.А.. Построение тестов для базовых функций встраиваемых операционных систем, // Программные продукты и системы. - 1998. - № 4.

3.        If the RedBoot Fits, Anthony J. Massa, Embedded Systems Programming Magazine, vol. 15 no. 8, August 2002.

4.        Booting Linux: The History and the Future, Werner Almesberger, June 25, 2000.

5.        MPC7450 RISC Microprocessor Family User's Manual, MPC7450UM/D 2/2003 Rev. 3.

6.        DINK32 PowerPC Debugger User’s Manual, DINK_UM/D 4/2003 Rev.13.1.

7.        Никифоров В.В., Домарацкий Я.А.. Системное тестирование программных изделий. // Программные продукты и системы. - 1998. - № 4.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=612
Версия для печати
Выпуск в формате PDF (1.06Мб)
Статья опубликована в выпуске журнала № 4 за 2003 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: