CC BY
49
12. Lysne O. Towards an Analytical Model of Wormhole Routing Networks. Microprocessors and Microsystems, vol.21, pp. 491-498, 1998.
13. Myricom, Inc., http://www.myri.com.
14. Ni L.M., McKinley P.K. A survey of wormhole routing techniques in direct networks. Computer, pp. 62-76, 1993.
15. Seitz C., Boden C.L., Seizovic N., J.Su,W. The Design of the Caltech Mosaic C. Multicomputer. Proceedings of the Washington Symposium On Integrated Systems, Seattle, WA, 1993.
16. A.T.C. Tam. Performance Studies of High-Speed Communication on Commodity Cluster. Phd. thesis, December 2001, University of Hong Kong.
РАЗРАБОТКА ЗАГРУЗЧИКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ВСТРОЕННОЙ СИСТЕМЫ УПРАВЛЕНИЯ
Я.А. Домарацкий
Motorola Global Software Group, Russia
В современном мире мы все чаще и чаще сталкиваемся со встроенными системами управления. Программная часть простейшей встроенной системы управления представляет собой бесконечный управляющий цикл, осуществляющий опрос входных воздействий на систему и вызов соответствующих обработчиков событий. Данный подход может быть использован при сравнительно небольшом числе входных событий и внутренних состояний системы (десятки событий и состояний) и при относительно слабых связях между обработчиками событий.
При большом числе внешних событий и внутренних состояний системы (сотни или тысячи событий и состояний) и при наличии большого числа связей между обработчиками событий построение программной части встроенной системы управления на основе бесконечного управляющего цикла не представляется возможным. В данном случае необходимо использование операционной системы реального времени (ОСРВ) для организации псевдопараллельного исполнения набора прикладных задач и для организации обмена данными и управляющими сигналами между задачами [1]. Использование ОСРВ позволяет уменьшить число связей между компонентами системы и существенно упрощает модификацию системы в будущем. Кроме того, использование ОСРВ повышает уровень качества программного продукта так как функции ОСРВ могут быть протестированы независимо от прикладного программного обеспечения (ПО) [2].
В случае сложных систем управления, как правило, выделяют отдельный программный компонент - системный загрузчик. Основными задачами системного загрузчика являются предварительная инициализация аппаратуры и запуск прикладного ПО. Как правило, отладка системного
загрузчика производится совместно с отладкой аппаратной части.
Основные функции системного загрузчика
Набор функций системного загрузчика варьируется в зависимости от свойств аппаратной платформы (набор интерфейсов ввода-вывода, наличие энергонезависимой памяти) и области применения системы (автомобильная промышленность, сетевые устройства и т.д.).
Как правило, выделяют два уровня ПО системного загрузчика: уровень драйверов устройств целевой аппаратной платформы и уровень программных модулей. Пример программной архитектуры системного загрузчика представлен на рисунке 1.
Примером системного загрузчика для встроенных программных систем может служить RedBoot монитор [3].
Основными функциями системного загрузчика являются:
- предварительная инициализация целевой аппаратной платформы;
- определение режима работы системы;
- загрузка и запуск прикладного ПО;
- средства отладки прикладного ПО;
- средства тестирования и отладки целевой аппаратной платформы;
- средства обновления прикладного ПО и системного загрузчика.
Функции системного загрузчика усложняются при усложнении целевой аппаратной платформы и прикладного ПО, приближаясь по своему набору к функциям системы BIOS персонального компьютера. В отдельных случаях, например при запуске системы Linux, выделяют несколько независимых
Уровень программных модулей системного загрузчика
Командная строка
Загрузка ОСРВ
Диагностическая система
Система отладки
Файловая система
Другие системы
Уровень драйверов устройств
Драйвер FLASH
Драйвер послед. канала
PCI драйвер
SPI драйвер
I2C драйвер
Драйверы других устройств
Целевая аппаратная платформа
ЦП Контроллер послед. канала Контроллер PCI канала Контроллер SPI канала Контроллер I2C канала Другие комм. контр
FLASH память
Послед. устройства
PCI устройства
SPI устройства
I2C устройства
Другие устройства
Рис. 1
этапов загрузки и соответствующих программных загрузчиков: загрузочные блоки (первый и второй этапы начальной загрузки) и загрузчик (третий этап процесса начальной загрузки) [4].
Предварительная инициализация целевой аппаратной платформы и определение режима работы системы
Как правило, системный загрузчик получает управление после включения питания целевой аппаратной платформы. После включения питания необходимо осуществить:
- инициализацию центрального процессора (ЦП);
- инициализацию подсистемы внешнего ОЗУ;
- инициализацию устройств ввода-вывода;
- подготовку системы к сеансу связи с пользователем или к загрузке прикладного ПО.
Обычно существует несколько режимов работы системы с точки зрения системного загрузчика. Примерами режимов работы системы являются: штатный режим работы, диагностический режим работы, режим обновления прикладного ПО на локальных носителях и режим обновления системного загрузчика. Режим работы системы может быть задан как внешним по отношению к системному загрузчику способом (например, посредством установки перемычек на системной плате), так и в результате сеанса связи системного загрузчика с конечным пользователем.
Загрузка и запуск прикладного ПО
Размер прикладного ПО в системах управления узлами автомобиля может достигать нескольких мегабайт. Размер прикладного ПО в современных телекоммуникационных системах может достигать десятков мегабайт. Таким образом, за-
грузка прикладного ПО обычно проводится во внешнее ОЗУ из внешних носителей. В качестве внешних носителей могут использоваться внешняя память, построенная на основе отдельных flash-микросхем, flash- simm-карт либо Compact flash-карт. Дополнительные интерфейсы (например Ethernet) также могут быть использованы для загрузки прикладного ПО с сетевых носителей.
Средства отладки прикладного ПО и целевой аппаратной платформы
Удобно, если системный загрузчик предоставляет простейшие средства отладки ПО. В современных системных загрузчиках обычно реализованы следующие функции по отладке прикладного ПО:
- просмотр и изменение содержания памяти;
- передача управления по заданному адресу;
- механизм остановки исполнения программы по заданному адресу.
Реализация вышеперечисленных функций обычно не требует существенных временных затрат. Наибольшую трудность может вызвать реализация механизма остановки программы по заданному адресу с использованием так называемого механизма программных точек останова. Однако большинство процессоров для встраиваемых систем (например, процессор MPC7450 компании "Моторола" [5]) предоставляют аппаратную поддержку реализации механизма остановки исполнения программы по заданному адресу.
Набор функций отладки прикладного ПО может быть расширен добавлением следующих функций:
- остановка исполнения программы при обращении к заданной ячейке памяти;
- пошаговое исполнение программы;
- показ отладочной информации и полей структур данных программы;
- отладка программы в терминах команд ассемблера;
- управление режимами работы ЦП.
Низкоуровневый отладчик 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 протоколов) используют функции ОСРВ либо когда требуется организация псевдопараллельного исполнения задач системного загрузчика для сокращения общего времени загрузки системы.
Предварительная отладка системного загрузчика
Предварительная отладка системного загрузчика производится, как правило, с использованием демонстрационных плат. В случае использования демонстрационной платы набор устройств ввода-вывода и архитектура подсистемы памяти могут отличаться от набора устройств ввода-вывода и архитектуры подсистемы памяти целевой аппаратной платформы. Однако основные функции системного загрузчика (например, работа с fla.sk-устройствами, интерфейс командной строки, функции по отладке ПО и т.д.) могут быть проверены с использованием демонстрационной платы.
Как правило, низкоуровневый инициализаци-онный код целевой аппаратной платформы (примером подобного кода является код инициализации системного контроллера) не может быть проверен с использованием демонстрационной платы. Для проверки инициализационного кода системного контроллера рекомендуется использовать системы совместной верификации аппаратного и программного обеспечения, строящиеся на основе моделей аппаратного обеспечения. Подобный подход позволяет осуществить проверку инициа-лизационного кода системного загрузчика на этапе разработки целевой аппаратной платформы.
Отладка системного загрузчика на целевой аппаратной платформе
Отладка системного загрузчика на целевой аппаратной платформе является наиболее трудоемким этапом отладки. Проведение предварительной отладки системного загрузчика с использованием демонстрационной платы и применение метода совместной верификации аппаратного и программного обеспечения позволяют сократить число дефектов кода системного загрузчика. Таким образом, на этапе отладки системного загрузчика на целевой аппаратной платформе приходится иметь дело в основном с дефектами аппаратуры (дефектами системного контроллера, внешних интерфейсов ввода-вывода, производства платы и т.п.).
Выпуск конечной версии системного загрузчика
Системный загрузчик является критической частью ПО с точки зрения обеспечения работоспособности системы. Как правило, код системного загрузчика загружается в энергонезависимую память целевой аппаратной платформы на этапе конечного тестирования аппаратной платформы в промышленных условиях и не может быть изменен в режиме промышленной эксплуатации.
Требования к качеству кода системного загрузчика могут варьироваться. Обычно требования по качеству выше чем 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 Al-mesberger, 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.
ЗАДАЧИ УЛУЧШЕНИЯ КАЧЕСТВА ПРОГРАММНЫХ ПРОДУКТОВ
О.Ю. Берг, С.В. Максюта, В.С. Пилидии
Индустрия программных продуктов (ПП) является одной из наиболее интенсивно развивающихся и прибыльных. В России же рынок собственных ПП практически отсутствует. Единичные образцы ПП, пользующихся спросом пользователей, лишены рыночной конкуренции как фактора самосовершенствования. Доля ПП России в объеме мирового рынка составляет менее 1 %.
При этом программная индустрия является одним из основных компонентов национальных информационных инфраструктур, без которых в современных условиях немыслимо ни социальное, ни экономическое, ни научное, ни оборонное развитие страны. Таким образом, возникает необходимость освоения современных методов и средств программной инженерии, особенно инженерии качества ПП, обобщаемых в международных и национальных стандартах.
В условиях рыночной экономики успешная деятельность любой организации возможна в том случае, если производимые ею продукция или услуги конкурентоспособны, соответствуют потребительскому спросу, действующим нормативным документам. Иными словами, продукция и услуги
должны быть высококачественными. При этом возникают вопросы: Как оценить качество ПП? чем его измерить? В данной работе рассмотрены основные задачи, решение которых позволяет улучшить качество выпускаемых ПП.
Одним из основных условий повышения качества ПП является совершенствование процесса их создания. За последние десять лет разработано множество концепций совершенствования указанных процессов. В качестве примеров можно привести концепцию «Улучшение процессов создания ПО» (Software Process Improvement, SPI) американского Software Engineering Institute (SEI), которая опирается на статистические методы контроля технологических процессов [1], «Сквозной контроль качества» (Total Quality Management, TQM) [2], «Реинжиниринг деловых процессов» (Business Process Reengineering, BPR) [3], «Постепенное совершенствование деловых процессов» (Business Process Improvement, BPI) [4].
В основе всех этих концепций лежит понимание жизненного цикла ПП как совокупности фаз, которые проходит ПП в процессе своего развития [5]:
