close

Вход

Забыли?

вход по аккаунту

?

Astapkovich

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
А. М. Астапкович, Ю. Е. Шейнин
ВСТРОЕННЫЕ
СИСТЕМЫ УПРАВЛЕНИЯ
Учебное пособие
Санкт-Петербург
2011
УДК 681.51
ББК 32.973
А-91
Рецензенты:
начальник лаборатории СПИИРАН
кандидат технических наук, доцент В. И. Шкиртиль;
зав. кафедрой комплексной защиты информации СПбГУАП
доктор технических наук, профессор Е. А. Крук
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
Астапкович, А. М.
А-91
Встроенные системы управления: учеб. пособие / А. М. Астапкович, Ю. Е. Шейнин. – СПб.: ГУАП, 2011. – 224 с.: ил.
ISBN 978-5-8088-0678-8
В учебном пособии рассматриваются многоканальные системы
управления реального времени встраиваемого класса. Значительное
внимание уделено современной аппаратной базе, технологиям разработки программного обеспечения и анализу современных стандартов для аэрокосмических и автомобильных применений. Детально
рассмотрены программно-инструментальные платформы QNX6 на
базе ОСРВ Neutrino и система стандартов OSEK/VDK.
Пособие предназначено магистрантам и аспирантам широкого
спектра специальностей. Может быть также рекомендовано системным интеграторам, руководителям проектов и менеджерам для актуализации своих знаний в данной области.
УДК 681.51
ББК 32.973
Учебное издание
Астапкович Александр Михайлович
Шейнин Юрий Евгеньевич
ВСТРОЕННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ
Учебное пособие
Редактор А. В. Подчепаева
Верстальщик С. Б. Мацапура
Сдано в набор 05.12.11. Подписано к печати 23.12.11.
Формат 60×84 1/16. Бумага офсетная. Усл. печ. л. 13,0.
Уч.-изд. л. 14,0. Тираж 150 экз. Заказ № 630.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
ISBN 978-5-8088-0678-8
© Санкт-Петербургский государственный
университет аэрокосмического
приборостроения (ГУАП), 2011
© А. М. Астапкович, Ю. Е. Шейнин., 2011
ВВЕДЕНИЕ
Настоящее учебное пособие посвящено рассмотрению многоканальных систем управления реального времени встраиваемого
класса для ответственных применений.
Отличительной особенностью этого класса является фиксированный на этапе разработки набор исполняемых программных кодов и повышенные требования к надежности программноаппаратной реализации алгоритмов управления системой, работающей автономно в жестких условиях эксплуатации. При этом под
надежностью системы подразумевается, в том числе, и необходимость реализации алгоритмов управления в требуемом временном
ритме по каждому из каналов управления. Исторически, многоканальные системы управления встраиваемого класса интенсивно
развивались и использовались в авиации и космических аппаратах. Именно эти применения в течение многих десятилетий определяли уровень развития как элементной базы, так и технологии
разработки программного обеспечения для систем управления.
Вместе с тем развитие элементной базы в течение последних десяти лет шло в полном соответствии с законом Мура, что обеспечило существенное увеличение объемов памяти программ и памяти
данных при одновременном снижении энергопотребления. Прогресс в развитии элементной базы обеспечил существенное расширение возможностей разработчиков аппаратного компонента
систем управления и одновременно потребовал развития соответствующих технологий разработки программного обеспечения. Эти
технологии интенсивно развиваются по нескольким главным направлениям.
Первое связано с широким использованием операционных и
микрооперационных систем реального времени (ОСРВ). Использование ОСРВ подразумевает необходимость использования специализированных программно-инструментальных сред поддержки разработки соответствующих микропроцессорных и микроконтроллерных платформ.
Второе направление характерно для систем управления современными автомобилями и связано с массированным переходом
к системам распределенного управления, реализуемым с применением сетевых технологий. При этом программное обеспечение
электронных блоков распределенной системы управления разрабатывается с применением технологий сетевых микрооперационных
систем управлении реального времени (mОСРВ). Можно без боль3
шого риска ошибиться предсказать, что в следующем десятилетии
именно автомобильная промышленность будет обеспечивать прогресс в развитии технологий разработки систем управления. Эта
уверенность базируется на высоком темпе обновления модельного
ряда и большим объемом производства, что обеспечивает возможность выделении значительных средств на соответствующие НИОКР. Характерным примером является разработка семейства стандартов OSEK/VDX, инициированная немецкими автомобильными
концернами.
Третье направление связано с тем обстоятельством, что современная система управления, даже скромная по размерам, обладает
сложной топологией и имеет разнородный компонентный состав.
Разработка программного обеспечения такого класса систем подразумевает одновременное использование нескольких платформ.
Фактически речь идет о необходимости применения унифицированных программно-инструментальных сред, обеспечивающих
создание корпоративных платформ поддержки разработки.
Настоящее учебное пособие представляет собой семестровый
курс, содержащий анализ современного состояния элементной базы
и технологий разработки программного обеспечения для систем
управления встраиваемого класса. Одной из главных задач этого
курса была необходимость формирования системного подхода к задачам разработки таких систем, которые становятся неотъемлемой
частью современных технических устройств, начиная со стиральной машины и заканчивая коммуникационными спутниками.
В пособии значительное внимание уделено анализу современных стандартов для аэрокосмических и автомобильных применений, современной аппаратной базе и современным технологиям
разработки программного обеспечения. Детально рассмотрены
программно-инструментальные платформы QNX6 на базе ОСРВ
Neutrino и система стандартов OSEK/VDX.
Авторы выражают благодарность ректору государственного
университета аэрокосмического приборостроения А. А. Оводенко,
чье решение и поддержка предопределило создание этого учебного
пособия.
Приятно также отметить доброжелательное отношение и помощь в получении материалов методического характера выпускника нашего университета, а ныне сотрудника компании PROSOFT
Горбунова Н. Б., а также помощь директора СЗЦИТ В. М. Космачева при подготовке пособия к изданию.
4
Глава 1. СТРУКТУРА СИСТЕМ УПРАВЛЕНИЯ
КОСМИЧЕСКИМИ АППАРАТАМИ
Интенсивное развитие систем управления встраиваемого класса
началось в середине прошлого века и напрямую связано с освоением космического пространства.
1.1. История развития цифровых систем управления
Достаточно быстро выяснилось, что многообразие и сложность
задач, стоявших перед создателями космических аппаратов, требуют использования цифровых систем управления. Следует подчеркнуть, что как бортовая, так и наземная аппаратура подобного
класса разрабатывалась впервые и изобиловала большим количеством новых технических и технологических решений на всех
уровнях разработки. Речь идет об элементной базе, структуре
устройств, систем, электронных блоков, помехоустойчивых протоколах обмена, алгоритмах и программном обеспечении. При этом
фактор времени, критически важный в условиях развернувшейся
гонки за лидерство в освоении космического пространства, оказывал существенное влияние на разработчиков. В настоящее время в
Интернете доступно большое количество информации об истории
развития систем управления космическими аппаратами [1–16].
История становления космической отрасли подробно изложена в
литературе [11], которая рекомендуется для самостоятельного изучения в качестве дополнительной.
§1. ЦВМ «Кварц» и третий советский
искусственный спутник
В качестве отправной точки в истории цифровых систем управления реального времени космических аппаратов следует считать
систему управления третьего советского искусственного спутника
Земли. Спутник был запущен 15 мая 1958 года с космодрома Байконур с помощью облегченной модификации ракеты-носителя P-7.
Это был первый полноценный космический аппарат, обладающий
всеми базовыми подсистемами цифрового управления [1].
На борту спутника было размещено 12 научных приборов, разработанных семью группами разработчиков. С их помощью прово5
дились прямые измерения давления и состава верхней атмосферы
Земли, определялись характеристики магнитного и электростатического полей Земли и ионосферы, изучались первичные космические лучи и микрометеорные частицы, проводились измерения
параметров излучения Солнца.
Спутник имел форму конуса с диаметром основания 1,73 м и высотой 3,75 м и весил 1327 кг. Внешний вид спутника показан на
рис. 1.1.
Спутник функционировал на орбите до 6 апреля 1960 года. Полет этого спутника заложил основы нового направления в науке –
космической физики. Выполненные на спутнике измерения позволили установить наличие внешней зоны радиационного поля
Земли. Была получена карта пространственного распределения
магнитного поля Земли в интервале высот 280–750 км [2].
Последовательность работы всех систем задавало программновременное устройство, которое и послужило прообразом современных систем управления встраиваемого класса. Система обеспечивала сбор телеметрической информации с научных приборов и ее
передачу на наземные пункты управления. Этот круг задач относился к классу задач управления полезной нагрузкой. Получаемая
информация передавалась по радиоканалу на систему наземных
станций слежения, реализованных на первых цифровых вычислительных машинах «Кварц». По этому же радиоканалу с наземных
пунктов управления поступали команды управления. Соответственно, задача управления системой радиосвязи также обеспечивалась бортовой системой управления [3].
Рис. 1.1. Третий искусственный спутник Земли
и наземный пункт управления
6
Кроме этих функций, бортовая система обеспечивала решение
ряда задач жизнеобеспечения спутника. К задачам этого класса относились задачи мониторинга системы питания и системы активного терморегулирования. Регулирование теплового режима осуществлялось путем управления циркуляцией газа, а также путем
изменения коэффициента собственного излучения. Это регулирование обеспечивалось системой из 16 управляемых жалюзи, сигналы управления которыми вырабатывались на основе показаний
температурных датчиков.
Цифровые вычислительные машины «Кварц» пришли на смену
аналоговым вычислителям и были разработаны под руководством
Т. Н. Соколова, заведующего кафедрой «Математические и счётнорешающие приборы и устройства» Ленинградского политехнического института. Для реализации ЦВМ «Кварц» были использованы логические элементы на базе ферритовых сердечников с вентильными элементами в цепях связи [4, 5].
Эти машины послужили основой распределенной системы измерения траекторных параметров искусственных спутников. Необходимость выполнения достаточно сложных по тем временам
расчетов в режиме реального времени заключалась в том, что для
уверенного нахождения спутника радиолокаторами после исчезновения его из зоны видимости необходимо как можно точнее знать
его координаты при следующем входе в зону наблюдения. Для этого система должна была:
принимать сигналы о координатах спутника;
преобразовывать эти сигналы в цифровой код;
сглаживать траекторию и привязывать ее ко времени;
осуществлять долговременное запоминание;
направлять эту информацию в канал связи, обеспечив помехозащитное кодирование.
При реализации системы управления впервые было осуществлено объединение нескольких машин в сеть. Центральная машина
системы размещалась в Москве, а 5 периферийных машин, принимающих и передающих телеметрическую информацию со спутника, были распределены по всей территории СССР.
Вопросы обеспечения надежности элементов, узлов и системы
управления являлись ключевыми для функционирования системы
в целом. В качестве показательного примера можно привести такой
факт, что для записи телеметрии на тех участках орбиты, которые
не были доступны наземным станциям слежения, впервые предполагалось применить бортовой магнитофон. Непосредственно перед
7
стартом была обнаружена его неисправность, и спутник отправился в полет с неработающим магнитофоном, что существенно снизило объем получаемой научной информации.
§2. Система управления корабля «Восток-1»
«Восток» – это наименование серии космических кораблей, созданных под руководством генерального конструктора С. П. Королева в период с 1958 по 1963 годы. На корабле «Восток-1» был осуществлен первый в истории успешный запуск в космос человека,
которым был Ю. В. Гагарин.
Полёт первого человека в космос, состоявшийся более пятидесяти лет назад, только условно можно назвать пилотируемым. Несмотря на многочисленные тестовые запуски, организаторы полёта
были совершенно не уверены в том, что человек сможет справиться
с выполнением космической миссии в ручном режиме. Вот почему
одновитковый полёт «Востока-1» от старта и до приземления протекал полностью в режиме автоматизированного управления. Из
этого вовсе не следует, что для первого космонавта Земли Ю. В. Гагарина выполнение полетного задания было простым делом. Драматические детали этого знаменитого полета стали известны широкой публике только в последнее время
Общая масса космического корабля составляла 4,73 т, длина (без
антенн) – 4,4 м, а максимальный диаметр – 2,43 м. Корабль состоял из сферического спускаемого аппарата массой 2,46 и диаметром
2,3 м, выполняющего также функции орбитального отсека. Приборный отсек имел массу 2,27 т, имел коническую форму с максимальным диаметром 2,43 м. Отсеки механически соединялись между собой при помощи металлических лент и пиротехнических замков.
Система управления космического корабля «Восток-1» была разработана под руководством Б. Е.Чертока. С учетом принятой концепции аппаратура кораблей «Восток» была выполнена как можно
более просто. Управление всеми бортовым системами в штатных
режимах осуществлялось программно-временным устройством
ПВУ «Гранит-5В». Каждый из этапов управления (взлёт, движение по орбите, посадка) описывался циклограммой – специальной
программой для ПВУ. Циклограммы управления закладывались
в «Гранит-5В» ещё на Земле. Для сохранения циклограмм в ПВУ
имелось устройство хранения информации – прообраз нынешних
постоянных запоминающих устройств [7].
8
Циклограммы могли корректироваться по дублированному
командно-управляющему радиоканалу. Два комплекта приемных
и дешифрирующих устройств аппаратуры командной радиолинии
с блоками коммутации обеспечивали прием на корабле 63 команд с
Земли для управления комплексом бортовой аппаратуры.
Маневр возвращения в нормальном режиме эксплуатации выполнялся автоматически по команде, передаваемой по радио с Земли. С целью горизонтальной ориентации корабля использовались
инфракрасные датчики. Выравнивание вдоль оси орбиты выполнялось при помощи звездных и солнечных датчиков ориентации.
Система ориентации корабля «Восток» имела два независимых режима работы: с автоматической одноосной ориентацией на Солнце (АСО) и ручным управлением (РУ) с визуальной ориентацией
на Землю. Исполнительными органами являлись два идентичных
комплекта (по восемь двигателей в каждом) микрореактивных двигателей, работающих на сжатом азоте.
В состав АСО входили блоки датчиков положения Солнца, датчиков угловой скорости (ДУС) и счётно-решающий блок. Датчик
Солнца был выполнен по щелевой схеме на принципе перекрытия
полей зрения трёх фотоэлементов. Контрольный датчик сигнализировал о правильности ориентации перед включением двигательной
установки. Датчики угловой скорости представляли собой двухстепенные поплавковые гироскопы с механической обратной связью.
С целью обеспечения надежности датчики угловой скорости каждого канала были троированы.
Счётно-решающий блок содержал элементы сравнения сигналов, поступающих от датчика Солнца и ДУС, логическую схему и
генератор импульсов постоянной длительности и частоты. Логика
управления могла реализовать как непрерывный режим работы исполнительных органов, так и импульсный. Режимы поиска Солнца (как ориентира) и поддержание положения ориентации корабля
были объединены. Автоматическая система ориентации пилотируемого корабля «Восток» была отработана в ряде беспилотных пусков в 1960 году [8, 9].
Система управления включала в себя дублирующую подсистему
ручного управления ориентацией на Землю и ручного управления
системами жизнеобеспечения. Переход в режим ручного управления осуществлялся через прообраз системы разграничения доступа, требовавшей ввода кода доступа.
Внешний вид компонентов подсистемы ручного управления показан на рис. 1.2. Конструктивно пульты управления выполнялись
9
Рис. 1.2. Компоненты подсистемы ручного управления
корабля Восток-1
1 – приборная панель 2 – ручка управления ориентацией
в пространстве; 3 – пульт управления системами жизнеобеспечения
таким образом, чтобы обеспечить работу космонавта в перчатке
скафандра.
Для обеспечения задач по работе человека в космическом пространстве корабль снабжался автономной и радиотелеметрической
аппаратурой контроля и регистрации параметров, характеризующих состояние космонавта, конструкции и систем. Двусторонняя
радиотелефонная связь космонавта с наземными станциями осуществлялась с помощью ультракоротковолновых и коротковолновых радиостанций. В состав подсистемы контроля состояния
космонавта входила телевизионная система с двумя передающими
камерами.
Системы жизнеобеспечения и терморегулирования поддерживали в спускаемом аппарате нормальную атмосферу с давлением
755–775 мм ртутного столба с 21–25 % кислорода по объему и температуру 17–26 °С.
Индивидуальное снаряжение космонавта включало в себя скафандр с системами вентиляции и кислородного питания. Хотя
штатный режим полета длился 108 минут, запасы пищи, воды и
емкости для сбора отходов были рассчитаны на 10 суток.
Считается, что успешное осуществление первого в истории пилотируемого космического полета на корабле «Восток-1» не в последнюю очередь было обеспечено надежной работой ПВУ «Гранит-5В»
и наземного комплекса управления. К счастью, подсистема ручного управления и запасы не понадобилась. В дальнейшем в качестве
10
управляющих систем в пилотируемых кораблях следующего поколения серии «Союз» стали применяться цифровые высоконадёжные бортовые ЭВМ семейства «Аргон» [10].
§ 3. Автоматический комплекс «Луна-16»
Под руководством Г. Н Баба́кина, руководителя и главного конструктора «НПО Лавочкина», был выполнен комплекс сложнейших разработок, обеспечивших ряд достижений советской лунной
программы, которые не превзойдены и по настоящее время. Одной
из его выдающихся разработок явился автоматический комплекс
«Луна-16».
Главным результатом полета «Луны-16» с точки зрения развития бортовых систем управления стала первая в мире доставка
автоматическим аппаратом на Землю образцов грунта внеземного происхождения. Общая масса колонки грунта, доставленного
«Луной-16» с поверхности Луны, составила 101 г.
Станцией «Луна-16» были установлены рекорды, зарегистрированные и подтвержденные дипломами FAI: мировой рекорд максимальной массы, доставленной на лунную поверхность в классе «С»;
мировой рекорд максимальной массы, возвращенной на Землю с
поверхности Луны в классе «С»; мировой рекорд максимальной
массы лунных пород, доставленной на Землю автоматической станцией в классе «С». Эти достижение в области использования автоматических станций не превзойдены до настоящего времени[11,
12, 13].
Конструкция станции. Структурный состав станции «Луна16» и ее внешний вид показаны на рис. 1.3. Комплекс состоял из
посадочного блока, возвратной ракеты Луна-Земля и спасаемого
аппарата [11, 14].
Посадочный блок был снабжен четырьмя опорами для мягкой
посадки на грунт. На ней были закреплены буровое устройство для
отбора образца грунта и ракета с возвращаемым аппаратом для
доставки контейнера с отобранными образцами на Землю. Двигательная установка посадочного блока имела основной двигатель с
регулируемой тягой для торможения, а также два двигателя малой
тяги, работающие на завершающем участке посадки. Основной
двигатель имел возможность многократного запуска. При подъеме
с Луны посадочный блок служил стартовым столом для ракеты
«Луна-Земля».
11
™Æ˾Æƹ
›ÇÀ»É¹Ò¹¾ÅÔÂ
¹ÈȹɹË
¨ÉÁºÇÉÆÔÂ
ÇËʾÃ
«ÇÈÄÁ»ÆÔÂ
º¹Ã
¬Èɹ»ÄØ×ÒÁ¾
ÊÇÈĹ
¨ÉÁºÇÉÆÔÂ
ÇËʾÃ
ÈÇʹ½ÇÐÆǼÇ
ºÄÇù
»Á¼¹Ë¾ÄÕƹØ
ÌÊ˹Æǻù
¨Çʹ½ÇÐÆǼÇ
ºÄÇù
šÌÉÇ»ÇÂ
žιÆÁÀÅ
±Ë¹Æ¼¹
ºÌÉǻǼÇ
žιÆÁÀŹ
»Á¼¹Ë¾ÄÕ
ɹþËÔ
¤Ìƹ ¾ÅÄØ
«¾Ä¾ÍÇËÇžËÉ
«ÇÈÄÁ»ÆÔÂ
º¹Ã
¨Çʹ½ÇÐÆÔÂ
ºÄÇÃ
Рис. 1.3. Структурный состав и внешний вид станции «Луна-16»
Система управления станции была распределенной. Бортовая
аппаратура, работающая на перелете и после посадки на Луну,
была сосредоточена в герметичном приборном отсеке тороидальной
формы с несколькими наростами в виде эллипсоидов с люками, через которые в отсек вставлялись приборы.
На центральном баке был укреплен цилиндрический приборный
отсек диаметром 56 см. Внутри отсека были установлены электронные счетно-решающие и гироскопические приборы системы управления ракетой, приборы двухканального бортового радиокомплекса метрового диапазона связи (линии Земля – борт и борт – Земля),
аккумуляторные батареи и приборы бортовой автоматики. В состав
системы управления, обеспечивавшей построение и запоминание
системы координат в момент старта, стабилизацию аппарата при
работе двигательной установки, входили курсовой гироприбор, состоявший из двух свободных гироскопов, гироскопический интегратор продольных ускорений, автомат стабилизации и автомат отключения двигателя. В качестве исполнительных органов системы
стабилизации на активном участке использовались рулевые сопла
двигательной установки.
Учитывая малое время полета возвратной ракеты, в системе энергопитания были использованы одноразовые серебряно-цинковые
батареи емкостью 14 ампер-часов.
12
На внешней поверхности приборного отсека ВР были установлены четыре штыревые приемно-передающие антенны. К верхней части приборного отсека с помощью металлических стяжных
лент прикреплялся спасаемый аппарат сферической формы массой
36 кг, который отделялся от ракеты по радиокоманде с Земли.
Возвращаемый аппарат представлял собой металлический шар
диаметром 50 см. Его внешний вид показан на рис. 1.4.
Предохранение оборудования аппарата от воздействия высоких температур при входе в атмосферу обеспечивало теплозащитное покрытие корпуса спускаемого аппарата. Внутренний объем
возвращаемого аппарата состоял из трех изолированных отсеков.
В первом из них располагались радиопеленгационные передатчики УКВ-диапазона, обеспечивающие возможность обнаружения возвращаемого аппарата при спуске на парашюте на Землю,
серебряно-цинковая аккумуляторная батарея емкостью 4,8 амперчаса, элементы автоматики и программно-временное устройство,
управляющее вводом в действие парашютной системы.
Во втором отсеке располагались в сложенном виде парашюты,
четыре упругие антенны пеленгационных передатчиков, два наполненных газом эластичных баллона, обеспечивающих необходимое положение возвращаемого аппарата на поверхности Земли после посадки. Площадь тормозного парашюта была 1,5 м2, а основного – 10 м2.
Рис. 1.4. Внешний вид возвращаемого аппарата
13
Третьим отсеком являлся цилиндрический контейнер для образцов грунта, взятых с поверхности Луны. В контейнере с одной
стороны было приемное отверстие, герметично закрываемое специальной крышкой после помещения туда взятых образцов.
Станция имела общую подсистему жизнеобеспечения, которая
обслуживала как посадочную платформу, так и возвращаемую
ракету. В нее входили подсистемы энергообеспечения и теплового регулирования. Подсистема энергоснабжения обеспечивала
электроэнергией все бортовые системы и на всех участках полета
и во время пребывания на поверхности Луны. Подсистема теплового регулирования обеспечивала поддержание в заданном диапазоне температуры газа внутри герметичных отсеков, температуры
элементов конструкции, бортового оборудования и аппаратуры,
расположенных на наружной поверхности станции. В полете эта
система поддерживала температуру в заданных пределах путем использования активных и пассивных способов терморегулирования.
Пассивные способы терморегуляции обеспечивались экранами вакуумной теплоизоляцией (ЭВТИ) и подбором оптических свойств
покрытий поверхностей, не защищенных ЭВТИ. Активные способы реализовывались циркуляционными и испарительными системами терморегулирования.
Функции системы управления. О функциях системы управления дает представление описание успешно реализованной программы полета [11–16].
Автоматическая станция «Луна-16» была запущена с космодрома Байконур 12 сентября 1970 года с помощью четырехступенчатой ракеты-носителя «Протон-К». На трассе перелета к
Луне 14 сентября была проведена коррекция траектории. 17 сентября было произведено включение двигателя, который, отработав 236 секунд, обеспечил торможение и выход автоматической
станции «Луна-16» на селеноцентрическую орбиту. Первая коррекция орбиты, проведенная 18 сентября, обеспечила прохождение аппарата над выбранным районом посадки с одновременным
понижением высоты до 20,8 км. С помощью второй коррекции,
проведенной 19 сентября, высота перицентр была уменьшена до
11,86 км.
Вновь двигательная установка была включена 20 сентября для
обеспечения торможение и схода с орбиты станции «Луна-16».
Высота над поверхностью Луны на начало торможения составила 13,28 км, а на момент выключения двигателя – 2,45 км. После
выключения двигателя аппарат в течение 43 секунд совершал сво14
бодное падение. На высоте 600 м от поверхности вновь начал работать основной двигатель станции в режиме регулируемой тяги в
соответствии с выбранной программой управления и поступающей
информацией от допплеровского измерителя скорости и радиовысотомера. На высоте 20 м скорость станции была снижена до 2 м/с.
Здесь основной ЖРД был выключен, и дальнейшее торможение
происходило с помощью двигателей малой тяги.
На высоте около 2 м по команде от гамма-высотомера они были
выключены, и 20 сентября автоматическая станция «Луна-16» совершила мягкую посадку на поверхность Луны в районе Моря Изобилия. При этом вертикальная скорость аппарата в момент касания поверхности составила 4,8 м/с. Протяженность трассы полета
от точки схода с орбиты до точки посадки составила 250 км. Масса
станции при посадке на Луну составила 1880 кг.
После посадки было определено положение станции на лунной
поверхности, а с помощью телефотометров были предприняты попытки получить изображения места бурения. Всего были произведено три включения телефотометров. Из-за недостаточной освещенности изображение места бурения получено не было.
Затем по команде с Земли было включено грунтозаборное устройство, и начались операции по забору грунта, включая бурение грунта до глубины 35 см. Взятые образцы грунта были помещены в контейнер возвратной ракеты и герметизированы.
Старт возвратной ракеты с поверхности Луны с образцами лунного грунта состоялся 21 сентября. Продолжительность обратного
перелета составила 84 часа. 24 сентября за 8 часов до входа спасаемого аппарата в атмосферу Земли произошло его отделение от возвратной ракеты. Скорость входа в атмосферу составила 10950 м/с,
а максимальные перегрузки, действующие на спускаемый аппарат
в процессе аэродинамического торможения, достигали 315 единиц.
При снижении вертикальной скорости до 250 м/с на высоте 14,5 км
была введена в действие парашютная система.
На высоте около 11 км произошло отделение тормозного и раскрытие основного парашюта. Одновременно с этим были включены
пеленгационные радиопередатчики. В 8 часов 14 минут самолетами и вертолетами поискового комплекса были приняты радиосигналы, а затем спуск на парашюте визуально наблюдался с вертолета Ми-4, который сопровождал его до посадки на Землю в 80 км
юго-восточнее города Джезказгана (Казахстан). Сложнейшая программа полета автоматической станции «Луна-16» была выполнена полностью.
15
Сбор телеметрических данных. Следует подчеркнуть, что путь
к успеху был усеян обломками от менее удачных предыдущих попыток. Краткое описание предшествующей серии запусков весьма
поучительно и дает представление об одной из ключевых функций
системы управления, обеспечивающей режимы работы с нарушением нормальных условий работы и аварийные режимы.
Для этих режимов принципиально важно обеспечить сбор и передачу на наземные пункты управления телеметрической информации с аварийного космического аппарата с момента возникновения нештатной ситуации до гибели аппарата. Только в этом случае
возможно продвижение вперед, а не бесконечный цикл повторения
одних и тех же ошибок. Очень много конкретных примеров о критически важном значении телеметрической информации приведено в литературе [11].
После полета станции «Луна-15», завершившегося аварийной
посадкой на поверхность Луны, было предпринято еще три попытки запустить аппарат этого типа для доставки на Землю образцов
лунного грунта.
Автоматическая станция, которая была запущена 23 сентября
1969 года с помощью ракеты-носителя «Протон-К», потерпела аварию из-за того, что уже после выведения на опорную геоцентрическую орбиту на пассивном участке полета из-за не закрывшегося
разделительного клапана в магистрали произошло истекание окислителя из топливного бака. Возникший нерасчетный возмущающий момент парировался исполнительными органами системы
обеспечения запуска, что привело к израсходованию рабочего тела.
В результате не произошло второе включение двигательной установки разгонного блока для перехода на траекторию полета к Луне.
По команде «Аварийное выключение двигателя» произошло отделение космического аппарата от разгонного блока. На 67-м витке
по командам с Земли с помощью двигательной установки было проведено торможение и затопление космического аппарата в акватории Тихого океана.
Автоматическая станция, которая была запущена 22 октября
1969 года, потерпела аварию вследствие того, что из-за отказа одного из блоков радиокомплекса обратные развороты головного блока
были проведены со значительной ошибкой, в результате к моменту
второго включения ДУ головной блок был неправильно сориентирован в пространстве. После отработки разгонного импульса автоматическая станция и разгонный блок вошли и сгорели в плотных
слоях атмосферы над акваторией Тихого океана.
16
Автоматический комплекс «Луна-24». Эта составляющая программы исследования Луны была завершена успешной работой автоматического комплекса «Луна-24». Комплекс стартовал к Луне
9 августа 1976 года. Его масса составила 5795 кг, масса возвратной
ракеты – 514,8 кг, а масса спасаемого аппарата – 34 кг. Комплекс
создавался с учетом опыта и на основе конструкций комплексов
«Луна-16» и «Луна 20», но содержал ряд доработок.
В частности, в три раза была уменьшена заправка водой системы
обеспечения теплового режима приборного отсека и снят высотомер малых высот «Квант». Освободившиеся ресурсы по весу были
использованы для реализации грунтозаборного устройства, которое включало в себя буровую головку, механизм перегрузки керна
и контейнер для его укладки.
Главным результатом полета «Луны-24» стала доставка на Землю образцов лунного грунта массой 170 г, при этом номинальное погружение буровой коронки в грунт соответствовало 225 см, а фактическая длина колонки составила около 160 см. Таким образом,
доставленные на Землю образцы лунного грунта завершили серию
проб: Море Изобилия («Луна-16»), его древнее материковое обрамление («Луна-20»), геологический разрез Моря Кризисов («Луна-24»).
Детальное описание конструкций советских автоматических
станций для исследования Луны и их систем управления заинтересованный читатель найдет в Интернете [16].
1.2. Системы управления марсохода
Spirit-Opportunity
Существенный прогресс в области элементной базы, приборостроения и систем управления обеспечил возможность проведения
исследований планет солнечной системы с помощью автономных
мобильных роботов. Современный уровень развития этого направления отражает проект исследования геологической истории Марса с помощью марсоходов Spirit-Opportunity.
В результате цикла выполненных исследований поставленная
задача была успешно решена, и в настоящее время имеются фактические доказательства наличия воды на Марсе в прошлом. Кроме
этого в геологической истории Марса были обнаружены следы вулканической активности. Это означает рождение нового научного
направления – геологии планет солнечной системы. Следует добавить, что в 2008 году аппарат Phoenix, приземлившийся недалеко
17
от северного полюса, выделил воду из мерзлого марсианского грунта, что явилось очередным успехом новой науки.
Этот раздел посвящен рассмотрению особенностей бортовой системы марсохода, проверенных практикой успешного применения.
§1. Описание проекта
Работы по проекту были выполнены NASA под непосредственным управлением ее лаборатории JPL (Jet Propulsion Laboratory).
Основной задачей для этой уникальной геологической партии являлся сбор данных о климатической и геологической истории Марса, а также обнаружение следов наличия воды на Марсе (хотя бы в
его истории).
На основании анализа результатов предыдущих экспедиций для
поиска были выбраны район кратера Гусева и равнина Meridiani
Planum. Эти районы располагаются на противоположных сторонах
планеты и имеют существенные отличия в геологическом плане,
что должно было повысить шансы на успешное решение поставленной задачи.
Два идентичных мобильных робота-геолога с именами Spirit и
Opportunity были доставлены на Марс в январе 2004 года. Внешний вид марсохода изображен на рис. 1.5.
Рис. 1.5. Внешний вид марсохода Spirit-Opportunity
18
Марсоходы должны были обеспечить возможность проведения
исследований в течение 3 месяцев. Они были оснащены многоканальной стереовидеосистемой, миниатюрным термоэмиссионным
спектрометром, спектрометром Мэссбауэра, рентгеноскопическим
спектрометром на альфа частицах, магнитометром. Для решения
основной задачи экспедиции марсоходы был оснащены манипуляторами с пятью степенями свободы. Манипулятор оснащен абразивной головкой для зачистки исследуемой поверхности, микрокамерой высокого разрешения и сенсорными элементами аналитических приборов.
Для передачи собранной информации имелась возможность
прямой связи с Землей, а также связи через орбитальный ретранслятор.
К моменту написания данного пособия функционирование марсохода Spirit было завершено, а марсоход Opportunity продолжал
работать. С помощью марсохода Spirit была успешно решена основная задача этой экспедиции – обнаружены следы наличия в прошлом воды на Марсе.
Фактически марсоход Spirit проработал 6 лет, пройдя маршрут
в 7,7 км, превысив тем самым проектную цифру в 12 раз. На Землю
был передано 124000 изображений. С его помощью было исследовано 15 объектов в виде обломков скал. С помощью бортовой научной
аппаратуры было проведено детальное исследование в 92 точках с
предварительной зачисткой для обеспечения спектрографических
и микроскопических исследований.
Концепция построения системы управления марсоходов.
Структурный состав робота-геолога показан на рис. 1.6. Шасси робота – шестиколесное с подвеской специальной конструкции, обеспечивающей контакт колес с поверхностью при перемещении по
неровной поверхности.
Каждое колесо имеет собственный электромотор, а передние и
задние колеса могут поворачиваться вокруг вертикальной оси. Базовые параметры шасси марсохода приведены в табл. 1.1.
Сложность осуществления геологоразведки на Марсе определяется его большой удаленность от Солнца и Земли. Удаленность
от Солнца существенным образом влияет на энерговооруженность
шасси. Удаленность от Земли не постоянна и меняется во времени
из-за различий в параметрах орбит и скоростей движения.
Максимально возможная проектная скорость перемещения
марсохода – 5 см/с (36 м/ч). Фактическая же скорость зависела от
используемого режима движения. В полностью автономных режи19
¦¹»Á¼¹ÏÁÇÆÆÔ¾
ùžÉÔ
«¾ÉÅÇÖÅÁÊÊÁÇÆÆÔÂ
ÊȾÃËÉÇžËÉ
¨¹ÆÇɹÅÆÔ¾
ùžÉÔ
™Æ˾Æƹ
¬£›
¹Æ˾Æƹ
ªÇÄƾÐÆÔ¾
ȹƾÄÁ
£¹ÄÁºÉÇ»ÇÐƹØ
ÅÁѾÆÕ
¦¹Èɹ»Ä¾ÆƹØ
¹Æ˾Æƹ
¥¹¼ÆÁËÇžËÉ
¥ÁÆÁ¹Ë×ÉƹØùžɹ
»ÔÊÇÃǼÇɹÀɾѾÆÁØ
™ºÉ¹ÀÁ»Æ¹Ø
¼ÇÄǻù
©¾Æ˼¾Æ
ÊȾÃËÉÇÅ
¥¹ÉÊÇÎǽ
4QJSJU
0QQPSUVOJUZ
±¹ÊÊÁÊȾÏÁ¹ÄÕÆÇÂ
ÃÇÆÊËÉÌÃÏÁÁ
SPDLFSCPHJF
Рис. 1.6. Структурный состав марсохода Spirit-Opportunity
мах она существенным образом зависела от способности системы
управления анализировать ситуацию на предполагаемом пути следования.
Таблица 1.1
Параметры шасси марсохода Spirit
Параметр
Значение
Количество колес с двигателями
Количество колес с возможностью поворота
Диаметр колеса
Предельно допустимая высота препятствия
Максимальная скорость
Номинальная скорость
Минимальный радиус разворота
Единица измерения
6
4
25
см
20
см
5
3,7
1
cм/с
cм/с
М
Из-за большой удаленности от Земли время передачи информации к марсоходу и получения ответа от него варьируется в диапазоне 8–42 минуты. Такая большая задержка делает невозможным
управление перемещением марсохода в режиме реального времени. Это означало, что с Земли могли поступать только высокоуров20
невые команды, выполнение которых обеспечивает бортовая система управления. Соответственно, команды на выполнение текущих
операций вырабатывались на основании информации получаемой
с марсохода и исходя из целей текущих исследований конкретного
этапа. Система управления обеспечивает для этой цели сбор и отправку телеметрической информация с систем марсохода и информации с приборов полезной нагрузки и камер видеосистемы.
Темп поступления команд с наземного пункта управления составлял, как правило, одна команда в марсианские сутки. Канал
передачи являлся чрезвычайно зашумленным, так как находился
в непосредственной зоне действия мощного широкополосного источника помех в виде Солнца. Ошибки в передаче команд и получении информации потенциально могли привести к потере марсохода, что означало срыв дорогостоящей исследовательской программы. Для обеспечения надежности канала связи была использована
комбинированная схема защиты, основанная на использовании
кода Рида-Соломона и сверточных кодов. Сверточные коды обеспечивали защиту от повреждения отдельных битов, а коды РидаСоломона обеспечивали защиту от пакетных ошибок. В целом это
существенно ограничивало скорость передачи информации.
При этом для решения поставленной задачи требовалось исследовать сложные геологические структуры, которые могли нести
информацию о геологической истории планеты. Точки, представляющие интерес, выбирались экспертами наземного пункта управления на основании анализа изображений окружающей местности.
Перемещение от одной такой точки к следующей требовало
перемещения по местности, на которой препятствие встречалось
в среднем каждые 5 метров. При этом нельзя было допустить ни
переворота марсохода, ни повреждения его шасси от столкновения
с обломками скал. Аналогичные по сути задачи возникали при использовании манипулятора и его инструментов.
В этих условиях решение поставленной задачи требовало обеспечить выполнение практически всего спектра решаемых задач
по перемещению марсохода и управлению манипулятора в полуавтономном и автономном режимах. В этих режимах существенным
образом использовалась видеоинформация со стереокамер робота.
На рис. 1.7 приведено видеоизображение с камеры марсохода,
показывающее положение манипулятора, снимающего заинтересовавший исследователей объект с помощью встроенной микроскопической камеры. Этот же рисунок дает наглядное представление о
характере местности, где проводились геологические изыскания.
21
Рис. 1.7. Вид с камеры марсохода Spirit
В штатном режиме эксплуатации роботы получали задания
один раз в марсианские сутки. Эти задания включали в себя указания, какую видеоинформацию и какие данные надлежит собрать,
в какую точку следует переместиться, как использовать манипулятор и аналитические приборы. Телеметрическая информация и
информация с камер и приборов пересылалась в наземный пульт
управления. Эти данные использовалась при разработке задания
на следующие сутки.
§ 2. Видеосистема марсохода
Передача видеоинформации с марсохода является совершенно
необходимой для оценки ситуации, выбора объекта и программы
его исследования, выработки последовательности высокоуровневых команд по перемещению марсохода в точку, представляющую
интерес. Анализ информации осуществлялся в наземном центре
управления. Кроме этого видеоинформация существенным образом использовалась системой управления робота для оценки препятствий и операций по их объезду.
Оценка ситуации по пути следования использовалась с помощью
стереоизображений, получаемых с помощью выбранной пары камер. Марсоход имел для этого три типа камер: две пары камер для
22
отслеживания препятствий (HazCams), пара поворотных камер для
оценки ситуации на маршруте, пара поворотных камер панорамного обзора (PanCam). Параметры камер приведены в табл. 1.2.
Видеосистема включала в себя камеру высокого разрешения на
манипуляторе робота, которая использовалась для получения детальных снимков геологических структур. Кроме того, на посадочной ступени имелась еще одна камера, которая использовалась при
съезде марсохода на поверхность Марса.
Особенности использования стереоизображений для решения
прикладных задач рассматриваются в литературе [17]. Видеоинформация существенно больше по объему по сравнению с командной и телеметрической информацией, но она обладает избыточностью, что позволяет использовать ее сжатия с целью обеспечения
разумного времени на ее передачу в наземный центр управления.
Таблица 1.2
Параметр
Параметры камер марсохода
Значение
HazCAm
2
52
NavCam
1
152
PanCam
1
152
Единица
измерения
Количество камер
Пара камер
Высота
cм
Расстояние между каме10
20
28
cм
рами
Угол зрения
125
45
18
градус
Максимальный размер
1024 ×1024 1024×1024 1024×1024
пиксел
изображения
Бит на пиксел
12
12
12
Дистанция стереоизобра0,5–5
2–20
4–70
м
жения
Управление поворотНет
Есть
Есть
наклон
Для этого иcпользовался специализированный алгоритм сжатия
информации, базирующейся на идеях вейвлет-компрессии. При соответствующем способе передачи коэффициентов этот подход [18,
19] обеспечивает поэтапное восстановление видеоизображения с
постепенным улучшением его качества вплоть до полного восстановления. На практике такой подход обеспечивает возможность
проводить анализ сцен до получения всего изображения и использовать изображения нужного качества в зависимости от решаемой
задачи. Фактически использовалась комбинированная схема с
управляемой степенью сжатия.
23
Для реализации сжатия был использован оригинальный алгоритм c пространным названием ICER Progressive Wavelet Image
Compression, разработанный сотрудниками JPL. Считается, что
это первый случай использования вейвлет-преобразований в космической технике. Использованный алгоритм имел много общего
с JPEG2000, в частности использовался метод битовых плоскостей.
Детали алгоритма рассматриваются в литературе [18, 19].
§ 3. Базовые функции системы управления
Система управления должна обеспечить функционирование
системы жизнеобеспечения, что являлось необходимым условием
возможности выполнения научной программы исследований.
Для выполнения научной программы требовалось обеспечить:
решение комплекса задач безопасного перемещения марсохода
в автономном режиме;
управление манипулятором для установки сенсорных элементов измерительной аппаратуры в заданные положения;
управление манипулятором и приборами полезной нагрузки и
сбор получаемых данных;
передачу данных и прием команд с центра управления.
Задача автономного перемещения формулировалась в таком
виде: марсоход за день должен быть способен без угрозы потери
функциональности преодолеть ощутимое расстояние по местности
с некоторым заданным уровнем сложности, не отклоняясь от заданного маршрута сверх установленных пределов. Детали задания
по перемещению зависели от наличия информации о местности. У
наземных операторов имелась возможность выбирать различные
режимы движения. Решение задачи автономного перемещения
обеспечивалось бортовой системой управления с использованием
стереоизображений окружающей местности и, в некоторой степени, показаний ряда других датчиков марсохода.
В состав системы управления входит подсистема навигации. Эта
система проводила анализ пути следования на предмет наличия
препятствий и определения их параметров. На основании этих данных строилась карта возможных путей следования к заданной точке. По этой карте подсистема навигации выбирала оптимальный
путь следования, обеспечивающий объезд препятствий. Движение
по выбранному маршруту обеспечивалось системой управления
движения с анализом текущего состояния марсохода на предмет
соответствия критериям безопасности.
24
Оценка текущего положения осуществлялась разными способами, в том числе и с помощью видеосистемы исчисления пройденного пути (visual odometry). Эта подсистема использовалась в тех
случаях, когда использование счисления пути по измерению количеству оборотов колес было невозможно из-за сложного характера
взаимодействия колес с поверхностью [20, 21].
Структура системы управления. Система управления движением была реализована по трехуровневой схеме и содержала:
уровень низкоуровневых команд;
уровень движения по дуге с заданными параметрами;
уровень автономного движения в заданную точку.
Низкоуровневые команды обеспечивают возможность оператору задать точно, на сколько следует повернуть каждое колесо и угол
поворота его оси. Уровень низкоуровневых команд обеспечивает
возможность реализации операций тестирования и нестандартных
операций. В частности, во время проведения исследований вращение одного из колес было использовано для создания углубления
в грунте. Эта точка была далее использована для проведения исследований геологических структур. Именно таким образом были
обнаружены первые фактические доказательства наличия воды в
прошлом.
Прямое управление поворотным механизмом использовалось
для диагностики неисправностей на финальной стадии эксплуатации марсохода Spirit, когда с ним возникли проблемы.
Движение по дуге является базовым примитивом, из которого
формируются все возможные типы перемещений. Движение по
прямой или поворот на месте являются частным случаем движения
по дуге. Маршрут движения к заданной точке конструировался из
дуг, обходящих препятствия.
Текущее положение робота оценивалось с помощью инерционной системы навигации Litton LN-200, включавшей в себя 3-Dасселерометры и датчики угловых скоростей, а также датчики
оборотов колес. На основании этой информации и реализуемой траектории движения вырабатывались команды управления моторами. Эта же информация использовалась в подсистеме обеспечения
безопасности движения.
Подсистема безаварийного движения. Во время движения
осуществлялась проверка с частотой 8 Гц на наличие нескольких
типов потенциальных угроз. Проверки включали в себя измерения
параметров:
наклон вперед/наклон вбок/поворот;
25
угол наклона солнечных батарей по отношению к Солнцу;
взаимное расположение элементов шасси марсохода;
потребляемый каждым мотором ток;
оценка прогресса в движении;
оценка доступных ресурсов.
Текущие параметры сравнивались с предельными параметрами. На основании этих оценок система управления могла заблокировать выполнение команд оператора, считая их слишком рискованными. При выработке задания на текущие сутки оператор мог
задавать степень автономности робота заданием соответствующего
режима перемещения и вариантов его реализации.
Режимы перемещения. Система управления перемещениями
обеспечивала возможность использования нескольких режимов
автономного перемещения в заданную точку.
При ручном управлении (Directed Driving) марсоход перемещался по заданной траектории без использования своих возможностей
анализа видеоизображения окружающей местности или адаптации
способа перемещения к ее особенностям. В этом режиме обеспечивалась максимальная скорость перемещения – до 124 м/ч. Этот
режим использовали на относительно плоских и чистых участках,
полагаясь на подсистему обеспечения безопасности перемещения.
Критерием возможности использования этого режима на пути
следования являлось отсутствие на траектории движения препятствий с высотой больше чем 20 см. Анализ ситуации проводился
на Земле, куда передавались изображения с каждой из пар камер.
Как правило, для анализа ситуации требовалось от 8 до 12 стереоизображений в направлении движения марсохода. Передача
этих снимков представляла собой завершающий этап выполнения
предыдущей команды на перемещение. На основании этих снимков строилась цветная 3D-карта окружающей местности, анализ
которой позволял принять решение о наличии объектов, представляющих интерес для исследования и возможности использования
режима ручного управления.
Для более сложных участков, например при перемещении по
склонам кратеров или холмов с уклонами 15–30 градусов, по команде оператора осуществлялся переход в режим автономной навигации (Autonomous Navigation – AutoNav). В этом режиме марсоход мог самостоятельно выбирать путь следования к указанной
точке. В результате анализа генерировалась программа действий
в виде конкретного набора примитивов, обеспечивающих объезд
препятствий.
26
Максимальная скорость перемещения в этом режиме составляла 36 м/ч. Реализация сгенерированной программы движения могла выполняться с использованием разных подсистем обеспечения
автономного движения. При движении по неровным и песчаным
участкам подсистема счисления пути на основе показаний датчиков числа оборотов не обеспечивала объективной информации.
В этих случаях подсистема счисления пути начинала использовать видеоинформацию. Идея алгоритма заключалась в выделении в
поле зрения марсохода базового объекта и вычислении смещения относительно него. Для обозначения этого способа счисления пройденного пути использовалось обозначение Visual Odometry. Ряд деталей
приведен в литературе [6]. Так как обработка снимков осуществляется бортовым компьютером с очень скромными по сегодняшним
меркам параметрами, то скорость перемещения, по сути дела, ограничивалась этой подсистемой и составляла 10 м/ч. По опыту эксплуатации этот подход к построению подсистемы великолепно себя
зарекомендовал. Ограничения на скорость перемещения являются
недостатками аппаратной реализации данной подсистемы.
При реализации того или иного варианта режима автономной навигации использовался менеджер ограничения активности
(Activity Constraint Manager), который проверял отсутствие противопоказаний к выполнению планируемых операций. К ограничениям этого класса относились: походное положение манипулятора,
отсутствие принятых команд, отсутствие ошибок при выполнении
предыдущих операций. Этот режим широко использовался на
практике.
За первые 21 месяц эксплуатации марсоходов ими было пройдено 10 км. Следует подчеркнуть, что при отработке алгоритмов
управления движением на Земле не могли быть смоделированы в
полном объеме марсианские условия. Соответственно, отработка
техники управления велась на протяжении всей миссии.
Подсистемы жизнеобеспечения. Базовыми функциями систем
жизнеобеспечения являются обеспечение энергией систем марсохода и поддержания температуры системы управления и приборов
полезной нагрузки в безопасном температурном коридоре.
Система питания обеспечивает энергией все подсистемы марсохода, каждая из которых представляет собой сложный комплекс.
Например, механическая система включала в себя 36 коллекторных, 4 шаговых и 4 бесколлекторных двигателя.
Система питания включает в себя солнечные панели, Li-Ion буферный аккумулятор и автономную систему управления. Аккуму27
лятор был специально разработан для этого проекта и обеспечивал
возможность работы при пониженных температурах. Состоял из
двух параллельных секций, каждая из которых состояла из восьми
ячеек. Аккумулятор для обеспечения 30 В питания с мощностью
16 А*ч (480 Вт), разрабатывался под обеспечение 500 циклов перезарядки. Выбранный тип аккумулятора требовал индивидуального контроля за степенью заряда каждой ячейки, формирующей буферную батарею.
Автономная система управления аккумулятора осуществляла
контроль операций заряда-разряда, контроль температурного состояния по пяти точкам, обеспечивала выдачу телеметрической информации, а также работу сторожевого таймера всей системы управления. Для каждой секции имеется собственная плата управления,
реализованная с применением микропроцессора и чипа FPGA.
Подсистема термоконтроля обеспечивала сохранение работоспособности аппарата на стадии перелета, посадки на Марс и его функционирования на поверхности. Эти стадии существенно отличаются друг от друга внешними условиями и длительностью. Описание
особенностей конструкции с учетом требований по температурному
режиму каждого из компонент рассмотрены в литературе [24, 25].
Бортовые компьютеры сохраняют работоспособность в диапазоне температур –40 – +40 °С. В течение марсианского дня максимальная температура составляла 22 °С и особых проблем с обеспечением
температурного режима не возникало. После захода Солнца температура опускалась до –100 °С, и обеспечение температурного режима оказывалось критически важным. Для обеспечения комфортного температурного режима бортовой компьютер был помещен в термокожух, подогреваемый с помощью электрообогревателей, восьми
радиоизотопных источников и выделяемого собственного тепла.
При работе на поверхности Марса бортовая система управления
обеспечивала подготовку всех систем к «ночевке», «побудку» при наступлении марсианского дня и их прогрев перед началом работы.
§4. Аппаратное обеспечение бортовой
системы управления
Аппаратно система управления реализована на базе одноплатного компьютера с 32-битным RISC-процессором RAD6000 с рабочей частотой 20 МГц. Разработка процессора для космических
применений была выполнена подразделением IBM Federal System
28
в сотрудничестве с лабораторией Air Force Research Laboratory.
Процессор разрабатывался на базе PowerPC 750. Максимальная
частота процессора составляет 33 МГц, а производительность 35
МIPS. Компьютер появился на открытом рынке в 1996 году и стоил
200000–300000 долларов. К июню 2008 года в использовании находилось более 200 бортовых систем космического класса, реализованных на базе этого компьютера. На Марсе системы на базе указанного микропроцессора до этого были использованы в проектах
Mars Pathfinder, Mars Polar Lander, Mars Climate Orbiter, Phoenix
Polar Lander.
Бортовой компьютер марсоходов имеет 128 Мбайт память
DRAM, 256 Мбайт памяти флэш и 3 Мбайта EEPROM. Размеры
платы компьютера 15×23 см.
Система управление моторами, связной аппаратурой, видеокамерами и научными приборами была реализована с использованием стандарта VMEbus. Для ряда устройств платы сопряжения имели последовательные интерфейсы и контроллер шины VMEbus,
реализованный на FPGA. Последовательные интерфейсы использовались как для связи с бортовым компьютером, так и для связи
плат расширения между собой.
Все стереокамеры марсохода разбиты на группу левых и правых камер, подключаемых через последовательные интерфейсы к
плате сопряжения. На рис. 1.8 показана блок-схема платы сопря7.&CVT
3"% ¡Æ˾É;ÂÊ7.&CVT
¨¹ÅØËÕ
»Á½¾ÇºÌ;ɹ
¨¹ÅØËÕ
»Á½¾ÇºÌ;ɹ
¥ÌÄÕËÁ
ÈľÃÊÇÉ
¥ÌÄÕËÁ
ÈľÃÊÇÉ
¤¾»Ô¾Ã¹Å¾ÉÔ
ÊÈÇÊľ½Ç»¹Ë¾ÄÕÆÔÅ
ÁÆ˾É;ÂÊÇÅ
¨É¹»Ô¾Ã¹Å¾ÉÔ
ÊÈÇÊľ½Ç»¹Ë¾ÄÕÆÔÅ
ÁÆ˾É;ÂÊÇÅ
Рис. 1.8. Блок-схема плат сопряжения камер с бортовым компьютером
29
жения для видеокамер стереопар. Камеры каждой группы подключаются через мультиплексоры, и может быть использована только
одна пара камер. При работе с одной парой камер другие камеры
видеосистемы не запитываются. Получаемая по последовательному интерфейсу видеоинформация с камер каждой группы сохраняется в памяти видеобуфера, откуда она попадает по шине VMEbus в
бортовой компьютер.
§5. Программное обеспечение системы управления
Структура и принципы построения программного обеспечения
строились на основе аналогичного и проверенного на практике
программного обеспечения для марсохода Mars Pathfinder. Была
использована коммерческая операционная система VxWorks компании Wind River. Это система с вытесняющей многозадачностью
(preemptive multitasking), которая широко используется в авиакосмической отрасли. На одном из семинаров представитель компании с гордостью утверждал, что они контролируют 100 % рынка
встраиваемых систем на Марсе.
Программное обеспечение системы управления марсохода требует 9 Мбайт памяти, из которых 1,4 Мбайта занимает модуль
управления перемещениями.
Программное обеспечение делится на высокоуровневые объекты. Все электронные устройства марсохода представляются в виде
таких объектов. Кроме этого имеются чисто программные объекты
для предоставления сервисов. Например, записи телеметрических
измерений или сохранения текущего состояния объекта.
Каждому программному объекту соответствует нить или задача.
Каждый объект имеет собственный массив переменных описания
состояния и собственную память, которая принадлежит только
ему. Объекты обмениваются информацию посредством сообщений.
При этом вся информация содержится в сообщении, т. е. не используются указатели на память задачи. Объекты включают в себя описание в виде машины состояний. Сообщения, получаемые из других задач, могут приводить к изменению состояния объекта.
Эта принятая парадигма программирования существенно упростила организацию быстрой разработки робастного программного
обеспечения. Программистам не надо было защищать доступ к разделяемой памяти семафорами, что снимало проблему взаимных
блокировок.
30
Следует указать, что этот подход не мог быть строго реализован повсеместно. В системе управления используется видеоинформация, которая слишком объемна для того, чтобы передаваться в
виде сообщений. Для такого рода обменов использовались схемы
захвата и освобождения буферов обмена, а приложения обменивались указателями на зарезервированные за ними буфера. Но таких
исключений было не очень много.
1.3. Стандарты систем управления
космического назначения
Международный характер современных космических проектов
и работа на рынке космических услуг требует наличия стандартов,
обеспечивающих возможность использования оборудования разных стран. Знание структуры и логики современных стандартов
для систем управления космическими аппаратами является необходимым условием возможности участия в международных космических проектах.
§ 1. Международная кооперация
в осуществлении космических проектов
Наряду с научными исследованиями параллельно идет интенсивное развитие космических технологий для телекоммуникационных применений. В качестве иллюстрации приведем сообщение
с ленты новостей, взятое в момент написания этого раздела.
«Разгонный блок “Фрегат”» модернизированной ракеты-носителя
“Союз-2.1а”, стартовавшей в среду 13.07.11 в 6.27 мск с Байконура,
успешно вывел на орбиты шесть американских космических аппаратов связи Globalstar-2», – сообщил представитель Роскосмоса. «Спутники переданы в управление заказчику. Таким образом, российская
часть программы по выводу на орбиту аппаратов Globalstar-2 считается выполненной», – сказал представитель космического агентства.
Globalstar – крупнейшая в мире по числу абонентов система коммерческой мобильной спутниковой связи. Спутники второго поколения с увеличенным до 15 лет временем работы и увеличенной
пропускной способностью заменят спутники Globalstar-1, которые
в последние годы испытывали проблемы с ускоренной деградацией
электронных компонентов ретрансляторов. Штатный состав груп31
пировки – 48 основных и 8 резервных аппаратов. Она способна принимать сигналы с 80 % поверхности Земли, за исключением приполярных областей и нескольких районов Мирового океана.
Развертывание космической группировки связи Globalstar второго этапа началось 19 октября 2010 года. В этот день »Союз-2» вывел на орбиту шесть спутников Globalstar второго поколения. Всего
в 2011 году Россия планирует запустить с Байконура 18 спутников для пополнения системы Globalstar: еще два запуска по шесть
спутников второго поколения в каждом намечаются на октябрь и
декабрь соответственно.
Первоначально состоявшийся в среду запуск был назначен на
6.58 мск понедельника, 11 июля. Однако за несколько секунд до
старта запуск был перенесен на 12 июля из-за выявленных автоматикой технических неполадок. Во вторник ранним утром запуск
снова не состоялся и был перенесен уже на резервную дату »в связи
с необходимостью окончательного устранения замечаний».
Это сообщение отражает ряд важных моментов, характерных для
сегодняшнего состояния космической отрасли. Речь идет, в первую
очередь, о сложившейся практике использования интернациональной кооперации при реализации бизнес-проектов, существенным
усложнением используемых аппаратов, большими финансовыми и
имиджевыми потерями при возникновении нештатных ситуаций.
Можно также утверждать, что без наличия общепринятых стандартов дальнейшее освоение комического пространства в коммерческих целях сильно замедлится.
§2. Система стандартов ECSS-E
В настоящее время Европа начинает развивать свою космическую отрасль, рассматривая ее в первую очередь с точки зрения
бизнеса. Для этой цели была создана организация European Cooperation for Space Standardization (ECSS).
Концепция системы специализированных стандартов рассматривает разработку систем управления как сложный процесс, требующий междисциплинарного подхода, учитывающего, как минимум:
механику системы управления;
особенности эксплуатации систем управления в космическом
пространстве и на внеземных объектах;
особенности поведения цифровых и аналоговых компонентов на
всех этапах жизни космических аппаратов.
32
Кроме этого требуется использование современных достижений
теории управления и компьютерных технологий применительно к
жестким условиям эксплуатации. В реальных проектах это создает
трудности при системной интеграции сложных многокомпонентных систем, что, как правило, сказывается на сроках реализации и
конечной стоимости проектов.
Эта взаимосвязь нашла свое отражение в структуре пакета
стандартов ECSS по состоянию на 2011 год, которая приведена в
табл. 1.3.
Таблица 1.3
ECSS-S-ST-00C
Описание систем
Стандарты управления
Система стандартов ECSS
ECSS-З-ST-001B
Описание терминов
Стандарты страхования Инженерные стандарты
M-10 Проектное плани- Q-10 Проектное управ- E-10 Инженерия систем
рование и реализация ление страхованием
продукта
M-40 Управление
Q-20 Страхование ка- E-20 Разработка элекструктурой и информа- чества продукта
трических и оптических
ционным обеспечением
систем
проекта
Q-30 ВзаимозависиE-30 Разработка мехаM-60 Управление
стоимостью и графиком мость
ники
проекта
E-40 Разработка проM-70 Интегрированная Q-40 Безопасность
граммного обеспечения
логистическая поддержка
M-80 Управление риQ-60 Технология
E-50 Коммуникации
сками
работы с электронными и электрическими
компонентами
Q-70 Материалы, меха- E-60 Разработка систем
нические компоненты управления
и процессы
Q-80 Страхование про- E-70 Наземные системы
граммных продуктов и работа с ними
Стандарт ECSS-E-60A. Стандарт был принят в 2004 году и, как
и все остальные стандарты этой организации, свободно распространяется. Он относится к пакету стандартов, касающихся инженерного обеспечения, и формализует базовые понятия, относящиеся к
системам управления.
33
В преамбуле к стандарту подчеркивается, что проектирование
систем управления космического класса является комплексным
процессом, включающим согласование ряда требований, касающихся структуры системы, механического, электрического, электронного компонентов, коммуникационной наземной структуры и
работы с ними.
Управляемая система определяется как часть системы, обеспечивающая ей требуемые свойства по достижению заданного состояния при наличии внешних неуправляемых воздействий. Включает
в себя систему управления и объект управления (управляемое оборудование).
Системы управления всегда используют обратную связь. Структурно для этого необходимо иметь датчики для оценки текущего
состояния оборудования, устройства управления, которые обеспечивают возможность изменения состояния управляемого оборудования, и устройство управления, реализующее предписанные алгоритмы управления по поступающим командам пользователей системы. Устройства управления осуществляют преобразование внутренних команд управления в физические воздействия на управляемый объект. Для сложных многокомпонентных систем датчики и
устройства управления, в свою очередь, могут быть сложными системами с дополнительными внутренними связями и внутренним
управлением. Такие системы строятся по многоуровневой схеме.
Системы управления разрабатываются под разнообразные и
весьма специфические цели. Они должны обеспечивать достижение
этих целей при наличии неконтролируемых внешних воздействий.
§3. Структура управляемой системы
Этот раздел содержит описание ряда базовых понятий, используемых стандартом. Для реальной работы рекомендуется использовать
полную версию стандарта. Во избежание терминологической путаницы переведенные названия для базовых понятий, вводимых в рамках
этого стандарта, сопровождаются обозначениями первоисточника.
Модель структуры управляемой системы, используемой в стандарте ECSS-E-60A, показана на рис. 1.9. Модель описывается рядом определений, вводимым этим стандартом.
Управляемая система (controlled system). Часть системы, обеспечивающая ей специфицированные свойства по управляемости.
Включает в себя управляемое оборудование и систему управления.
34
£ÇŹƽÔÌÈɹ»Ä¾ÆÁØ $POUSPMPCKFDUJWFT
›À¹ÁÅǽ¾ÂÊË»Á¾ÊÇÃÉÌ¿¹×Ò¾ÂÊɾ½ÇÂ
*OUFSBDUJPOXJUIFOWJSPONFOU
£ÇŹƽÔ
ÌÈɹ»Ä¾ÆÁØ
$POUSPMDPNNBOET
£ÇÆËÉÇÄľÉ
¬ÊËÉÇÂÊË»¹
$POUSPMMFS
ÌÈɹ»Ä¾ÆÁØ
"DUVBUPST
§ºÉ¹ËƹØÊ»ØÀÕ
$POUSPMGFFECBDL
¬Èɹ»ÄؾÅǾ
ǺÇÉ̽ǻ¹ÆÁ¾
$POUSPMMFE
1MBOU
¹ËÐÁÃÁ
4FOTPST
$¡ª«ž¥™¬¨©™›¤ž¦¡¸$POUSPM4ZTUFN
¬¨©™›¤¸ž¥™¸ª¡ª«ž¥™
$POUSPMMFETZTUFN
¬Èɹ»ÄؾÅǾ
ÈÇ»¾½¾ÆÁ¾
$POUSPMQFSGPSNBODF
Рис. 1.9. Структура управляемой системы
Управляемое оборудование (controlled plant). Это физическая
система, которой следует управлять. Управление подразумевает
модификацию и формирование требуемого поведения управляемого оборудования, вне зависимости от внешних (неконтролируемых)
воздействий. Управляемое оборудование представляет собой: запускаемую ракету, спутник, группировку спутников, манипулятор,
подвижный робот (rover), лабораторное или другое оборудование
аналогичного назначения.
Система управления (control system). Часть управляемой системы, разработанная для придания оборудованию свойств управляемости. Включает в себя устройство управления, датчики и устройства управления.
Устройство управления (controller). Компонент, разработанный для придания оборудованию специфицированных функций.
Устройство управления взаимодействует с оборудованием посредством датчиков (sensor) и устройств управления (actuator). В самом
общем случае устройство управления включает в себя аппаратное
обеспечение, программное обеспечение и действия обслуживающего персонала. Система управления может быть реализована на
35
компонентах, распределенных между космическим и наземным
сегментами управляемой системы.
Устройство управления (actuator). Устройство или система,
которая преобразует команды от системы управления в физические
воздействия на управляемое оборудование.
Датчик (sensor). Устройство, которое измеряет какой-либо параметр и представляет их в виде сигнала обратной связи для системы управления.
Описанный выше набор понятий относится к аппаратной составляющей систем управления. Как таковое, управление осуществляется системой управления с использованием математической модели.
Этот круг понятий стандартом определяется следующим образом.
Математическая модель (mathematical model). Представляет
собой математическое описание поведения оборудования, составляющих системы управления или окружающей среды. Математическая модель включает в себя алгоритмы, формулы и параметры.
Состояние (state). Набор переменных или параметров, описывающих динамическое поведение управляемой системы в данный
момент времени. Описывается вектором состояния системы, и этот
термин тоже может быть использован. Состояние может быть истинным (true), требуемым (reference), желаемым (desired), измеренным (measured), или оцениваемым (estimated).
Истинное состояние (true state). Вектор, определяющий текущее состояние системы и окружающей среды. Этот состояние всегда неизвестно.
Оцениваемое состояние (estimated state). Вектор, описывающий оценку системой управления состояния управляемой системы
и окружающей среды.
Требуемое состояние (reference state). Вектор, описывающий
требуемое состояние управляемой системы.
Оцениваемое состояние (measured state). Вектор состояния,
полученный посредством измерения с использованием датчиков и
устройств управления.
Пример информационных связей для типовой структуры системы
управления приведен на рис. 1.10. С точки зрения теории систем управления эта структура обеспечивает выполнение базовых функций:
определение текущего или прогнозирование желаемого состояния системы;
определение текущего или прогнозирование оцениваемого состояния системы;
выработку команд управления.
36
Ÿ¾Ä¹¾ÅǾ
EFTJSFE
«É¾ºÌ¾ÅǾ
ÊÇÊËÇØÆÁ¾
SFGFSFODF
§Èɾ½¾Ä¾ÆÁ¾Ë¾ÃÌÒ¾¼Ç
»¾ÃËÇɹÊÇÊËÇØÆÁØ
ÊÇÊËÇØÆÁ¾
ÁÄÁÇϾÆÁ»¹¾ÅǼÇ
»¾ÃËÇɹÊÇÊËÇØÆÁØ
›ÔɹºÇËù
»Êľ½Ì×ÒÁ¾ÅÇžÆËÔ
ÃÇŹƽ
»É¾Å¾ÆÁ
ÌÈɹ»Ä¾ÆÁØ
£ÇŹƽÔ
ÌÈɹ»Ä¾ÆÁØ
§Ï¾ÆÁ»¹¾ÅǾ
FTUJNBUFE
ÊÇÊËÇØÆÁ¾
ª¡ª«ž¥™
¬¨©™›¤ž¦¡¸
§Ï¾Æù˾ÃÌÒ¾¼Ç
ÁÄÁ
ºÌ½ÌÒ¾¼Ç
ÊÇÊËÇØÆÁØ ¡ÀžɾÆÆǾ
NFBTVSFE
ÊÇÊËÇØÆÁ¾
ªÁ¼Æ¹Ä
ǺɹËÆÇÂ
Ê»ØÀÁ
ÊÇÊËÇØÆÁ¾
Рис. 1.10. Информационная структура системы управления
Как правило, современные системы управления имеют компонент, обеспечивающий интерфейс пользователя с устройством
управления. Для этого компонента используется MMI (man-machine
interface). В текущей версии стандарта этот компонент не нашел
отражения в явном виде.
§4. Командная и телеметрическая информация
В системе европейских стандартов существенное внимание уделено принципам организации сбора, формирования и передачи
телеметрической информации с борта космического аппарата на
наземный пункт управления, а также передача команд на борт космического аппарата.
Стандарт ECSS-E-ST-70-01С, выпущенный в 2010 году, вводит
концепцию системы бортовой регистрации (on-board control
procedure system – OBCP system), которая уже началась использоваться на практике в европейских космических проектах.
Система бортовой регистрации определяется как набор средств
для создания, передачи и выполнения на борту космического аппарата программного компонента, обеспечивающего сбор телеметрических данных о текущем состоянии оборудования. Реализация концепции OBCP предполагает по возможности максимально
полную независимую реализацию этой подсистемы от остального
37
бортового программного обеспечения. При этом предъявляются
требования к обеспечению легкой загрузки, выполнения и замены
этого компонента.
Концепция OBCP, вводимая стандартом ECSS-E-ST-70-01С,
подразумевает:
обеспечение нужд всех категорий пользователей, под которыми
понимаются системные инженеры, инженеры службы поддержки
бортового программного обеспечения, инженеры AIT (Assembly,
Integration,Testing) инженеры службы эксплуатации;
независимость цикл разработки этой подсистемы от цикла разработки остального бортового программного обеспечения;
совместимость с требованиями стандартов ECSS-E-70-41 и ECSSE-ST-70-31.
Стандарт ECSS-E-ST-70-31 определяет требования к данным,
которые предоставляются потребителю. Набор этих данных обеспечивает возможность выполнения операций обеспечения всего
жизненного цикла космического аппарата: сборки, тестирования и
эксплуатации.
Сбор и передача этих данных обеспечивается специализированным программным обеспечением подсистемы OBCP. OBCP состоит
из набора программных компонентов двух типов: OBAP и OBOP.
OBAP (On-Board Application Procedures ) – это подсистемы, которые включают в себя часть функций космического аппарата, и, в этом
смысле, являются его составной частью. В этом смысле приемка космического аппарата подразумевает наличие всех используемых процедур сбора данных. При этом делается оговорка, что после приемки
эти процедуры ( в соответствии с концепцией) могут быть обновлены.
OBOP (On-Board Operation Procedures ) – это подсистемы, которые используются при эксплуатации космического аппарата, но не
требуются при его приемке.
Стандарт ECSS-E-70-41. Полное оригинальное название стандарта – «Space engineering. Ground systems and operations-telemetry
and telecommand packet utilization». Этот стандарт специфицирует
способы реализации пакетов данных, содержащих команды удаленного управления и телеметрические данные, используемые для
мониторинга и дистанционного управления подсистемами космического аппарата и его полезной нагрузки. Это один из наиболее
проработанных и детальных стандартов европейского космического агентства. Ниже приводится краткий обзор лишь ряда положений этого стандарта, имеющих непосредственное отношение к теме
учебного пособия.
38
Структура стандарта включает в себя описание используемой
концепции управления, которая включает в себя все базовые требования к мониторингу и управлению аппаратом во время его сборки, тестирования и эксплуатации. В стандарте определяется набор
сервисов, обеспечивающих все эти операции.
Сервис (service) определяется как набор функций, реализуемых
на борту космического аппарата и предоставляемых пользователю.
Реализация этого набора функций должна осуществляться и мониторироваться пользователем посредством определяемых запросов
на реализацию выбранной функции и отчетов по результатам реализации.
Детальное описание сервисов включает в себя структуру содержания информационных пакетов, используемых для передачи команд управления и получения телеметрической информации.
Принципы формирования и передачи телеметрической информации. Космический аппарат в качестве телеметрической информации о текущем состоянии оборудования (housekeeping report)
должен передавать на наземный пункт управления пакет соответствующих данных. Содержание пакета данных, его структура и частота передачи определяются производителем космического аппарата. Критерии выбора этих параметров должны гарантировать получение полной и однозначной информации с частотой, согласованной с временными параметрами контура управления аппаратом.
В нормальных режимах эксплуатации пакеты с телеметрической
информацией должны посылаться с заданным периодом. Для этого в канале передачи данных с аппарата на наземный пункт управления должны быть зарезервированы необходимые ресурсы. При
этом следует подчеркнуть, что надежность передачи команд и данных обеспечивается за счет использования процедур помехоустойчивого кодирования, определяемых отдельным стандартом. Выполнение этого естественного требования в условиях интенсивных
электромагнитных помех, характерных для условий эксплуатации
космических аппаратов, приводит к существенному увеличению
объема передаваемой информации. С учетом этого обстоятельства в
стандарте рассматривается ряд механизмов, обеспечивающих снижение требований к каналу передачи информации.
Как правило, наземный пункт управления заинтересован лишь
в получении информации об изменении текущего состояния. В соответствии с этим в стандарте предусмотрен дополнительный режим передачи телеметрических данных, в котором посылка конкретных данных из пакета осуществляется при наличии измене39
ний. Стандарт определяет процедуры фильтрации и установления
порогов изменений с целью устранения шума при измерении аналоговых параметров.
В дополнение к режиму периодической посылки телеметрических
данных в стандарте предусмотрена посылка данных о существенных
событиях, зарегистрированных на борту космического аппарата, например фиксации отказов в работе тех или иных систем. Этот тип сообщений носит название «сообщения о событиях» (event reporting).
В него входят также сообщения и о прохождении некоторых определенных точек в реализации той или иной команды. Такой способ
передачи информации требует существенно меньших ресурсов.
Еще одним механизмом является передача статистических параметров проведенных измерений (statistical data reporting). Использование этого способа подразумевает передачу статистических
оценок измерений контролируемых параметров, таких как математическое ожидание, минимальное и максимальное значение,
стандартное отклонение.
В заключение следует отметить, что за последние десять лет
сформировался и стремительно развивается сегмент беспилотных
авиационных комплексов разнообразного назначения [10]. Для
этого направления техники в качестве отправной точки представляется целесообразным использовать модели и структуры подсистем сбора телеметрической информации, описанные в стандарте
ECSS-E-70-41.
Контрольные вопросы и задания к главе 1
1. Опишите особенности эксплуатации систем управления космических аппаратов.
2. Опишите ключевые особенности разработки цифровых систем
управления космическими аппаратными комплексами.
3. Проведите сравнение структур систем управления для станции «Луна-16» и марсоходов Spirit-Opportunity.
4. Оцените количество каналов управления, каналов сбора данных в системе управления марсохода Spirit-Opportunity.
5. Опишите способы обеспечения надежности в описанных космических аппаратах.
6. Какие принципы робототехники Айзека Азимова и с какими
приоритетами использованы при построении системы управления
марсоходами ?
40
7. Что дает использование вейвлет-сжатия в канале передачи
данных с марсохода?
8. Какова цель стандартов страхования Q-XX ECSS?
Литература к главе 1
1. Википедия – http://ru.wikipedia.org/wiki/ Спутник-3.
2. Байконур – http://space-russia.narod.ru/doc/suttelit.html
3. ГУП «Завод им. Калинина» – http://www.zik-spb.ru/paper/
Gaz10-11_2010.pdf
4. Википедия – http://ru.wikipedia.org/wiki/ Соколов Тарас
Николаевич.
5. НПО «Импульс» – http://npo-impuls.ru /Беседа с доцентом
Политехнического университета Ф. А. Васильевым.
6. Википедия – u.wikipedia.org/wiki/Восток-1.
7. НПО «Молния» – http://npo-molniya.ru/content/ первыепилотируемые-космические-корабли-восток-и-восход-часть-3.
9. http://space-horizon.ru/articles/16 Создание космического
корабля Восток.
10. КОМПЬЮТЕРРАONLINE – http://www.computerra.ru/
own/604530/ Предок HAL 9000: компьютер первого космического
корабля.
11. Онлайн библиотека – http://www.erlib.com/Черток Б.Е. /
Ракеты_и_люди.
12. Википедия – http://www.google.ru/Луна-16
13. http://znaniya-sila.narod.ru/ Полеты к Луне автоматических аппаратов.
14. http://www.planetology.ru/Космические аппараты для исследования Луны.
15. http://cosmopark.ru/luna16_m.html АМС ЛУНА-16
16. GALSPACE http://galspace.spb.ru/index90.file/luna.html.
17. A Lossy Image Compression and Stereo Ranging Quality from
Mars Rovers / A. Kiely, A. Ansar, A. Castano, M. Klimesh, J. Maki.
IPN Progress Report 42-168 February 15, 2007.
18. Kiely A., Klimesh M. The ICER Progressive Wavelet Image
Compressor. IPN Progress Report 42(155), November 15, 2003.
19. ICER-3D: A Progressive Wavelet-Based Compressor for
Hyperspectral Images / A. Kiely, M. Klimesh, H. Xie, N. Aranki. IPN
Progress Report 42-164 February 15, 2006.
20. Biesiadecki J. J., Maimone M. W. The Mars Exploration Rover
Surface Mobility Flight Software: Driving Ambition, March 2006.
41
IEEE Aerospace conference proceedings, Big Sky, Montana, USA,
March 2006.
21. Biesiadecki J., Leger C., Maimone M. Tradeoffs Between
Directed and Autonomous Driving on the Mars Exploration Rovers.
Proc. 2005,International Symposium of Robotics Research, San
Francisco CA, 12–15 October, 2005.
22. Mark Maimone, Yang Cheng and Larry Matthies. Two Years
of Visual Odometry on the Mars Exploration Rovers. Jet Propulsion
Laboratory, California Institute of Technology, Pasadena, CA USA.
23. Todd E., Litwin, Justin N., Maki J. Imaging Services
Flight Software on the Mars Exploration Rovers. Proc. 2005 IEEE
International Conference on Systems, Man and Cybernetics Waikoloa,
Hawaii,October 10–12, 2005.
24. T. Glenn Tsuyuki, Arturo Avila, Henry I. Awaya, Robert J. Krylo,
Keith S. Novak, and Charles J. Phillips. Mars Exploration Rover:
Thermal Design is a System Engineering Activity. SAE 041 ICES-331,
Jet Propulsion Laboratory, California Institute of Technology.
25. Keith S. Novak, Gary M. Kinsella, Robert J. Krylo, and Eric T.
Sunada. Thermal Design and Flight Experience of the Mars Exploration
Rover Spacecraft Computer- Controlled, Propulsion Line Heaters. Jet
Propulsion Laboratory, California Institute of Technology.
26. Современные тенденции построения систем управления дистанционно-пилотируемыми летательными аппаратами/
А. М. Астапкович, А. Л. Анисимов, А. Г. Елисеенко, И. О. Суханов //
Информационно-управляющие системы для подвижных объектов.
СПб.: Политехника, 2002. С. 3–32.
42
Глава 2. АППАРАТНОЕ ОБЕСПЕЧЕНИЕ
СИСТЕМ УПРАВЛЕНИЯ
В Париже в 1900 году на Международном математическом конгрессе знаменитый математик Давид Гильберт представил список
нерешенных проблем. В этом списке второй значилась задача доказательства непротиворечивости системы аксиом обычной арифметики, формулировку которой в дальнейшем Гильберт уточнил.
Уточненная формулировка заключалась в постановке задачи нахождения общего метода, который позволил бы определить, «выполнимо ли данное высказывание на языке формальной логики,
т. е. установить его истинность».
Алан Тьюринг впервые в 1936 году получил ответ: проблема
Гильберта оказалась неразрешимой. Результаты работы он описал
в своей знаменитой статье, датированной 1937 годом [1].
В работе было введено четкое определение понятия «метод». Отталкиваясь от интуитивного представления о методе как о некоем
алгоритме, т. е. процедуре, которая может быть выполнена механически без творческого вмешательства, Тьюринг теоретически показал, как эту идею можно воплотить в виде подробной модели вычислительного процесса. Полученная модель вычислений, в которой каждый алгоритм разбивался на последовательность простых,
элементарных шагов, и была логической конструкцией, названной
впоследствии «машиной Тьюринга».
Тьюринг стал первым, достигшим понимания универсальной
природы вычислительной машины. Он показал, что можно построить универсальную машину, способную работать так же, как
любая простая машина Тьюринга, если в нее ввести описание этой
простой машины.
Эта идея послужила отправной точкой при разработке универсальных вычислительных систем, эволюция которых привела к появлению систем управления встраиваемого класса.
2.1. Структура систем управления
Базовый принцип построения современных вычислительных
систем заключается в использовании магистрально-модульных
структур. В соответствии с этим принципом вычислительная система состоит из специализированных модулей объединенных
информационно-управляющей магистралью. Управление конкрет43
ным устройством при таком подходе требует наличия в составе
системы модулей логического управления, которые генерируют
временные управляющие воздействия для устройств управления.
Устройства управления иногда называют устройствами сопряжения с объектом.
При таком разделении по функциям модули, вырабатывающие
сигналы логического управления, ничем не отличаются от остальных модулей вычислительной системы. С логической точки зрения
аналогичным образом реализуется и абстрагирование входных сигналов с датчиков и терминальных устройств управления.
Модули, обеспечивающие ввод информации с датчиков и
устройств управления, а также выработку логических сигналов
управления, называются портами. Соответственно, порты могут
быть входными или выходными. Физически это отдельные модули, а логически они описываются как адресуемые регистры. На
этом уровне рассмотрения система управления в принципе не отличается от вычислительной системы, но должна рассматриваться как система, выполняющая обработку информации в реальном
масштабе времени.
В соответствии с этим, обработка информации выполняется
пошагово в соответствии с предписанным алгоритмом. Алгоритм
обработки представляется как описание последовательности операций, выполняемых с данными, получаемыми с входных портов
системы. Пошаговое описание алгоритма обработки данных описывается специальным образом и называется программой. Сигналы
логического управления представляют собой значения, которые записываются в выходные порты системы управления в соответствии
с реализуемым алгоритмом.
Конфигурирование и управление портами осуществляется аналогичным образом, для чего конфигурационные и управляющие
регистры портов имеют соответствующую логическую адресацию.
§1. Понятие архитектуры
Для укрупненного описания структур в электронике используют блок-схемы. Структура вычислительной системы определяется
реализуемой концепцией и оказывает существенное влияние на используемые способы обработки данных. Чтобы отразить эту взаимосвязь используется термин «архитектура», который является
более широким понятием, чем блок-схема.
44
Архитектура вычислительной системы. Представляет собой
описание общей логической организации вычислительной системы, согласованной со способом представления данных. Архитектура системы определяет общие принципы реализации программного
обеспечения и его взаимодействия с аппаратными компонентами
системы.
Описание операции представляет собой описание конкретного
типа арифметической или логической операции, описание адреса данных, которые должны быть использованы при выполнении
данной операции и адрес, куда должен быть помещен результат выполненной операции. Описание набора операций называют командами. Набор команд является характерной особенностью конкретного варианта реализации вычислительной структуры.
Один шаг работы при реализации алгоритма заключается в чтении описания очередной выполняемой команды, чтении данных из
памяти по адресам, указанным в команде, выполнении предписанной операции и записи результата по указанному в операции адресу.
В результате выполнения предписанной последовательности операций по заданным адресам памяти данных оказывались результаты
вычислений. Таким образом, память данных используется для хранения как исходных данных, так и результатов вычислений.
Универсальность описанной структуры обеспечивается за счет
раздельного описания алгоритма и используемых данных. Машина
с такой структурой может использовать один и тот же алгоритм для
обработки данных и имеет возможность реализовывать различные
алгоритмы при условии, что имелась возможность изменить описание алгоритма (исполняемой последовательности команд).
Гарвардская архитектура. Архитектура этого типа универсальной вычислительной системы показана на рис. 2.1. Последова-
™ÉÁÍžËÁоÊÃÇ
ÄǼÁоÊÃǾ
ÌÊËÉÇÂÊË»Ç
"-6
šÄÇÃ
ÌÈɹ»Ä¾ÆÁØ
¨¹ÅØËÕ
½¹ÆÆÔÎ
¨¹ÅØËÕ
ÈÉǼɹÅÅ
¬ÊËÉÇÂÊË»Ç
»»Ç½¹»Ô»Ç½¹
Рис. 2.1. Гарвардская архитектура
45
тельность операций, представляющая собой описание алгоритма,
упорядочена и размещается в памяти программ. Используемые
данные также упорядочены и размещаются в памяти данных. Раздельное хранение программы и данных является характерной особенностью гарвардской архитектуры.
Гарвардская архитектура широко используется в сигнальных
микропроцессорах, представляющих собой специализированные
устройства для цифровой обработки сигналов. Примеры сигнальных процессоров: Texas Instruments TMS320C6201, Analog Devices
ADSP-TS001, Motorola DSP96002, Intel PXA 800.
С середины 90-х годов прошлого века эта архитектура начала использоваться в микроконтроллерах, предназначенных для реализации малогабаритных систем управления встраиваемого класса.
Эта архитектура служит основой для очень популярных микроконтроллерных платформ, развиваемых фирмами Microchip и Atmel.
Архитектура фон Неймана. Параллельно с Гарвардским университетом аналогичная по назначению система разрабатывалась в
Принстонском университете под руководством фон Неймана.
Структура машины фон Неймана, изображенная на рис. 2.2,
с технической точки зрения была более универсальна, по сравнению с гарвардской архитектурой, что достигалось объединением
памяти данных и памяти программ. При разработке программы
это позволяло произвольным образом разделить память на память
программ и память данных в зависимости от специфики решаемой
задачи. Соответственно, обмен между блоками и общей памятью
осуществляется по одному каналу. В современной терминологии
канал обмена данных принято называть шина (bus).
¨¹ÅØËÕ
½¹ÆÆÔÎ
¯¾ÆËɹÄÕÆÔÂÈÉÇϾÊÊÇÉ$16
™ÉÁÍžËÁоÊÃÇ
ÄǼÁоÊÃǾ
ÌÊËÉÇÂÊË»Ç
"-6
šÄÇÃ
ÌÈɹ»Ä¾ÆÁØ
ÃÇŹƽÔ
Á½¹ÆÆÔ¾
¬ÊËÉÇÂÊË»¹
»»Ç½¹»Ô»Ç½¹
¹½É¾Ê
¨¹ÅØËÕ
ÈÉǼɹÅÅ
Рис. 2.2. Архитектура фон Неймана (принстонская)
46
Так как элементная база на начальном этапе развития вычислительной техники была дорога, это, казалось бы, незначительное усовершенствование обеспечивало возможность использовать
одну и ту же машину для обработки двух, в некотором смысле,
полярных классов задач: «много данных – простой алгоритм» и
«мало данных – сложный алгоритм». Эти соображения привели
к тому, что архитектура фон Неймана стала повсеместно использоваться.
Сравнение принстонской и гарвардской архитектур. Первые
реализации универсальных вычислительных машин строились на
блочной основе и были очень громоздки и ненадежны из-за применения электровакуумных ламп в качестве логических элементов.
Они применялись для решения научно-технических задач, требующих большого объема рутинных вычислений. Соответственно,
базовым параметром, по которому велось их сравнение, являлась
скорость вычислений. Эти машины использовали принстонскую
архитектуру.
Скорость вычислений существенным образом зависит от используемых логических элементов, структуры блока вычислений и достижимых скоростей выборки и обработки команд. Эти скорости
определяются используемыми тактовыми частотами и, в конечном
счете, ограничиваются сверху линейными размерами логических
элементов, т. е. технологией.
Широкое использование гарвардской архитектуры в современных микроконтроллерах обусловлено двумя причинами.
Гарвардская архитектура обеспечивает возможность, по крайней мере, двукратного повышения производительности по сравнению с принстонской архитектурой без увеличения частоты микропроцессора. Эта возможность обуславливается возможностью
параллельного считывания команд из памяти программ и чтения
(записи) данных.
Гарвардская архитектура сложнее в реализации, чем принстонская. Этим объяснялось ее использование в сигнальных процессорах, для применений в которых ценовой фактор не являлся определяющим. Потребовалось несколько десятилетий развития технологий, чтобы обеспечить возможность создания микроконтроллеров с
достаточно большими объемами памяти программ и данных, располагающихся на кристалле, выпуск которых был бы экономически
оправдан при ориентации на рынок бытовых изделий. В настоящее
время технологический барьер преодолен, что и предопределяет
широкое распространение этого типа архитектуры.
47
§2. Микропроцессор Intel 4004
Развитие вычислительных систем принято датировать поколениями. Эта хронология, в первую очередь, привязывается к типу
используемой элементной базы. Начиная с четвертого поколения,
технологические возможности обеспечили создание миниатюрных
вычислительных систем. Отправной точкой принято считать появление микропроцессора Intel 4004.
Детальное рассмотрение его архитектуры позволяет рассмотреть
ряд существенных деталей реализации вычислительных систем.
Микропроцессор (microprocessor). Специализированная микросхема, которая обеспечивает возможность выполнения сложной обработки данных с помощью алгоритмов, описываемых программным способом. Для вычислительных и управляющих систем,
реализуемых на микропроцессорах, данные и описание программы
их обработки хранятся в отдельных микросхемах памяти. Эта информация представляется в двоичном виде и хранится в упорядоченном виде. Для работы с ней (чтение, запись) требуется использование адреса.
В различных архитектурах и для различных команд используются разные алгоритмы чтения команд и данных, их обработки и
хранения результатов, реализуемые электронными компонентами
микропроцессора.
Адресная информация и данные в процессе обработки представляются в двоичном виде и хранятся в регистрах микропроцессора.
Регистры представляют собой цифровую электронную схему, служащую для хранения двоичных чисел, разрядность которых зависит от принятых архитектурных решений.
Обработка команд реализуется циклическим образом. Временной отрезок, за время которого производится обработка одной команды, называется командным циклом. Командный цикл формируется из некоторого количества одинаковых интервалов, величина
которых зависит от используемой частоты тактового генератора.
Арифметически-логическое устройство (Arithmetic Logical
Unit – ALU). Также используется аббревиатура CPU (Central
Processing Unit). Базовый компонент вычислительной системы
или системы управления, обеспечивающий выполнение арифметических и битовых операций (сложение, вычитание, умножение, деление, сдвиг и т. п.), операций сравнения (больше, меньше и т. п.)
и логических операций (И, ИЛИ, НЕ) с передачей управления на
заданный адрес.
48
Шина (bus). Совокупность аппаратных решений, обеспечивающих информационный обмен между блоками вычислительноинформационной системы.
В отличие от связи точка-точка к шине можно подключить несколько устройств, которые будут использовать одни и те же проводники для обмена информацией. Различают параллельные и
последовательные шины, разделяемые по способу представления
передаваемой информации.
В параллельных шинах информация передается одновременно,
и каждому биту слова передаваемой информации соответствует
свой проводник. Количество одновременно передаваемых разрядов
соответствует количеству проводников в шине и называется шириной или разрядностью шины. По функциональному назначению
проводники в шине используются для передачи двоичного представления адреса (адресная шина), передачи данных (шина данных) и передачи команд управления (шина управления). На практике используют и обобщенное название «шина», включающее в
себя эти три компонента.
В последовательных шинах используется малое количество проводников (2–4) и последовательный способ передачи битов информации за счет временного разделения. Для организации временного разделения битов и информационных посылок используются
отдельно передаваемые тактирующие сигналы или сигналы специальной формы, например старт и стоп биты.
Арбитраж шины. Совокупность аппаратно-программных решений, обеспечивающих бесконфликтный обмен информацией
между устройствами, соединенными шиной. Наиболее распространены шины с временным разделением и случайным доступом.
В шинах с временным разделением разграничение доступа к
шине осуществляет мастер-устройство (master), соответственно,
остальные устройства называются слэйв-устройствами (slave).
В русскоязычной литературе для этого употребляются термины ведущее и ведомое устройства.
Случайный доступ широко используется в сетевых (распределенных) информационных системах. В таких сетях все устройства
равноправны.
Микропроцессор Intel 4004. Появление микропроцессоров относят к четвертому поколения средств вычислительной техники.
До этого при производстве систем обработки информации использовались так называемые микропроцессорные комплекты, представлявшие собой набор микросхем, совместимый по логической и
49
аппаратной реализации. На базе этих комплектов производились
вычислительные системы, интегрируемые в единое целое на печатных платах.
Микропроцессор Intel 4004 изначально был ориентирован на
рынок гражданской продукции и предназначался для калькуляторов, разрабатываемых японской фирмой Busicom. Для реализации
калькулятора с требуемыми характеристиками требовалось использование 16 интегральных схем. Революционным было решение Intel разработать вместо них одну интегральную схему, которая и была названа микропроцессор. Эта разработка на многие годы
определила тенденции развития электронной индустрии, одним из
лидеров которой стала фирма Intel. По сути, до разработки этого
первого микропроцессора фирма Intel была лишь разработчиком и
производителем схем памяти.
Первый микропроцессор был выпущен в свободную продажу
корпорацией Intel в 1971 году. С этого события был начат отсчет
поколениям микропроцессоров.
Параметры и особенности архитектуры микропроцессора Intel
4004:
2250 транзисторов, реализованных с применением 10-микронной технологии;
рабочая частота 92–200 кГц;
команда выполнялась за восемь тактов (60000 операций /с);
8-битная структура с 4-битной реализацией внутренней шины,
по которой передавались 12-битные адреса, 8-битные команд,
4-битные данные;
46 команд;
трехуровневый стек (максимальная вложенность подпрограмм –
3);
16 ножек в корпусе DIP16;
стоимость 100 долларов.
Разработка микропроцессора обеспечила Intel лидерство в области микроэлектроники по многим причинам, но главные из них
две, и они не были столь очевидны на момент принятия решения о
начале разработки.
Во-первых, интеграция в одном чипе сложного электронного
устройства оказалась экономически выгодной по сравнению с реализацией на печатных платах с использованием микропроцессорных комплектов, требующих больших трудозатрат. Эта тенденция
работает уже на протяжении более 40 лет и количественно описывается законом Мура.
50
Во-вторых, ориентация на широкий рынок бытовых вычислительных устройств обеспечивала экономическую эффективность
предлагаемого решения. До этого вычислительные устройства этого класса использовались в дорогостоящих изделиях для больших
вычислительных машин или в изделиях военного назначения.
Бизнес-модель для такого класса изделий описывается формулой
«малый тираж – большая стоимость». Ориентация на бытовые применения требует другой формулы «большой тираж – малая стоимость». Этот переход был осуществлен благодаря японскому заказчику.
Следует указать, что фактическое соотношение рынка гражданской и военной продукции на начало 21 первого века описывалось
соотношением 95:5. Соответственно, гражданский сектор определяет уровень развития технологий обработки сигналов.
Архитектура микропроцессора Intel 4004. Рассмотрим на
примере указанного микропроцессора особенности организации
обработки данных в цифровых вычислительных системах.
Архитектура микропроцессора показана на рис. 2.3. Микропроцессор использовал раздельную память программ и данных
(признак гарвардской архитектуры), но передача 12-битных адресов, 8-битных команд и 4-битных данных производилась по одной
мультиплексированной 4-битной шине. Это потребовало организации временного разделения и соответствующего управления.
Память программ, память данных и схема тактирования являются внешними компонентами. На вход микропроцессора подаются сигналы тактирования, которые используются блоком тактирования и управления. Этот блок обеспечивает синхронизацию работы всех составляющих микропроцессора. Для этого используется
третья шина – шина управления.
Выполнение каждой команды в микропроцессоре осуществлялось за 8 тактов. Номер обрабатываемой команды хранится в отдельном регистре. Начальное значение номера обрабатываемой команды равно 0. Это значение изменяется либо схемой управления,
либо ALU при обработке команды передачи управления на заданный адрес памяти программ.
Из памяти программ по шине данных производится считывание команды с соответствующим номером. Временную последовательность выдачи в шину адреса и получения текущей команды
реализует схема управления. Декодер команд выделяет код операции и адреса данных, над которыми эта операция должна быть выполнена.
51
ºÁËƹØ
½»ÌƹÈɹ»Ä¾ÆƹØ
ÑÁƹ%%
šÌ;ÉÑÁÆÔ
½¹ÆÆÔÎ
›ÆÌËɾÆÆØغÁËƹØÑÁƹ½¹ÆÆÔÎ
›É¾Å¾ÆÆÔÂ
ɾ¼ÁÊËÉ
©¾¼ÁÊËÉ
¹ÃÃÌÅÌÄØËÇÉ
©¾¼ÁÊËÉ
ÍĹ¼Ç»
"-6
ªÁ¼Æ¹ÄÔÌÈɹ»Ä¾ÆÁØ
ȹÅØËÕ×ÈÉǼɹÅÅÁ
½¹ÆÆÔÎ
©¾¼ÁÊËÉ
ÃÇŹƽ
*OTUSVDUJPO
SFHJTFS
¾Ãǽ¾É
ÃÇŹƽ
*OTUSVDUJPO
EFDPEFS
ºÄÇÃ
˹ÃËÁÉÇ»¹ÆÁØ
ÁÌÈɹ»Ä¾ÆÁØ
¥ÌÄÕËÁÈľÃÊÇÉ
.VMUJQMFYFS
ªÐ¾ËÐÁÃ
ÃÇŹƽÁÊËÖÃ
QSPHSBN
DPVOUFS1$
BOETUBDL
ªÁ¼Æ¹ÄɾÊ˹É˹
3FTFU
*0QPSUT
ªÁ¼Æ¹Ä
˹ÃËÁÉÇ»¹ÆÁØ
$MPDL
Рис. 2.3. Архитектура микропроцессора Intel 4004
Аналогично командам эти данные по той же шине считываются
из памяти данных. Для направления данных и команд в нужные
блоки микропроцессора используется мультиплексор.
Считанные по этим адресам данные обрабатываются в соответствии с кодом операции с сохранением результатов в регистреаккумуляторе и временном регистре. При выполнении арифметических операций результат записывается в адрес, определяемый
параметрами и операндами команды. Схемой управления осуществляется инкрементирование счетчика команд и командный цикл
повторяется. Состояние ALU после выполнения команды описывается битами регистра флагов.
Если операция относится к классу логических, то по завершении действий с данными производится изменение значения счет52
чика команд в соответствии с параметрами этой команды. Соответственно, в следующем командном цикле производится считывание
команды, находящейся по этому адресу.
Работа с ALU производится через вспомогательный регистр, обеспечивающий сохранение промежуточных результатов вычислений. Этот регистр называется регистр-аккумулятор и представляет
собой дополнение к основной памяти данных.
Как правило, алгоритм содержит блоки операций, которые используются многократно с разными данными и в разных местах программы (например, рассчитать cos(x), отобразить число display(d) и
т. п.) Для обеспечения возможности многократного использования
одних и тех же операций по обработке данных используются подпрограммы, которые представляют собой способ экономии памяти
программ.
Вызов подпрограммы осуществляется специальной командой
передачи управления на нужный адрес. Данные, подлежащие обработке этой подпрограммой, должны быть предварительно записаны по нужным адресам. По завершении выполнения подпрограммы осуществляется вызов команды, следующей за номером
команды, содержавшей вызов.
Сложные программы обработки могут потребовать вложенных
вызовов подпрограмм. В этом случае для корректного возврата к
месту начального вызова требуется сохранения адресов вызывающих подпрограмм. Для этого используется специальный блок,
называемый стэком. Глубина стэка у микропроцессора Intel 4004
была равна трем, что и определяло глубину вложенности.
Регистр флагов предназначен для описания особенностей выполнения конкретной команды. Например, при выполнении деления
на ноль из-за ошибки в программе выполнение следующих команд
прерывается, и в регистре флагов выставляется соответствующий
бит, сигнализирующий об ошибке. Анализ содержания регистра
флагов позволяет выявить причину остановки и найти ошибку в
программе или использованных данных. Эта составляющая первого микропроцессора эволюционировала в компонент ядра современных микропроцессоров и микроконтроллеров, называемый
контроллер прерываний. Контроллеры прерываний являются
ключевым элементом встраиваемых систем управления реального
времени. Кроме обработки исключительных ситуаций (exceptions),
контроллеры прерываний обеспечивают синхронизацию работы
модулей ядра и периферии, например таймеров, модулей аналогоцифрового преобразования и т. п.
53
§3. Законы Мура и Амдала
На основании имевшейся у него статистики один из основателей
корпорации Intel и ее технический директор Гордон Myр (Gordon
Moore) в 70-x годах прошлого столетия сделал прогноз, что количество транзисторов в интегральных схемах будет возрастать вдвое,
каждые 24 месяцев [2]. Это соотношение, известное как закон
Мура, остается справедливым уже 40 лет.
Базовые параметры микропроцессоров Intel, которые иллюстрируют эту закономерность, представлены на рис. 2.4 и в табл. 2.1.
Таблица 2.1
Параметры микропроцессоров Intel
Линейный Частота,
Производительразмер,
Мгц
ность, МIPS
микрон
Год
Количество
транзисторов
1971
1974
1979
1982
1985
1989
1993
1997
1999
2000
2250
5000
29000
120 000
275 000
1 180 000
3 100 000
7 500 000
24 000 00
42 000 000
10
6
3
1,5
1,5
1
0,8
0,35
0,25
0,18
0,09–0,2
2–3
4–10
6
12–16
16–150
60–66
233–300
450
1400
2003
410 000 000
0,13
1300–1600
2006
1000 000 000
0,09
1300–1600
0,06
0,9
Процессор
4004
8080
8086
80286
80386
80486
Pentium
Pentium II
Pentium III
Pentium IV
Itanium 2
Madison
Itanium 2
Montecito
Анализ этих данных показывает, что кривая с рис. 2.4, отображающая количество транзисторов на кристалле после 1995 года,
претерпевает излом. И современная версия закона Мура гласит,
что количество транзисторов на кристалле удваивается каждые восемнадцать месяцев.
Следует указать на поворотный пункт в развитии архитектур
микропроцессоров, который знаменовался выпуском первого двуядерного микропроцессора Itanium c кодовым названием модели
Montecito, который был отгружен заказчику в июле 2006 года.
Данный микропроцессор обеспечивает увеличение производительности в 2 раза по сравнению с одноядерным предшественником и
при этом обладает пониженным на 20 %. энергопотреблением.
54
£ÇÄÁоÊË»ÇËɹÆÀÁÊËÇÉÇ»
%VFM$PSF*UBOJVN
*OUFM
*OUFM1FOUJVN**
Рис. 2.4. Иллюстрация закона Мура
Можно констатировать, что в развитии микропроцессоров закончилась эпоха архитектур «System on Chip» и началась новая эра
архитектур «Claster on Chip», знаменующая переход к началу широкого применения параллельных вычислений и сетевых технологий внутри одного кристалла. Такого рода архитектуры относят к
классу многоядерных.
Многоядерный микропроцессор – это вычислительная система,
реализованная на одном кристалле и обеспечивающая скорость обработки данных за счет распараллеливания. Многоядерный микропроцессор использует архитектуру внутренней «распределительной» (arbiter) шины для общего процессорного интерфейса с пропускной способностью до 6,4 Гб/c, предназначенной для управления двумя и более микропроцессорными ядрами.
Производительность этого класса вычислительных систем описывается законом Амдала [3]. Вывод этого закона достаточно прост
и логичен.
Закон Амдала. Пусть в системе с N ядрами решается некоторая
вычислительная задача. При естественном предположении, что
доля f от общего объема вычислений не может быть, в принципе,
распараллелена, а остальная поддается идеальному распараллеливанию без накладных расходов, выигрыш по производительности
по сравнению с решением этой же задачи на одноядерном процессоре составит
55
S ≤ 1/ (f + (1–f)/N) < 1/f.
(2.1)
Выражение (2.1) представляет собой один из вариантов формулировки закона Амдала. С помощью нее построена диаграмма, изображенная на рис. 2.5.
Как следует из выражения (2.1) предельно возможное ускорение, которое способно обеспечить многоядерная архитектура, определяется алгоритмом и равна 1/f и не зависит от того, сколько параллельных ядер имеет микропроцессор. Понятно, что предельный
случай f = 0 не достижим для реальных систем, так как он предполагает отсутствие информационных связей между процессорами.
Закон Амдала недвусмысленно демонстрирует, что прирост эффективности вычислений зависит от алгоритма (т. е. от специфики
решаемой задачи) и ограничен сверху минимальным значением параметра f. Соответственно, не для всякой задачи имеет смысл наращивания числа процессоров или вычислительных ядер. Более
того, если учесть время для передачи данных между узлами вычислительной сети, то зависимость времени вычислений от числа
используемых узлов будет иметь максимум. Это в свою очередь
означает, что с определенного момента добавление новых узлов в
систему приведет к увеличению времени на решение задачи.
Более детальную оценку возможного выигрыша может дать интегральная формулировка этого закона в виде
T
S=∫
0
⎛
1
f (t) ⎞⎟
+ ⎜⎜1 −
⎟dt.
⎜
f (t) ⎝
N ⎠⎟
(2.2)
4/
4/
4/
4/
/
Рис. 2.5. Диаграмма для оценки производительности
многоядерных систем с применением закона Амдала
56
Такая формулировка обеспечивает возможность применения закона к отрезку выполняемой программы, величина которого задается
параметром T. При этом требуется знание динамики распараллеливания, отображаемое динамическим коэффициентом загрузки f(t).
Принцип масштабируемого ускорения. Известен ряд уточнений закона Амдала применительно к параллельным вычислительным системам [3–5]. Так, Густавсон (Gustavson) [4] учел связь между размерностью задачи и размерностью системы и сформулировал
принцип масштабируемого ускорения: размерность (эффективно)
решаемых задач растет с ростом размерности системы.
Технология Tri-Gate. С точки зрения размеров в Intel считается, что транзисторы классической схемы с электродами и затвором между ними можно совершенствовать приблизительно до
2020 года. Соответственно, дальнейшее наращивание возможностей микропроцессоров заключается в использовании новых принципов вычислений.
Но существует и развивается более реалистичная перспектива –
трехмерные многослойные микросхемы. Такие решения предлагал
сам Гордон Мур, а также профессор Стэндфордского университета
Том Ли и некоторые другие исследователи.
Опытные образцы транзисторов с трёхмерным затвором были
получены в научно-исследовательских лабораториях Intel ещё в
2002 году, который считается годом изобретения технологии TriGate. Новую технологию в сочетании с 22-нм техпроцессом планируется внедрить до конца 2011 года и уже на её основе выпускать новые многоядерные процессоры под кодовым названием Ive Bridge.
Трёхмерные транзисторы Tri-Gate, изготовленные на базе 22-нм
техпроцесса и работающие на низком напряжении, обеспечивают
до 37 % более высокую производительность по сравнению с обычными транзисторами, изготовленными на базе 32-нм технологии.
Процессоры с новыми транзисторами могут потреблять менее половины мощности, чем 32-нм чипы с двухмерной структурой, при
том же самом уровне производительности. Поэтому такие чипы
прекрасно подойдут для встраиваемых систем управления носимых устройств, в которых важна не только высокая производительность, но и длительное время автономной работы.
Для портативных устройств особенно важна и миниатюрность,
которую также гарантирует новая разработка: по оценкам специалистов корпорации, на площади, равной площади точки в конце
этого предложения, можно разместить более шести миллионов
транзисторов Tri-Gate, выполненных по 22-нм технологии.
57
§4. Сигнальные микропроцессоры
Появление микропроцессоров обеспечило возможность разработки управляющих компьютеров, ориентированных на использование в многоканальных системах управления. Компьютеры
этого типа называют бортовыми (onboard computer) и их относят
к классу компьютеров для встраиваемых применений (embedded
solutions).
Первые бортовые компьютеры были специализированными и
разрабатывались под конкретный вид управляемого источника. Все
ресурсы встраиваемых компьютеров первых поколений использовались для реализации цифровой обработки входных воздействий
и сложных алгоритмов управления. Эффективность их применения достигалась за счет универсализации этого ключевого компонента систем управления. В свою очередь это привело к созданию
специализированных микропроцессоров для обработки сигналов,
которые называют сигнальными. Для обозначения данного типа
микропроцессоров используется аббревиатура DSP (Digital Signal
Processing). Архитектура сигнального микропроцессора является
расширением канонической структуры вычислительной системы.
Обработка поточной информации в реальном времени обеспечивается за счет использования проблемно-ориентированной архитектуры. В сигнальных процессорах реализуется аппаратная реализация типовых блоков, используемых при цифровой поточной
обработке сигналов.
Реализация обработки данных таким блоком представляет собой
вызов соответствующей команды, параметры которого определяют
вариант конкретной реализации. Специализированную команду
DSP можно трактовать как аппаратную реализацию подпрограммы, фактические параметры которой задаются в виде параметров
команды. По завершении обработки конкретных данных генерируется сигнал прерываний, обработка которого осуществляется
ядром микропроцессора.
Соответственно, сигнальные процессоры имеют расширенную
систему команд. В качестве показательного примера можно указать команду реализации DO-цикла.
Как правило, сигнальные процессоры обеспечивают возможность аппаратной (быстрой) реализации операций с плавающей
запятой, операции умножения, сложения, умножения с накоплением в блоке MAC (multiply and accumulate), суммирования с накоплением, работу с кольцевыми буферами.
58
Кроме этого, структуры сигнального процессора обеспечивают аппаратную поддержку основных операций, необходимых для
цифровой обработки массива дискретных отсчетов входного аналогового сигнала: аналого-цифровое и цифроаналоговое преобразование (АЦП, ЦАП), выполняемое кодеком, организация массива
дискретных отсчетов сигналов в памяти данных, перебор элементов массива в соответствии с выбранной последовательностью индексов с помощью генератора адреса.
Цифровые сигнальные процессоры способствовали появлению
целого ряда новшеств по отношению к каноническим архитектурам и первым микропроцессорам.
Контроллер прерываний. Для синхронизации процесса параллельной обработки служит система управления прерываниями,
иногда называемая контроллером прерываний.
Механизм организации параллельной работы устройств с помощью системы прерываний реализуется следующим образом.
Выполняемая программа передает по системной шине данные,
требующие обработки, на соответствующий модуль. В принципе,
механизм записи или считывания данных в память не отличается
от механизма передачи данных к микросхемам или модулям, подключаемым к системной шине. Для этого все модули имеют адреса
и регистры для приема данных и имеют логику, реализующую доступ к шине.
Ядро микропроцессора, передав данные или команды по соответствующему адресу, освобождается от работы с конкретным модулем и продолжает выполнение программы. Например, посылает
данные на обработку другому модулю.
Получив данные или команды на выполнение тех или иных
действий от центрального микропроцессора, модуль начинает обработку полученной информации. По завершении предписанных
операций вырабатывается управляющий сигнал, поступающий на
контроллер прерываний. Контроллер прерываний фиксирует конкретный модуль, выработавший сигнал прерываний, выставив бит
флага прерываний в регистре источников прерываний, и в свою
очередь вырабатывает сигнал прерывания для микропроцессора.
На следующем командном цикле вместо очередной команды,
описываемой программным счетчиком, будет выполняться команда, находящаяся по адресу, предназначенному для обработки
прерываний. Обработка прерываний осуществляется также программным образом с помощью специализированных программ, называемых обработчиками прерываний. Соответственно, на время
59
выполнения обработки прерываний, выполнение других команд
приостанавливается.
В сигнальных процессорах для аппаратной реализации сохранения контекста (сохранения результатов текущих вычислений) при
обработке прерываний с целью минимизации времени реакции на
сигнал прерывания в настоящее время широко применяются теневые регистры. Этот механизм при появлении сигнала прерывания
обеспечивает сохранение значений ряда регистров CPU аппаратным способом.
Механизм неявной адресации. Ориентация на обработку массивов отсчетов данных, что является основной задачей, под которую
разрабатывались сигнальные процессоры, привела к появлению
регистров неявной адресации и контроллера обеспечения прямого
доступа к памяти.
Механизм неявной адресации ориентирован на обработку векторных данных и реализуется следующим образом.
При необходимости выполнить однотипные операции с данными, размещенными в памяти последовательно, в регистр неявной
адресации записывается адрес первого элемента обрабатываемого
массива. Если при выполнении команды обработки в качестве параметра используется имя регистра неявной адресации (РНА), то
в качестве адреса операнда используется адрес, записанный в регистр РНА. В зависимости от типа команды, после ее завершения
содержание регистра РНА инкрементируется, декрементируется с
задаваемым шагом.
В сочетании с аппаратной реализацией DO-цикла и использованием операции с накоплением получаем эффективный способ реализации, например, Фурье-преобразований в реальном масштабе
времени.
Контроллер прямого доступа к памяти. Контроллер прямого
доступа к памяти (Direct Memory Access – DMA) обеспечивает возможность передачи информации с одного адреса памяти данных на
другой, минуя CPU. Такое решение позволяет существенно ускорить быстродействие микропроцессора при реализации векторных
операций.
В современных сигнальных микропроцессорах используют многоканальные контроллеры DMA. Это решение начинает использоваться и в современных микропроцессорах.
Архитектура процессора OMAP-L138. Достигнутый к настоящему времени уровень развития технологии обеспечивает возможность использования сигнальных процессоров в качестве одного
60
из модулей микропроцессора. В качестве показательного примера
кратко рассмотрим архитектуру процессора OMAP-L138 фирмы
Texas Instrument (рис. 2.6).
Это двуядерный процессор, ориентированный на мультимедийные применения. Процессор реализован на базе микропроцессорного ядра ARM926EJ-S и сигнального процессора DSP C674x DSP.
¡Æ˾É;ÂÊ+5"(
¨Ç½ÊÁÊ˾ŹÌÈɹ»Ä¾ÆÁØ
«¹ÃËÁÉÇ»¹ÆÁ¾
1--¼¾Æ¾É¹ËÇÉ
°¹ÊÔɾ¹ÄÕÆǼǻɾžÆÁ
35$
¼¾ÆÜÏ
¨Ç½ÊÁÊ˾Ź"3.
¨Ç½ÊÁÊ˾Ź%41
¸½ÉÇD..6
"3.&+4
¸½ÉÇ%41
$Y
,C&5#
"&5 *$BDIF
£º
30.
%DBDIF
£º
30.
-
-
£º
£º
30.
3".
˹žɹǺҾ¼ÇƹÀƹоÆÁØ
£º ȹÅØËÕ
¹ÆÆÔÎ
3".
¬Èɹ»Ä¾ÆÁ¾ÈÁ˹ÆÁ¾Å 4-&&1
ªÁÊ˾Ź
ÅÌÄÕËÁÈľÃÊÁÉÇ»¹ÆÁØÆÇ¿¾Ã
-£º
ȹÅØËÕ½¹ÆÆÔÎ
3".
£ºÈ¹ÅØËÕ ÈÉǼɹÅÅ
30.
¨ÉǼɹÅŹ
À¹¼ÉÌÀÐÁù
CPPU30.
¬Èɹ»Ä¾ÆÁ¾È¾É¾ÃÄ×оÆÁ¾ÅɾÊÌÉÊǻؽɹ4XJUDIFE$FOUSBM3FTPVSDFTs4$3
¨ž©¡­ž©¡¢¦´ž¥§¬¤¡
£ÇÆËÉÇÄľÉÈÉØÅǼÇ
½ÇÊËÌȹÃȹÅØËÁ
%."
ùƹĹ&%."
›ÆÌËɾÆÆØØ
ȹÅØËÕ
½¹ÆÆÔÎ
£º3".
™Ì½ÁÇÈÇÉËÔ
.D"4Q
X'*'0
£ÇÆËÉÇÄľÉ
-$%½ÁÊÈľØ
¨ÇÊľ½Ç»¹Ë¾ÄÕÆÔ¾
ÁÆ˾É;ÂÊÔ
Y.D#41Y41*
Y*$Y6"35
›Á½¾Ç
ÃÇÆËÉÇÄľÉ
71*'
¦¹ÊËɹÁ»¹¾ÅÔ¾
ÈÇÄÕÀÇ»¹Ë¾ÄÕÊÃÁ¾
ÁÆ˾É;ÂÊÔ136
¡Æ˾É;ÂÊÔʻƾÑƾ £ÇÆËÉÇÄľÉÁÆ˾É;Âʹ
ȹÅØËÕ×&.*'"
ʻƾÑƾÂȹÅØËÕ×
CC
/"/%'MBTI
%%3.%%3
C4%3".
¨¹É¹ÄľÄÕÆÔÂ
ÈÇÉË
V11
«¹ÂžÉÔ
YF18.
YF$"1
£ÇÅÅÌÆÁùÏÁÁ
64#64#&."$
.%*0)1*
..$4%4"5"
Рис. 2.6. Архитектура процессора OMAP-L138 (Texas Instruments)
61
ARM926EJ-S представляет собой 32-битный RISC-процессор,
обеспечивающий обработку 32-16-битных команд и 32-16-8битных данных. Ядро ARM имеет в своем составе сопроцессор CP15
для выполнения операций с плавающей запятой, собственную память программ и память данных, модуль защиты данных и модуль
управления памятью (Memory Management Unit – MMU).
Сигнальный процессор использует двухуровневую структуру
внутренней (cash) памяти. Уровень L1 представляет собой 32 Кбайт
памяти программ, а уровень L2 предназначен для данных и имеет
объем 256 Кбайт. Этот уровень может использоваться ARM-ядром.
В процессоре имеется 128 Кбайт памяти, которая может использоваться процессорными модулями.
Процессор обладает развитой системой периферийных модулей,
обеспечивающих аппаратную поддержку широкого спектра современных высокоскоростных коммуникационных решений: 10/100
Мбит Ethernet модуль, USB 2.0, USB 1.1, 2 I2C порта, специализированный многоканальный последовательный порт McASP, порт для
последовательного буферизованного обмена, UART, 2 порта SPI.
Для обеспечения возможности работы с внешней памятью процессор имеет порты EMIFA и DDR-контроллер.
2.2. Системы управления с модульной структурой
Управляющие системы столь же различны, как и управляемые
ими устройства. На сегодняшний день наиболее характерными
примерами областей, где постоянно востребованы встраиваемые
системы, являются:
промышленная автоматизация,
измерительная техника и приборостроение;
медицина;
авиация;
наземный транспорт;
торговля;
индустрия развлечений;
телекоммуникации;
мобильные и портативные устройства.
Непрерывное развитие элементной базы, накопленный опыт разработки вычислительных систем со сложной структурой обеспечили
возможность создания универсальных решений уже в части аппаратной составляющей компьютеров для встраиваемых применений.
62
§1. COTS и OEM-решения
Для создания универсальных и эффективных к конкретному
применению решений используется принцип модульности. Применение этого принципа подразумевает, что конфигурация и конкретная реализация вычислительной системы обеспечивается наличием набора базовых модулей, совместимых между собой. Сами
модули поставлялись независимыми фирмами и собираются в единое целое компанией, отвечающей за системную интеграцию.
Для обозначения такого типа технологии на практике используют две аббревиатуры: COTS и OEM.
COTS-технология. Термин COTS (Commercial Off-The-Shelf)
применительно к аппаратному обеспечению обозначает «поставляемый и готовый к использованию компонент».
Базовая мотивация использования таких компонентов заключается в принципиальной возможности существенного сокращения
сроков и стоимости всей разработки. Такой подход чреват целым
рядом сложностей, особенно в условиях жесткой конкуренции на
рынке аппаратных решений. Фактически он подразумевает появление явной и неявной зависимостей от поставщиков.
Альтернативой этому является необходимость организации разработки, производства и поддержания продукта, что не позволяет
уложиться в сроки и объемы финансирования конкретного проекта. Соответственно, применение COTS-технологий в сложных системах управления, выпускаемых в небольших количествах, зачастую единственный реалистичный способ их создания.
OEM-решения. Аббревиатура OEM (Original Equipment Manufacturer) используется для обозначения производителя комплектного оборудования, собираемого из отдельных готовых частей,
производимых другими предприятиями. При этом, кто является
разработчиком и конструктором, комплектующих, входящих в
конечное комплектное изделие, как и самого изделия, не является
принципиальным. Это может быть как собственно OEM, так и сторонняя компания. OEM-производитель не обязательно имеет собственную торговую марку или бренд. Поставщики OEM-решений
работают как напрямую на потребительский рынок, так и являются поставщиками для других компаний, будучи в этом качестве
субподрядчиками.
Существует определенный разнобой в применении этого термина.
Например, собранная печатная плата по ГОСТ 15105-69 не является
комплектным изделием, так как считается неразборной и не имеет
63
самостоятельных законченных элементов. Тем не менее поставщика плат принято классифицировать как OEM-производителя.
На розничном рынке компьютерных комплектующих и программного обеспечения OEM-решение – это версия продукта, поставляемая производителем в минимально необходимой комплектации и поступающая в таком виде в розничную торговлю. При
этом продукт не ориентирован на конечного потребителя и непосредственный производитель не обеспечивает его поддержку – гарантийные обязательства (или их отсутствие) и их объём по своему
усмотрению берут (или не берут) на себя розничные продавцы.
Системы управления встраиваемого класса, создаваемые с использованием такого рода технологий, широко используют одноплатные
компьютеры, дополняемые модулями собственной разработки работы с датчиками и выработки сигналов для управляющих устройств.
§2. Аппаратные решения стандарта PC-104
Ключевым элементом систем управления, реализуемым на базе
этого стандарта, является одноплатный компьютер, реализованный в специфицированном форм-факторе. Этот же форм-фактор
используется и при реализации остальных модулей аппаратной составляющей системы управления.
Одноплатный компьютер. Одноплатный компьютер (Single
Board Computer – SBC) представляет собой серийно выпускаемый,
готовый к применению компьютерный модуль. Это типичное COTSрешение, обеспечивающее значительное сокращение времени вывода новой системы на рынок. Основное назначение SBC можно
сформулировать следующим образом: универсальное стандартизованное решение для вычислительного ядра встраиваемой системы
управления, адаптируемое для решения конкретной задачи за счет
добавления специализированных аппаратных модулей.
Одноплатный компьютер имеет на одной плате микропроцессор, оперативную и постоянную память, устройства ввода-вывода.
Так как разные задачи требуют разной вычислительной мощности
и различного набора интерфейсов, в настоящее время выпускается большое количество модификаций одноплатных компьютеров,
ориентированных по конкретную область применения. Такие компьютеры отличаются небольшими размерами и определенным набором периферийных устройств, которые, прежде всего, ориентированы на использование в промышленных применениях.
64
Одноплатные компьютеры делят на два основных класса: компьютеры с поддержкой возможности модификации архитектуры за
счет использования предустановленных разъемов (слотов) расширения и компьютеры без возможности модификации.
Имеется широкий спектр систем реального времени встраиваемого класса, реализуемых на одноплатных компьютерах. Компьютеры этого класса традиционно используют хорошо отработанные
технологии микропроцессоров, используемые в рабочих станциях
и персональных компьютерах. В настоящее время для этого используются микропроцессоры класса 80486, Pentium и микропроцессоры, специализированные под встраиваемые применения.
Стандарт PC/104. Стандарт PC/104 разрабатывался с целью
создания унифицированной платформы для как можно большего
круга применений. При разработке модулей широко использовались элементы и архитектурные принципы IBM PC. Популярность
этого стандарта и возрастающие требования реальных применений
привели к необходимости разработки его расширения в виде стандарта PC/104 +.
Название стандарта PC/104 расшифровывается очень просто:
оно состоит из двух частей, первая из которых подчеркивает IBM
PC совместимость, а вторая сообщает количество контактов шины.
Впервые платы РС/104 появились на рынке в 1987 году, и уже через пять лет в 1992 году была выпущена первая открытая редакция
соответствующих спецификаций.
Шина РС/104 электрически и логически соответствует спецификации шины ISA со скоростью передачи данных 8 Мбит/с. Модификация шины PCI, поддерживаемая стандартом РС/104 +, обеспечивает обмен данными на скоростях до 133 Мбайт/с [6].
Системы управления на базе этого стандарта ориентированы на
применения в необслуживаемых системах, бортовой аппаратуре и
т. п. Они отличаются простой конструкцией и достаточно высокой
степенью устойчивости к внешним воздействиям.
Стандарт обеспечивает наращивание возможностей аппаратной
составляющей системы управления за счет использования модулей.
Линейные размеры стандартной платы составляют 90×96 мм. Платы модулей объединяются в единое целое по принципу этажерки с
шагом по высоте 15 мм. Крепление элементов этажерки осуществляется четырьмя угловыми монтажными стойками. Кроме того,
дополнительным механическим соединителем служат проходные
разъёмы шины РС/104. Сборка из двух модулей стандарта PC104
показана на рис. 2.7.
65
Благодаря применению специальных компонентов и аппаратных решений потребление энергии снижено до единиц ватт. В результате модульные компьютеры PC/104 могут работать в закрытых
объемах без применения принудительного охлаждения. Например,
большинство современных модулей содержат шинные формирователи с выходным током 25 мА, что позволяет подключать на шину
PC/104 до 12 модулей. При этом модули стандарта PC/104 позволяют уменьшить выходной ток шинных формирователей до 4 мА, что
является критически важным для мобильных систем.
Они имеют в своем составе аппаратные средства обеспечения надежности, включающие в себя память для программ пользователей
и сторожевые таймера для перезапуска программ в случае «зависания» или сбоев. Прикладное программное обеспечение может разрабатываться как на обычном персональном компьютере, так и на
компьютере PC/104.
По окончании разработки программы можно переписывать с
одного компьютера на другой, переключая кабель от жесткого диска (IDE интерфейс), используя накопители или RS232. При желании, периферийные модули в стандарте PC/104 могут использоваться в составе обычного персонального компьютера при подключении через пассивный переходник PC/104 (IEEE-P996.1) – ISA
(IEEE-P996).
В случае запуска операционной системы с жесткого диска процессорный блок работает как стандартный PC-компьютер. Все интерфейсы, находящиеся на процессорной плате, являются стан-
Рис. 2.7. Сборка из двух модулей формата PC104
66
дартными и полностью совместимы с периферией обычной PCмашины.
Одноплатный компьютер Tiger. В мае 2011 года фирма
VersaLogic(CША) объявила о начале поставок одноплатного компьютера в форм-факторе стандарта PС-104 +. Компьютер реализован на микропроцессоре Atom Z5xx (Menlow XL) фирмы Intel,
разработанном специально для встраиваемых применений. При
использовании частоты 1,33 ГГц работает в температурном диапазоне –40/ + 85 °С и за счет радикального снижения энергопотребления не требует вентилятора. Имеет гигабитный порт Ethernet, семь
портов USB 2.0, четыре последовательных порта, аудиоканал и видеоканалы высокого разрешения, контроллер IDE c возможностью
подключения двух устройств. Внешний вид одноплатного компьютера Tiger приведен на рис. 2.8.
Для начальной загрузки использует Embedded BIOS фирмы
Phoenix. Обеспечивает работу операционных систем Windows,
Windows Embedded, Linux, VxWorks, QNX.
Выполняет требования стандарта MIL-STD-202G по вибростойкости и ударным воздействиям. Гарантийный срок 5 лет. Ориентировочная стоимость одноплатного компьютера Tiger составляет
725 дол.
Модуль сигнальной обработки. Система управления подразумевает возможность обработки входных сигналов и формирования
сигналов управления. Для этого используются специализированные платы аналого-цифрового и цифроаналогового обеспечения,
выполненные в форм-факторе стандарта. Некоторое представление о возможностях современных реализаций PC-104-модуля для
Рис. 2.8. Одноплатный компьютер Tiger в форм-факторе PC-104 +
67
этих целей дает описание еще одного продукта фирмы Versa Logic
(США).
Модуль реализован в форм-факторе стандарта PC-104. Обеспечивает возможность аналого-цифрового преобразования 16 каналов с
разрешением 16 битов. Для одного канала обеспечивается частотой
преобразования 100 кГц. При обработке всех каналов частота преобразования составляет 67 кГц. Имеет два выходных аналоговых
сигнала с 12-битными цифроаналоговыми преобразователями. Как
входные, так и выходные каналы могут быть откалиброваны через
программируемый цифровой порт. Калибровочные константы могут быть сохранены в памяти EEPROM. Имеет два 8-битных конфигурируемых (вход-выход) цифровых порта.
Сборка из двух модулей, выполненных в стандарте PC-104, показанная на рис. 2.7, иллюстрирует возможность быстрого создания аппаратного компонента бортовой системы управления с централизованной архитектурой.
§3. Стандарт VMEbus
Стандарт VMEbus представляет собой стандарт архитектуры
для магистрально-модульных систем управления, разработанной
около 25 лет назад. Финансирование разработки этого стандарта
осуществляли MOTOROLA и SUN Microsystems. Несмотря на столь
солидный возраст системы на основе этого стандарта используются
до сих пор.
Встроенные системы на основе VMEbus выпускает около 140
компаний, и их продукты находят применение в самых различных отраслях. В число наиболее распространенных типов модулей входят процессорные платы с различными микропроцессорами (INTEL 80386,MC 68020 и др.), модули каналов аналоговых и
цифровых входов/выходов, интерфейсы локальных сетей и сетей
ЭВМ и многое другое. В частности, система управления марсоходов
Spirit и Opportunity реализована на этом стандарте с применением
одноплатного радиационно-стойкого компьютера RAD6000.
Архитектура VME выросла вокруг семейства микропроцессоров
MOTOROLA 68xxx, но сейчас имеются VME-реализации на Intel,
Power PC и RISC-процессорах и программируемой логике.
VMEbus – это спецификация, реализующая принцип модульности применительно к многоканальным системам управления. Она
ориентирована на широкую область применения от систем реаль68
ного времени до мультипроцессорных систем обработки данных.
Это обеспечивается возможностью использования разных модулей,
набор которых зависит от назначения разрабатываемой системы.
Этот стандарт широко применяется в аэрокосмической и военной
технике и ориентирован на применения, в которых определяющим
является надежность. В силу этого при разработке стандарта были
специфицированы не только электрические параметры и логика
работы модулей, но и определен принцип и способы реализации механической конфигурация системы. Для этого был выбран единый
механический стандарт – Евромеханика (МЭК 297-1, 297-3).
В табл. 2.2. приведен, далеко не полный, перечень коммерчески
поставляемых операционных систем, поддерживающих работу с
оборудованием стандарта VMEbus.
Таблица 2.2
Операционные системы для VMEbus
OC UNIX
Solaris
SunOs
Berkley
At&T
Linux
OC WINTEL
DOS
OS-2
Windows
Windows 95/98
Windows NT
OC реального времени
VxWorks
pSOS
LynxOS 3.1
QNX
RTLinux
Базовая спецификация VMEbus (IEEE-1014-1987) характеризуется следующим образом:
шина стандарта состоит из параллельной шины адреса (16–32
бита), шины данных (8–32бита) и шины управления;
шина управления разбита на группы (также используются термины «bus», «sub-bus») для обеспечения следующих функций:
арбитража шины передачи данных,
задания приоритета (до 7 уровней),
мониторинга состояния (контроль на наличие ошибок),
последовательной шины управления,
архитектура MASTER-SLAVE c поддержкой режима с несколькими мастер-устройствами;
тип обмена – асинхронный (отсутствует источник тактирования
шины);
регулируемая скорость обмена информацией c автоматической
подстройкой;
скорость обмена до 40 Мбайт/сек.
Конструктивное исполнение. Использование пассивных
кросс-плат является характерным для промышленных компью69
теров и систем, имеющих модульную структуру. Для обозначения
этой платы в англоязычной литературе используют термин «backplane», но на практике прижился термин «кросс-плата». В системах этого типа модули системы размещаются на платах, устанавливаемых в блок, имеющий стандартизированное конструктивное
исполнение. Сигналы по установленным на платах разъемам выводятся на кросс-плату блока – соединительную плату с ответными
частями разъемов, содержащую практически только соединительные линии связи между разъемами.
Это обеспечивает большую простоту и удобство обслуживания
всех узлов микропроцессорной системы, замену вышедших из
строя компонентов. Конструкция передней панели – планки, устанавливаемой на переднем крае платы, дает возможность непосредственного доступа к плате, без необходимости снятия крышки всего блока.
Система управления на основе VMEbus компонуется из функциональных модулей VME, устанавливаемых в крейты, число которых не регламентируется. Крейт представляет собой стандартный
каркас с объединительной магистралью VME, источником питания
и вентиляцией. Объединительная магистраль представляет собой
плату с размещенными на ней разъемами. Типы, электрическая
схема соединений и волновое сопротивление для проводников
«кросс-платы», тип разъемов являются специфицированными параметрами.
В каждый крейт можно поместить до 21 модуля VME. Стандартный шаг стандарта Eurocard по высоте обозначается как U и равен
1,75 дюйма. Размеры крейта и форм-фактор модуля по высоте выбираются из ряда 3U, 6U, 9U. В глубину модули должны иметь размер 160 мм. Для применений с большим уровнем вибраций, как
правило, используют модули 3U. Модули 9U на практике используются редко.
Базовые конструктивные элементы стандарта VMEbus показаны
на рис. 2.9. По современным меркам VMEbus система относительно
много потребляет. Для питания модулей могут использоваться питания на напряжениях 3, 5, + / – 12 и 48 вольт. Источники питания
могут устанавливаться внутрь крейта или быть внешними.
Используется несколько типов логических модулей, реализующих следующие базовые функции:
арбитр шины обеспечивает реализацию алгоритма предоставления шины устройствам (должен быть включен в слот (slot) под
номером 1);
70
обработчик прерываний обеспечивает фиксацию и обработку поступающих сигналов прерываний;
мастер-устройство обеспечивает возможность реализации многоуровневой системы управления и управляет посредством арбитра
шины обменом со слэйв-устройствами;
cлэйв-устройство обеспечивает возможность реализации нижних уровней системы управления и может инициировать обмен с
мастер-устройства за счет использования системы прерываний.
Для реализации функций арбитража шины и обработки прерываний часто используют одноплатные компьютеры.
Логическую организацию обмена данными по шине иллюстрирует рис. 2.10. В простом варианте конфигурации в крейте нахо-
б)
а)
в)
г)
Рис. 2.9. Конструктивные элементы стандарта VMEbus:
а) корпус крейта; б) кросс-плата; в) модуль 3U; г) модуль 6U
71
™ÉºÁËÉÑÁÆÔ
"3#*5&3
»ÃÄ×й¾ËÊØ»ÊÄÇË
Ǻ¾ÊȾÐÁ»¹¾Ë
ÌÈɹ»Ä¾ÆÁ¾½ÇÊËÌÈÇÅ
ÃÑÁƾÅÇÆÁËÇÉÁƼ
˾ÃÌÒ¾¼ÇÊÇÊËÇØÆÁØ
ÑÁÆÔ
¥¹Ê˾ÉÌÊËÉÇÂÊË»Ç
."45&3
ÌÈɹ»ÄؾËǺžÆÇÅ
ÈÇÑÁƾ½¹ÆÆÔÎ
ÇÊÌÒ¾ÊË»ÄؾËǺžÆ
½¹ÆÆÔÅÁÐ˾ÆÁ¾À¹ÈÁÊÕ
ÊÇÊÄÖ»sÌÊËÉÇÂÊË»¹ÅÁ
ªÄÖ»ÌÊËÉÇÂÊË»Ç
4-"7&
Ǻ¾ÊȾÐÁ»¹¾Ë
ŹÊ˾ÉÌÊËÉÇÂÊË»Ì
»ÇÀÅÇ¿ÆÇÊËÕ
Ð˾ÆÁØÀ¹ÈÁÊÁ½¹ÆÆÔÎ
½ÄؽÇÊËÌȹÃÑÁƾ
¼¾Æ¾ÉÁÉ̾ËÈɾÉÔ»¹ÆÁØ
¤ÁÆÁÁÀ¹ÈÉÇʹɹÀɾѾÆÁØ
¤ÁÆÁÁÈɾÉÔ»¹ÆÁÂ
¤ÁÆÁÁ½¹ÆÆÔÎ
¤ÁÆÁÁ¹½É¾Ê¹
Рис. 2.10. Логическая организация обмена данными по шине VMEbus
дится модуль арбитра шины, одно мастер-устройство и несколько
слэйв-устройств.
§4. Линии развития стандарта VMEbus
Непрерывное развитие элементной базы для цифровой обработки сигналов создает предпосылки к непрерывному наращиванию
возможностей систем управления с одной стороны, а с другой –
требует постоянной работы по разработке новых версий стандарта. Ключевым параметром, по которому идет модификация в настоящее время, является скорость обмена по шине. Сложность заключается в необходимости обеспечения совместимости изделий
последних модификаций с изделиями, выпускавшимися до этого
(совместимость сверху-вниз), так как в эксплуатации находится
большое количество выпущенного ранее оборудования.
VME64. Эта версия стандарта принята в 1995 году и характеризуется следующими нововведениями:
при реализации в форм-факторе 6U обеспечивает возможность
передачи 64-битных данных и использования 64-битного адреса;
при реализации в форм-факторе 3U обеспечивает возможность
передачи 32-битных данных и 40-битного адреса;
скорость передачи данных увеличена до 80 Мбайт/сек;
введена функция автоматического определения наличия
устройств – plug-and-play;
использованы разъемы с пониженным уровнем шума.
72
VME6 Extensions (VME64x). В 1997 году VITA Standards Organization (VSO) приняла серию расширений стандарта VMEbus –
VME64x. В дополнение к существующим возможностям был добавлен ряд усовершенствований, в частности:
скорость обмена увеличена до 160 Мбайт/с;
добавлена возможность использования питающих напряжений
3,3 В;
расширено количество линий питания с напряжением 5,5 В;
добавлена 141 линия цифровых входов-выходов, управляемых
пользователем;
добавлена защита от электростатического напряжения и улучшено экранирование крейта, за счет соответствующей конструкции передней панели;
предусмотрена возможность «горячей» замены.
VME320. Стандарт VME320 была введен компанией Arizona
Digital в 1997 году. Это не очередная модификация, а радикальное
изменение концепции. Основной целью являлся подъем средней
скорости обмена по шине до 320 Мбайт/с (пиковая скорость обмена
500 Мбайт/с).
Для этого используется новая конструкция кросс-платы и новый
протокол шины. Кросс-плата реализована с использованием топологии физическая звезда. Все линии информационного обмена сводятся к среднему слоту кросс-платы. Ключевая идея заключается в том,
что при обмене сигналами двух модулей, подключенных в разные
слоты, они проходят лишь через один разъем (средний) и не подвержены воздействию всех модулей, подключаемых к шине. Такая реализация обеспечивает меньшее искажение сигнала, что, в конечном
счете, обеспечивает возможность подъема скорости обмена.
Для этого потребовалось изменение протокола обмена, который
получил название 2eSST.
OpenVPX. Спецификация была одобрена в 2010 году VSO и принята ANSI. Увеличение возможностей оборудования, реализуемого
с разными версиями спецификаций стандарта VMEbus, по скорости передачи данных между модулями приведено в табл. 2.3.
Таблица 2.3
Версия стандарта
VMEbus IEEE-1014
VME64
VME64x
VME320
Скорости обмена по шине VMEbus
Протокол
Скорость, Мбайт/сек
BLT
MBLT
2eVME
2eSST
40
80
160
320-500
73
Спецификации ANSI/VITA 1-1994 (VME64), ANSI/VITA 1.11997 (VME64x) и последние модификации этого стандарта лучше
получать в организациях, осуществляющих координацию работ в
этом направлении, а именно:
VITA
PO Box 19658
Fountain Hills, AZ 85269
Tel: (480) 837-7486
http://www.vita.com
American National Standards Institute (ANSI)
11 West 42nd Street
New York, NY USA 10036
TEL: (212) 642-4900; FAX: (212) 398-0023
http://www.ansi.org
§5. Спецификация CompactPCI
CompactPCI – это вариант шины PCI[7], предназначенный для
построения встраиваемых систем [8]. Спецификация CompactPCI
разработана консорциумом производителей средств вычислительной техники промышленного назначения – PICMG (PCI Industrial
Computer Manufacturers Group).
Этот стандарт объединяет архитектуру локальной шины PCI с
технологиями и конструктивно-технологическим исполнением, характерными для средств вычислительной техники промышленного
применения. CompactPCI широко используется в системах управления реального времени, телекоммуникационном оборудовании,
приборостроении, медицинском оборудовании, системах сбора данных в реальном времени, авиационных и космических системах.
Конструктивное исполнение. С точки зрения конструктивного исполнения этот стандарт родственен стандарту VMEbus и совместим с широко используемым в промышленности стандартом
Евромеханика (Eurocard), платы CompactPCI имеют аналогичные
габаритные размеры. Используются платы формата 3U (160×100
мм, высота передней панели-планки – 128,5 мм) и платы формата 6U (160×233,35 мм, высота передней панели-планки – 262 мм)
(рис. 2.11). Передние панели-планки на платах CompactPCI удовлетворяют стандартам IEEE1101.1 (без электромагнитной защиты) или IEEE1101.10 (с рычажками экстрактора/инжектора и с
электромагнитной защитой).
Конструкция плат обеспечивает их надежное размещение в шасси блока. Вертикальное расположение плат обеспечивает лучшее
охлаждение за счет естественной конвенции воздуха. Способы установки и крепления плат дают хорошую стойкость к вибрации и ударам. Верхние и нижние края платы устанавливаются в жесткие на74
B
+
+
ÅÅ
+
+
+
ÅÅ
º
+
ÅÅ
+
ÅÅ
Рис. 2. 11. Типоразмеры и разъемы плат CompactPCI:
а) размер 6U; б) размер 3U
правляющие. Передняя панель установленной в блок платы крепится к блоку; с противоположной стороны жесткость крепления платы
обеспечивает используемый в CompactPCI штыревой разъем.
Важной особенностью CompactPCI является использование
специальных штыревых разъемов, монтируемых на плату. Конструкция и характеристики таких разъемов хорошо подходят для
использования в промышленных условиях повышенных помех и
воздействий окружающей среды (пыль, влага, вибрация и др.). Используются 5-рядные экранированные газонепроницаемые штыревые разъемы высокой плотности компоновки с шагом 2 мм по стандартам IEC 917 и IEC 1076-4-101 (МЭК-1076).
75
Разъем обладает низкой индуктивностью и переходным сопротивлением, что снижает уровень отраженных сигналов и позволяет
передавать высокоскоростные сигналы шины PCI по плате задней
стенки на 8 разъемов. Газонепроницаемость разъема обеспечивает
защиту от коррозии и потери контакта. Конструктивное исполнение разъема обеспечивает также жесткую фиксацию платы, установленной в блок, со стороны задней стенки блока.
Специальное дополнение к спецификации CompactPCI регламентирует правила проектирования плат, обеспечивающих свойства «горячей замены» [9]. Эти требования включены также в третью редакцию основной спецификации [8].
Используемые в CompactPCI разъемы обеспечивают возможность «горячей замены» плат (hot swap) – т. е. установки/извлечения плат без выключения питания. Для этого используется специальная конструкция контактов в разъеме. Разная длина штырей
разъема-вилки обеспечивает гарантированное поэтапное, последовательное замыкание/размыкание групп сигналов на разъеме
при установке/вынимании платы: при вставке разъема-вилки в
ответную часть сначала замыкаются земляные контакты, потом –
контакты питания, потом – сигнальные контакты; при вынимании
разъема размыкание происходит в обратном порядке.
Разъем содержит матрицу контактов – 5 рядов по 47 контактов,
физически и логически разделяемые на 2 группы – 25 (J1/P1) и 22
(J2/P2) контакта в ряду.
Разъем J1 включает все сигналы 32-разрядной шины PCI. Разъем J2 используется для дополнительных сигналов 64-разрядного
варианта шины PCI. Разъемы с J3 по J5 на платах 6U спецификацией не задействованы и могут применяться для специфических
сигналов (например, ввода/вывода) конкретных прикладных плат.
Подключение внешних каналов к плате CompactPCI возможно как
со стороны передней стенки, так и по разъемам задней стенки. Конструкция плат и блоков допускает как установку разъемов с выходом на переднюю панель-планку платы, так и монтаж подключения
внешних каналов по панели задней стенки блока, в соответствии со
стандартом IEEE1101.11 (по разъемам J3, J4, J5). Это обеспечивает
удобное подключение каналов ввода-вывода для разных применений в прикладных системах, что важно для многих промышленных и телекоммуникационных применений встроенной вычислительной техники.
Например, в сетевом и телекоммуникационном оборудовании
популярен монтаж подключений каналов ввода-вывода (например,
76
подключения магистральных каналов) по задней панели (кроссплате). При таком монтаже платы, требующие обслуживания в
ходе эксплуатации оборудования, оказываются свободны от внешних подключений на передней планке и могут выниматься и устанавливаться без перекоммутации кабелей подключения внешних
каналов (в том числе – в режиме «горячей» замены). При подключении плат CompactPCI к периферийным устройствам, наоборот,
часто удобнее использовать подключение кабеля от устройства к
разъему на передней планке.
Структура систем с CompactPCI. Система, разработанная в
соответствии со спецификацией CompactPCI, состоит из одного или
нескольких сегментов шины CompactPCI. Конструктивно сегмент
представляет собой кросс-плату (backplane), с установленными на
ней разъемами (ответные части для разъемов, размещаемых на
платах 3U/6U) c интервалом в 20,32 мм между платами.
Располагаемые на кросс-плате ответные части для разъемов J1
и J2 на плате CompactPCI, обозначаются, соответственно, как Р1 и
Р2. Каждый сегмент состоит из позиций – слотов (до 8 позиций в
сегменте), среди которых выделяется один системный слот и до 7
периферийных слотов (рис. 2.12).
ªÁÊ˾ÅÆÔÂÊÄÇË
¨¾ÉÁ;ÉÁÂÆÔÂÊÄÇË
Рис. 2.12. Плата задней стенки CompactPCI с ответными
частями разъемов: 1 системный слот и 7 периферийных слотов
(вид со стороны передней стенки блока)
77
Плата, устанавливаемая в системный слот, отвечает за процедуру инициализации системы, работу с сигналами всех плат сегмента, арбитража шины и формирования синхросигналов.
Системный слот использует разъем J2 для подключения этих
сигналов на плату задней стенки, и плата, устанавливаемая в системный слот, обязательно должна иметь разъем J2. В периферийных слотах могут устанавливаться платы, содержащие как ведомые устройства (slaves) на шине PCI, так и ведущие (bus masters).
Если плата, устанавливаемая в периферийный слот, не работает в
64-разрядной конфигурации шины PCI, то она может не содержать
разъема J2.
В пределах одного сегмента шины CompactPCI все сигналы
шины на кросс-плате разводятся по соответственным контактам
всех разъемов, кроме трех сигналов: CLK, IDSEL, REQ# и GNT#,
разводка которых определятся отдельно для каждого слота. Сигнал IDSEL для каждого слота соединяется со своим, отличным от
других слотов, одним контактом из верхней части набора линий
шины AD.
При использовании в вычислительной системе с шиной
CompactPCI нескольких сегментов они соединяются между собой
мостами PCI-to-PCI. Построение плат межсегментного взаимодействия в многосегментных конфигурациях регламентируется спецификацией PCI–to–PCI Bridge Board (PPBB)[10].
Питание систем. Спецификация CompactPCI предусматривает возможность построения систем с основным напряжением питания 5 В или 3,3 В. С точки зрения напряжения питания, платы
CompactPCI разделяются на платы, предназначенные для работы
только с напряжением питания 5 В; платы, предназначенные для
работы только с напряжением питания 3,3 В; и универсальные
платы, способные работать как с напряжением питания 3,3 B,
так и 5 В. Для предотвращения установки платы на 3,3 В в сегмент CompactPCI, спроектированный для работы с питанием 5 В,
и наоборот, предусмотрен ключ в позициях 12–14 разъема J1/P1,
(Key Area). Универсальная плата, которая может работать в любой
из конфигураций, в этих позициях разъема J1 не содержит никакого ключа. Кросс-плата сегмента CompactPCI «универсальной» быть
не может. Она проектируется либо на работу с питанием 3.3 В, либо
на работу с питанием 5 В. Соответственно конфигурируются и ключи в разъемах P1 каждого из слотов кросс-платы.
Для систем с шиной CompactPCI стандартизовано также размещение и разъем подключения источника питания. Спецификация
78
CompactPCI Power Interface [11] определяет типоразмеры источников питания для размещения в блоке CompactPCI, расположение
разъема для подключения источника (источников) питания и собственно разъем – его тип, электрические характеристики интерфейса и назначение контактов. Предусмотрена возможность «горячей замены» и для источника питания.
Модификации Small PCI и mini-PCI. Появление спецификации Small PCI вызвано потребностью производителей мобильных
вычислительных систем использовать шину PCI в условиях ограниченного пространства. Для производителей традиционных настольных систем реализация стандарта Small PCI также дает определенные выгоды в части увеличения модульности при построении
системы из отдельных функциональных компонентов.
В стандарте Small PCI сохраняются все характеристики шины
PCI, 32-разрядная мультиплексированная шина адреса/данных,
синхронный обмен со скоростью до 132 Мбайт/с при тактовой частоте шины 33 МГц. Новыми чертами являются добавление сигнала CLKRUN, с помощью которого устройства могут управлять значением тактовой частоты шины с целью снижения потребляемой
ими мощности, что особенно актуально в мобильных системах и
портативных компьютерах. Имеются также некоторые отличия в
конструктиве и размерах печатных плат, направленные на минимизацию занимаемого устройством объема.
§6. Система на модуле
Еще один вариант реализации принципа модульности, получивший название «система на модуле» (System On Module-SOM), появился совсем недавно.
Появление такого рода модулей обязано широкому распространению малогабаритных цифровых коммуникационных устройств.
Устройства этого класса требуют существенных вычислительных
мощностей для обработки аудио- и видеоинформации и имеют
жесткие ограничения на массогабаритные параметры, уровень
энергопотребления и стоимость конечного изделия. Выполнение
требования по стоимости возможно лишь при больших тиражах,
что и приводит к необходимости унификации вычислительного
компонента.
Следует подчеркнуть, что разработка малогабаритного одноплатного компьютера – достаточно трудоемкий и дорогой процесс.
79
В частности, это касается стоимости разработки многослойных плат
и необходимости использования высокоскоростных чипов памяти и
компонент, выполненных по BGA технологии. Возможность использования готового компонента в виде малогабаритного одноплатного
компьютера со специализированной периферией существенно расширяет круг компаний, для которых становится возможным разработка современных мобильных телефонов, коммуникаторов, электронных терминалов и т. д. Дополнительно такой подход для конечного пользователя обеспечивает модификацию устройств в течение
жизненного цикла за счет возможности замены модуля.
Рассмотрим этот подход на примере SOM OMAP-L138, разработанного на базе микропроцессора OMAP-L138 фирмой Logic PD, являющейся дочерней компанией Texas Instrument. Фирма Logic PD
специализируется на поставке малогабаритных одноплатных компьютеров, реализуемых на базе микропроцессоров фирмы Texas
Instruments.
Модуль OMAP-L138 – это COTS-решение, представляющее собой
одноплатный компьютер размера 30×40×4,5 мм, предназначенный
для встраиваемых применений для коммуникационных систем.
Весит этот модуль 7 г, что позволяет оценить фантастический прогресс в области микропроцессоров уже и по этому параметру.
Модуль поставляется в виде нескольких модификаций, использующих разные типы микропроцессоров. Модули реализуются как
на сигнальных микропроцессорах TMS320C6758, так и на коммуникационных микропроцессорах последнего поколения OMAPL138. Микропроцессор OMAP-L138 включает в себя ядро ARM9
и сигнальный микропроцессор С674x. Модуль работает на максимальной частоте 375 МГц. Функциональные возможности модулей одни и те же. Блок-схема модуля и внешний вид модуля SOM
OMAP-L138 приведены на рис. 2.13.
Модуль выпускается в двух модификациях на микропроцессоре
OMAP-L138 или TMS320C6748. Модуль содержит высокоскоростную память c параллельным доступом, память с последовательным
доступом, схему тактирования микропроцессора и шины обмена по
интерфейсу SATA, чип поддержки доступа к Ethernet и чип поддержки touch-screen клавиатур. Микропроцессоры модуля обеспечивают возможность коммуникаций по трем портам UART, двум
портам I2С и двум SPI. Кроме этого имеется возможность использовать коммуникационные интерфейсы USB, SATA, специализированные интерфейс (McASP) для работы с цифровыми аудио кодеками фирмы Texas Instruments.
80
«ÉÁÆÇ¿¾ÐÆÔÎɹÀӾŹ»ÔÊÇÃÇÂÈÄÇËÆÇÊËÁ
­ÇÉÅÁÉÇ
»¹Ë¾ÄÕ
ÈÁ˹×ÒÁÎ
ƹÈÉØ¿¾ÆÁÂ
«¹ÃËÁÉÌ×ÒÁÂ
¼¾Æ¾É¹ËÇÉ
»ÃÄ×йØ
4"5"
.**
¬ÆÁ»¾ÉʹÄÕÆÔ¾ ªÈ¾ÏÁ¹ÄÁÀÁ
£ÇÆËÉÇÄľÉ
ÁÆ˾É;ÂÊÔ
ÉÇ»¹ÆÆÔ¾
˹ÐÊÃÉÁƹ
ÁÆ˾É;ÂÊÔ
514
&UIFSOFU
6"35ÑË
4"5"
*ªÑË
.D"41
¬ÆÁ»¾ÉʹÄÕ
41*ÑË
&.*'"
ÆÔ¾ÈÇÉËÔ
64#ÑË
-$%
»»Ç½¹»Ô»Ç½¹
£¹Å¾É¹
¸½ÉÇÈÉÇϾÊÊÇɹ
0."1-ÁÄÁ
5.4ª%41
¡Æ˾É;ÂÊ
+5"(
Рис. 2.13. Блок-схема модуля SOM OMAP-L138
Микропроцессор OMAP-L138 содержит в своем составе модуль
поддержки интерфейса с жидкокристаллическим дисплеем с размерами до 1024×1024 пикселей и 16-битным представлением цвета, имеет часы реального времени и обеспечивает возможность контроля энергопотребления.
Модуль снабжен тремя малогабаритными 100-ножечными разъемами. Система управления на базе этого модуля включает в себя
плату под конкретное применение. Конструкция платы не регламентируется и зависит исключительно от функционального назначения системы управления. Эта плата должна содержать три специфицированных разъема, обеспечивающих подключение модуля.
На разъемы выведен интерфейс JTAG, обеспечивающий возможность программирования модуля и его отладку в составе разрабатываемой системы.
Таблица 2.4
Параметры модулей SOM на базе микропроцессоров
фирмы Texas Instruments
Процессор
ПоследоваТемпераDDR память,
Тип SOM
(частота
тельная флэш- турный диаMбит
375 МГц)
память, Мбит
пазон, °С
SOMOMAP-L138
OMAP-L138
10-1602AHCR
SOMOMAP-L138
OMAP-L138
10-1502AHCR
SOMOMAP-L138
OMAP-L138
10-1602QHIR
SOMC6748
TMS320C6748
10-1602AHCR
128
8
0–70
64
8
0–70
128
8
–40–85
128
8
0–70
81
Параметры модулей этого семейства приведены в табл. 2.4. При
поставке модуль снабжается библиотеками поддержки одноплатного компьютера. Прикладное программное обеспечение реализуется под операционной системой Linux.
2.3. Элементная база
для распределенных систем управления
Микроконтроллер представляет собой микросхему, предназначенную для создания специализированных систем управления. От
классического микропроцессора микроконтроллер отличается наличием широкого спектра периферийных модулей, обеспечивающих возможность компактной реализации элементов распределенных систем управления. Современные микроконтроллеры могут
всерьез рассматриваться как вариант реализации многоканальной
системы управления на кристалле (System on Chip-SOC).
§1. Микроконтроллеры
Архитектура микроконтроллера обеспечивает возможность реализации полного цикла обработки данных «измерение-вычислениевыработка сигналов управления» на одном кристалле. Для этого в
архитектуру микроконтроллеров кроме вычислительного ядра,
характерного для микропроцессоров, вводятся модули обработки аналоговых сигналов от датчиков, модули выработки сигналов
управления и модули специализированных, как правило, последовательных шин.
Микроконтроллеры были разработаны позже микропроцессоров и берут начало от микроконтроллера Intel 8048, выпущенного
в 1976 году. Взрывной характер распространения этой технологии
обеспечил микроконтроллер Intel 8051, выпущенный в 1980 году.
Этот микроконтроллер с гарвардской архитектурой имеет около
20 клонов, выпускающихся разными компаниями по настоящее
время. При разработке микроконтроллеров существенным образом
был использован опыт и технологии, разработанные для микропроцессоров, автономных модулей для аналого-цифровой и цифроаналоговой обработки сигналов.
Микроконтроллеры предназначены для использования во встраиваемых системах управления для самых разнообразных примене82
ний. Универсальное аппаратное решение для слишком широкого
круга применений было бы слишком громоздким и дорогим. В силу
этого, микроконтроллеры разрабатываются и производятся специализированными семействами, ориентированными на определенный класс устройств.
Разработкой и производством микроконтроллеров занимаются около 10 крупных электронных компаний. Номенклатура выпускаемых микропроцессоров включает сотни семейств и тысячи
конкретных реализаций.
О масштабах применения встраиваемых систем управления
дают представления следующие цифры. Более 90 % всех производимых микропроцессоров и микроконтроллеров используется во
встраиваемых системах управления. При этом в 2000 году было
произведено 365 миллионов микропроцессоров и 6,4 миллиарда
микроконтроллеров.
Для классификации микроконтроллеров используется способ
представления обрабатываемых данных, а именно 4-8-16-32-бита.
В системах управления промышленного назначения широко используются 8-битные микроконтроллеры. Ориентировочные параметры этого сегмента рынка приведены в табл. 2.5.
Как следует из приведенных данных, компании Intel и Zailog,
которые стояли у истоков развития и этого направления элементной базы для встраиваемых применений, в настоящее время в этом
сегменте рынка практически не присутствуют.
В связи с бурным развитием рынка автономных коммуникационных устройств и цифровой видео- и аудиоаппаратуры в настоящее время ряд ведущих компаний разработали специализированные семейства 16- и 32-битных микроконтроллеров. Как правило,
микроконтроллеры для этих применений содержат на кристалле
широкий набор коммуникационных модулей и модулей аппаратной поддержки специализированных шин.
Таблица 2.5
Состояние рынка 8-битных микропроцессоров
Компания
Доля рынка, %
Объем продаж, млн дол.
Motorola
22
Renesas (Hitachi + Mitsubishi)
15
Microchip
14
ST Micro
9
Philips
8
Atmel
6
Суммарный объем рынка в 2003–2004 году 4 млрд дол.
880
600
560
36
32
24
83
Объемы памяти на кристалле достаточно внушительны по сравнению с традиционными микроконтроллерами, но недостаточны
для работы с мультимедийными приложениями. Поэтому имеется
возможность использования внешней быстродействующей памяти, используемой как память программ или память данных. Схема
памяти подключается через соответствующий модуль реализации
шины, который входит в состав микропроцессора.
В качестве примера подобного класса чипов можно указать 16битные микропроцессоры семейства BlackFin (Analog Device).
§2. Особенности архитектуры
микроконтроллеров
Существенных отличий в архитектурах классического микроконтроллера от микропроцессора набирается достаточно много.
Все нововведения были обусловлены потенциальными выгодами,
которые сулило освоение ниши малогабаритных многоканальных
систем управлений реального времени для промышленных и бытовых применений. Каждое слово в этой декларации напрямую определяет характерные особенности построения архитектур микроконтроллеров.
Рассмотрим кратко причинно-следственные связи между этими
требованиями и их влиянием на архитектуру микроконтроллеров.
Ключевыми требованиями являлись малогабаритность и низкая стоимость реализации. Требование по минимизации габаритов
привело к необходимости использования памяти программ и памяти данных, реализованных на том же кристалле, что и СPU. Как
правило, микроконтроллеры реализуются по технологии, которая
существенно отстает от технологии производства современных микропроцессоров. Под технологией в данном контексте понимается
линейный размер логического элемента. Соответственно, объемы
памяти программ и данных микроконтроллеров существенно меньше, чем у малогабаритных одноплатных компьютерах.
Требование низкой стоимости аппаратной составляющей системы управления привело к широкому использованию корпусов
с ножками, расположенными по периферии, с возможностью монтажа на однослойных платах. В результате количество ножек у
микроконтроллеров является одним из важных параметров, определяющих возможность реализации малогабаритной многоканальной системы управления.
84
В силу своего базового предназначения микроконтроллеры по
необходимости должны иметь в составе своей архитектуры многоканальные модули аналого-цифрового преобразования и обработки
цифровых входных сигналов, многоканальные модули цифроаналогового преобразований и выработки выходных сигналов управления с широтно-импульсной модуляцией, модули поддержки
коммуникационных шин и т. п. Эти модули образуют периферию
микроконтроллера. Как правило, для обеспечения работы с конкретным периферийным модулем требуется три группы регистров:
регистры конфигурирования, управления и данных.
Содержание регистров конфигурирования определяет режим
работы модуля. Например, для коммуникационного порта UART
таким способом задается скорость обмена. Соответствующий бит в
регистре управления обеспечивает включение и выключение модуля. Получаемый и передаваемый байт данных содержится в соответствующих регистрах данных.
Регистры конфигурирования и управления реализуются также,
как и стандартные регистры данных. Работа с ними осуществляется
аналогичным образом с использованием команд микропроцессора.
Для реализации функций управления и индикации микроконтроллеры обязательно имеют в своем составе конфигурируемые
цифровые порты общего назначения, которые могут работать как на
вход, так и на выход. Конфигурирование портов осуществляется с
использованием соответствующих регистров конфигурации портов.
Из-за жесткого лимита на количество доступных для использования ножек эти порты и ряд внутренних модулей микропроцессора мультиплексированы. Корректное конфигурирование и инициализация этих модулей – нескончаемый источник ошибок при
разработке прикладного программного обеспечения.
Ориентация на применения реального времени продиктовала
необходимость наличия в составе микроконтроллера таймерных
модулей. Необходимость обеспечения специфицированных времен
реакции на входные воздействия и ограничения на объем элементов для реализации архитектуры потребовали использование укороченной системы команд.
Обработка в заданном темпе входных сигналов, их обработка и
выработка сигналов управления при наличии ограничений на максимально допустимую частоту привели к необходимости перехода
к широкому использованию гарвардской архитектуры и использованию конвейерных схем вычислений. Такой тип архитектуры
позволяет, по крайней мере, вдвое увеличить скорость обработки
85
данных за счет параллельного выполнения операций с памятью
программ и с памятью данных.
Так как системы бытового и промышленного назначения, как
правило, работают в необслуживаемом режиме, в их архитектуру
стали вводить аппаратные модули, обеспечивающие увеличение
надежности реализации предписанных алгоритмов управления.
В качестве модулей этого типа можно указать встроенные сторожевые таймеры, модули контроля уровня питающего напряжения,
стабилизации тактовой частоты и т. д.
Для микроконтроллеров, предназначенных для использования во встраиваемых системах управления с автономным питанием, архитектура микроконтроллеров обеспечивает возможность
управления уровнем потребления. Это обеспечивается за счет программного управления питанием незадействованных в конкретном
ªÁÊ˾Ź˹ÃËÁÉÇ»¹ÆÁØ
¨¹ÅØËÕ
ÈÉǼɹÅÅ
¨Ç½ÊÁÊ˾ŹÌÈɹ»Ä¾ÆÁØ
ÖƾɼÇÈÇËɾºÄ¾ÆÁ¾Å
¾ÑÁÍɹËÇÉ
ÃÇŹƽ
ªÁÊ˾Ź ÌÈɹ»Ä¾ÆÁØ ÃÇÆÍÁ¼ÌɹÏÁ¾Â
$16
£ÇÆÍÁ¼ÌɹÏÁÇÆÆÔ¾
ɾ¼ÁÊËÉÔ
¨¹ÅØËÕ
½¹ÆÆÔÎ
¨Ç½ÊÁÊ˾Ź
Ǻ¾ÊȾоÆÁØ Æ¹½¾¿ÆÇÊËÁ
ªÁÊ˾Ź ÈɾÉÔ»¹ÆÁÂ
©¾¼ÁÊËÉÔ
ǺҾ¼Ç
ƹÀƹоÆÁØ
©¾¼ÁÊËÉÔÃÇÆÍÁ¼ÌÉÁÉÇ»¹ÆÁØÌÈɹ»Ä¾ÆÁØÁɹºÇËÔ
ȾÉÁ;ÉÁÂÆÔÎÅǽÌľÂ
¨¾ÉÁ;ÉÁÂÆÔ¾ÅǽÌÄÁ
rÌÆÁ»¾ÉʹÄÕÆÔ¾ÈÇÉËÔÏÁÍÉǻǼǻ»Ç½¹»Ô»Ç½¹
rÅǽÌÄÁ™¯¨À¹Î»¹Ë¹Êɹ»Æ¾ÆÁر¡¥
r˹žÉÆÔ¾ÅǽÌÄÁ
rÃÇÅÅÌÆÁùÏÁÇÆÆÔ¾ÅǽÌÄÁ
Рис. 2.14. Архитектура современного микроконтроллера
86
режиме модулей микроконтроллера и даже изменением тактовой
частотой.
Обобщенная архитектура типового современного микроконтроллера приведена на рис. 2.14.
§3. Система команд
В настоящее время используется квалификация микроконтроллеров по набору и способу реализации системы команд. В современных микроконтроллерах популярно использование набора команд
RISC (Reduced Instruction Set Command) и микроконтроллеры с такой системой команд обычно называют RISC-микроконтроллеры.
В ряде микроконтроллеров используется и набор MISC
(Minimized Instruction Set Command) и CISC (Complete Instruction
Set Command).
Термин «сокращенный» (reduced) в названии архитектуры указывает на тот факт, что объем действий и время их выполнения
каждой командой, входящей в набор, оптимизирован таким образом, чтобы она могла выполняться за один-два командных цикла,
и обеспечивала возможность применения конвеерных схем выполнения операций. Как правило, конвеерная схема обработки команд
для своей реализации требует 4–12 тактов генератора. Общее число
команд при этом варьируется от 35 до 70. Набор этих команды реализуется аппаратными компонентами CPU.
RISC-архитектура обеспечивает возможность увеличения быстродействия и минимизацию энергопотребления. Эти процессоры
проще в реализации и требуют меньшего количества транзисторов
для реализации CPU по сравнению с CISC и MISC-архитектурами.
Несмотря на название, этот набор функционально полон и может
включать в себя, например, команду умножения 8-битных или 16битных чисел, которые выполняются табличным способом за один
командный цикл.
§4. Система прерываний микроконтроллеров
Принципиально важной составляющей архитектуры микроконтроллера является набор периферийных модулей. Управление ими
осуществляется программным способом и включает в себя операции конфигурирования, включения/выключения и, собственно,
87
выполнения функций, свойственных этому модулю. Эти функции
модули выполняют автономно за счет соответствующей аппаратной реализации конкретного модуля.
Так как современный микроконтроллер может иметь несколько десятков периферийных модулей, то применительно к многоканальной системе управления речь идет об организации управления
их параллельной работой. Система прерываний микроконтроллеров предназначена в первую очередь именно для этого. Эти системы
в разных микроконтроллерах реализуются по-разному.
Рассмотрим общий принцип функционирования системы прерываний.
Обработка прерываний осуществляется аппаратно-программными средствами. Запуск каждого модуля и его инициализация,
если это необходимо, осуществляется программным способом. Под
инициализацией в данном случае имеется засылка в специальные
регистры этого модуля конкретной информации, которая должна
быть тем или иным способом обработана. Модули, работающие с
внешними устройствами, получают информацию извне, и для них
в ряде случаев не требуется инициализация.
Запустив в работу конкретный модуль, микроконтроллер выполняет программу дальше. Например, запускает в работу следующий периферийный модуль или обрабатывает уже имеющуюся
информацию. Информация о текущем номере обрабатываемой команды хранится в специальном регистре – счетчике команд, обозначаемом обычно PC.
Выполнив необходимые операции, инициированный модуль
вырабатывает специальный сигнал, поступающий на вход системы
прерываний. Обработка этого сигнала на первом этапе осуществляется аппаратно и приводит к передаче управления на адрес обработчика прерываний. При этом текущее значение счетчика команд запоминается в специальном регистре, для того чтобы после завершения обработки прерывания можно было возобновить выполнение с
места, откуда произошло прерывание. Для корректного возобновления кроме значения PC требуется сохранения значений рабочих
и временных регистров, обычно используемых СPU, а в некоторых
случаях и некоторого набора регистров, принадлежащих конкретной задаче. Этот набор значений носит название контекста.
После запоминания контекста и текущего значения PC в регистр
счетчика команд заносится значение адреса, начиная с которого содержится набор команд, обеспечивающих дальнейшую обработку
прерывания уже программным способом. Эти команды должны
88
обеспечить фиксацию источника прерываний, обеспечить условия корректного продолжения выполнения основной (прерванной)
программы, обработку информации с модуля, вызвавшего прерывание. Например, осуществить пересылку байта информации с регистра модуля в рабочие регистры или память данных.
Для каждого модуля набор операций свой, и он описывается своей последовательностью команд. Эта последовательность команд
завершается блоком команд восстановления контекста и командой
возврата из прерываний, по которой осуществляется корректное
восстановление значения счетчика команд.
На рис. 2.15 изображен иллюстрирующий пример для системы,
использующей два модуля. При этом предполагается, что микроконтроллер имеет аппаратную реализацию в части распознавания
источника прерываний.
Программа управления реализуется на уровне S-0. В момент
времени t1 проводится инициализация периферийного модуля H-1
(уровень H-1), который работает до момента времени t2. Его работа на этом временном отрезке никак не влияет на выполнение программы на уровне S-0 и работа выполняется параллельно. Модуль
H-1 завершает свою работу в момент времени t2 и инициализирует
аппаратный сигнал прерывания, который поступает на аппаратно
4**
4*
)
4
)
)
U
U
U
U
U
U U U
›É¾ÅØ
Рис. 2.15. Пример временной диаграммы работы системы
с двумя периферийными модулями
1 – выполнение команд основной программы; 2, 3 – работа аппаратных модулей
периферии; 3 – работа аппаратной компоненты системы прерываний;
4, 5 – выполнение команд обработчиков прерываний
89
реализованную схему распознавания источника прерываний (уровень H-0). При аппаратной реализации длительность интервала невелика – один-два командных цикла.
В момент времени t3 управление передается на уровень S-1, на
котором программным способом осуществляется сохранение контекста для программы с уровня S-0, проводится пересылка и обработка информации для модуля H-1, восстанавливается контекст задачи и в момент времени t4 выполняется команда возврата из прерывания и возобновляется выполнение программы с уровня S-0.
В момент времени t6 эта же последовательность действий повторяется для аппаратного модуля H-2. Программная часть обработчика прерываний для этого модуля находится на уровне S-II.
Таким образом, программа с уровня S-0 не выполняется во время обработки прерываний в интервалах [t4–t2] и [t8–t6]. Во время
интервалов [t2–t1] и [t6–t5] выполнение программы осуществляется параллельно с работой аппаратно реализованных модулей.
2.4. Микроконтроллеры семейства pic18f
(nano Watt Technology)
В качестве примера, позволяющего оценить современный уровень развития микроконтроллеров, рассмотрим клон «nano Watt
Technology» семейства PIC18Fxxxx фирмы Microchip. Насколько
этот возможно, рассмотрение сфокусировано на базовых принципах реализации аппаратного компонента.
§1. Общая характеристика семейства
Рассматриваемые микроконтроллеры ориентированы на использование в малогабаритных устройствах с автономным питанием. Базовые параметры приведены в табл. 2.6, а архитектура старших представителей семейства на рис. 2.16.
§2. Архитектура семейства
Все семейство RISC-микроконтроллеров PIC18Fxxxx использует
модифицированную гарвардскую архитектуру (см. рис. 2.15). Модифицированная гарвардская архитектура позволяет использовать
память программ для хранения данных, но доступ к ней осущест90
вляется путем использования специальных команд, что существенно уменьшает возможность непреднамеренного ее изменения.
Организация цикла обработки команд использует две разные
шины для работы с памятью данных и памятью программ.
СPU содержит схему аппаратного умножения 8×8, которая выполняется за один командный цикл. Для обеспечения возможности работы с массивами служат регистры неявной адресации. Па
¸½ÉÇÅÁÃÉÇÃÇÆËÉÇÄľɹ
±Áƹ½¹ÆÆÔÎ
ÁÌÈɹ»Ä¾ÆÁØ
£ÇÆËÉÇÄľÉÑÁÆÔ½¹ÆÆÔÎ
¨Ç½ÊÁÊ˾Ź
ªÐ¾ËÐÁà ¦¾Ø»Æ¹Ø
Ǻ¾ÊȾоÆÁØ
™¤¬ ÃÇŹƽ
¹½É¾Ê¹
ƹ½¾¿ÆÇÊËÁ
ÁÊËÖÃ
ÏÁØ
¾Ãǽ¾É
£ÇÆËÉÇÄľÉ
«¹ÂžÉ
ÃÇŹƽ
ÈɾÉÔ»¹ÆÁÂ
À¹½¾É¿ÃÁÈÇ
ÈÁ˹ÆÁ×
±ÁƹÃÇŹƽ
«¹ÂžÉ
À¹½¾É¿ÃÁ
¨ÉǼɹÅÅƹØ
¼¾Æ¾É¹ËÇɹ
ȹÅØËÕ
£ÇÆËÉÇÄÕ
ÈÉÇ»¹ÄÇ»
›ÊËÉǾÆÆÔÂ
ÈÁ˹ÆÁØ
ÈÉǼɹÅŹËÇÉ
¥ÇÆÁËÇÉ
˹ÃËÁÉÇ
»¹ÆÁØ
œ¾Æ¾É¹ËÇÉ
˹ÃËÁÉÇ»¹ÆÁØ
›ÆÌËÉÁÊξÅÆÔÂ
ÇËĹ½ÇÐÆÔÂ
ÖÅÌÄØËÇÉ
«¹ÂžÉ
ºÁË
¥Ç½ÌÄÕ
±¡¥
À¹Î»¹Ë¹
Êɹ»Æ¾ÆÁØ
«¹ÂžÉ
ºÁË
ªËÇÉÇ¿¾»ÇÂ
˹žÉ
¨¾ÉÁ;ÉÁÂÆÔ¾ÅǽÌÄÁ
«¹ÂžÉ
ºÁË
«¹ÂžÉ
ºÁË
¥Ç½ÌÄÕ
¥Ç½ÌÄÕ
¥Ç½ÌÄÕ À¹Î»¹Ë¹ ÊÁÆÎÉÇÆÆÇ¼Ç ¹ÊÁÆÎÉÇÆÆǼÇ
Ǻžƹ
Êɹ»Æ¾ÆÁØ
Ǻžƹ
6"35
¥ÌÄÕËÁÈľÃÊÁÉÇ»¹ÆÆÔ¾
½»ÌƹÈɹ»Ä¾ÆÆÔ¾
ÈÇÉËÔ»»Ç½¹»Ô»Ç½¹
¨§©«™
›ÎǽԻÔÎǽÔ
™¯¨¼¾Æ¾É¹ËÇÉ
˹ÃËÁÉÌ×ÒÁÎ
ÁÅÈÌÄÕÊÇ»
¨§©«#
›ÎǽԻÔÎǽÔ
»Îǽԙ¯¨
»Æ¾ÑÆÁ¾ÈɾÉÔ»¹ÆÁØ
¨§©«ª
›ÎǽԻÔÎǽÔ
ÃÇÅÅÌÆÁùÏÁÇÆÆÔ¾
ÅǽÌÄÁ
ǺɹºÇËùÊÁ¼Æ¹ÄÇ»
¨§©«%
›ÎǽԻÔÎǽÔ
ÃÇÅÅÌÆÁùÏÁÇÆÆÔ¾ ÅǽÌÄÁ
¨§©«&
›ÎǽԻÔÎǽԙ¯¨
»Æ¾ÑÆÁ¾ÈɾÉÔ»¹ÆÁØ
¥Ç½ÌÄÕ
ºÁËÆǼǙ¯¨
¥Ç½ÌÄÕȾɾÈÉǼɹÅ
ÅÁÉ̾ÅÇÂȹÅØËÁ
½¹ÆÆÔÎ
&&130.
Рис. 2.16. Архитектура семейства микроконтроллеров
PIC18F4220/4320
91
мять данных относительно невелика – 512 байт. В специальных
режимах имеется возможность использования памяти программ
для хранения данных, которая для старшего представителя клона
составляет 8 Кбайт. При этом память программ обеспечивает возможность реализации до 100000 циклов перезаписи и сохранения
целостности данных до 40 лет.
Таблица 2.6
ПАРАМЕТРЫ СЕМЕЙСТВA nano Watt Technology
Параметр
PIC18F2220 PIC18F2320 PIC18F4220 PIC18F4320
Частота
31 Кгц –
40 Мгц
31 Кгц – 40 31 Кгц – 40 31 Кгц –
Мгц
Мгц
40 Мгц
Память
программ, байт/команд 4096/2048 8192/4096
данных, байт
512
512
EEPROM, байт
256
256
Периферийные модули
Универсальные I/O
A,B,C
A,B,C
порты
4
4
Таймеры
Стандартные модули за2
хвата, сравнения, ШИМ
2
Улучшенные модули за0
0
хвата, сравнения, ШИМ
Модуль 10-битного AЦП 10 каналов 10 каналов
SPI (I2C) SPI (I2C)
Модули последовательадресуеных интерфейсов
адресуемый UART мый UART
Модуль параллельного
нет
интерфейса
нет
Модуль источников пре19
19
рываний
Количество команд
75
75
Типы корпусов
28 SPDIP 28 SPDIP
28 SOIC
28 SOIC
4096/2048 8192/4096
512
512
256
256
A,B,C,D,E A,B,C,D,E
4
4
1
1
1
1
13 каналов 13 каналов
SPI (I2C)
SPI (I2C)
адресуеадресуемый UART мый UART
да
да
20
75
40 PDIP
44 TQFP
44 QFN
20
75
40 PDIP
44 TQFP
44 QFN
Архитектура микроконтроллера дополнена периферийным модулем электрически перепрограммируемой памяти EEPROM размером 256 байт. Этот модуль обеспечивает возможность хранения
данных прикладной программы в процессе функционирования
устройства и их восстановления после повторного включения питания. Тип используемой памяти обеспечивает до одного миллиона
циклов перезаписи и сохранения целостности данных до 40 лет.
92
Тактирование микроконтроллера. Для конкретного типа архитектуры производительность CPU прямо пропорциональна используемой частоте тактирующих импульсов. Микроконтроллер
обеспечивает возможность использования как встроенного источника тактирующих импульсов, так и двух способов реализации
внешних частотозадающих схем.
Использование встроенного источника тактирующих импульсов
обеспечивает возможность выбора частоты тактирования из ряда
31–125–250–500 кГц и 1–2–4–8 МГц. Точность параметров внутреннего истоника тактирующих импульсов в диапазоне 125 кГц –
8 Мгц составляет 1 %. Для систем управления, требующих использования часов реального времени, это относительно невысокое
значение. Оно является платой за габариты изделия. Этот параметр
можно существенно улучшить при использовании внешних частотозадающих элементов. Для этого способа тактирования частота
может достигать 40 МГц.
Одной из особенностей всего семейства PIC18Fxxxx является
возможность использования двух программно переключаемых
источников тактирующих импульсов. Это позволяет, в конечном
счете, снижать энергопотребление, правда ценой усложнения прикладного программного обеспечения.
§3. Периферийные модули
Таймерные модули. Микроконтроллеры семейства имеют в составе своей периферии 4 таймерных модуля. Каждый из этих таймеров обладает особенностями, а их совокупность обеспечивает разработчика широким спектром возможностей по реализации систем
управления реального времени.
Таймер 0 имеет программно управляемый предделитель, обеспечивающий возможность управления частотой прерываний с
параметром, выбираемым из ряда 2–4…256. Периферийный модуль Таймер 1 обеспечивает возможность реализации на нем часов
реального времени и потребляет 1,1 мкА при использовании собственной внешней частотозадающей цепочки 32 кГц и питании от
независимого источника 2 В.
Таймер 3 может работать независимо либо в в тандеме с Таймером 1, используя его как источник.
Каждый из этих таймеров реализован на двух 8-битных регистрах, т. е. это фактически 16-битные таймера, но для корректной
93
работы с ними требуются соответствующим образом написанные
обработчики прерываний.
Модуль Таймер 2 реализован на 8-битном регистре, имеет предделитель, постделитель и регистр периода. Этот таймер обеспечивает возможность микроконтроллеру генерации ШИМ-сигналов
управления внешними устройствами.
Модуль аналого-цифрового преобразования. Этот многоканальный модуль обеспечивает возможность аналого-цифрового
преобразования напряжений, получаемых с 10 (в старших представителях семейства 13) измерительных элементов датчиков. Преобразование осуществляется поочередно, канал за каналом, и управляется программным способом. При аналого-цифровом преобразовании осуществляется зарядка входного конденсатора до уровня
действующего на входе канала напряжения, а потом осуществляется преобразование этого значения в числовой формат. Новой
возможностью модуля для этого семейства является возможность
программным способом задавать временные параметры этих двух
этапов.
Универсальные порты ввода/вывода. Предельные возможности
системы управления, реализуемого на микроконтроллере из рассматриваемого семейства, по каналам управления фактически определяются количеством универсальных портов. Каждый такой порт
представляет независимый модуль, обслуживающий 8 ножек. Эти
ножки программным способом могут быть сконфигурированы для
работы как в качестве цифровых входов, так и цифровых выходов.
Таким образом, микроконтроллеры этого семейства потенциально способны обеспечить реализацию системы с суммарным количеством входных и выходных каналов, равным 30–32. Это число
ограничено сверху типом используемого корпуса (суммарное количество ножек), но некоторое количество их потребуется на подвод
питания, организацию тактирования, пользовательские интерфейсы и т. п. В любом случае, речь идет о количестве каналов, измеряемом десятками.
Устройство каждого из портов имеет свои особенности как по
функциям, так и по реализации. К таким особенностям относятся
способность быть источником прерываний, нагрузочная способность, наличие программно управляемой резистивной подтяжки к
питанию, мультиплексирования с другими модулями и т. п. В целом, богатство этих возможностей требует корректного конфигурирования и инициализации этих модулей в процессе запуска микроконтроллера.
94
§4. Система прерываний
Ключевым элементом многоканальной системы управления
реального времени является временная синхронизация работы по
каждому из каналов с целью обеспечения специфицированных
параметров по времени реакции. В общих чертах принцип работы
системы прерываний уже был описан выше. Следует подчеркнуть,
что система прерываний семейства микроконтроллеров PIC18Fxxx
обладает рядом особенностей, что и предопределяет необходимость
ее детального рассмотрения. При этом рассмотрение, по возможности, будет лишено излишней детализации.
Как следует из таблицы, в микроконтроллерах PIC18F4220/4320
максимальное количество возможных источников прерываний равно 19. В разнообразных вариантах использования в системах управления реального времени это количество может варьироваться.
Известные системы прерываний делятся на два класса: одноадресные и векторные. В одноадресных системах прерываний при
возникновении этого события от любого из модулей управление
передается на один, определенный заранее адрес. По этому адресу,
как правило, находится команда передачи управления на обработчик прерываний, реализуемый программным способом.
Далее производится ряд действий, связанных с сохранением
контекста программной единицы, выполняемой в момент возникновения прерывания, и, программным способом осуществляется
определение источника прерываний путем проверки состояния
флагов в регистрах управления.
В векторных системах распознавание источника прерываний
осуществляется аппаратными средствами. Для этого каждый источник прерывания имеет свой адрес, куда передается управление в
случае возникновения события. Далее, естественно, требуется обеспечить сохранение контекста и после этого выполнить обработку
прерывания. Такая система обеспечивает более быструю реакцию
на событие по сравнению с одноадресной реализацией, которая используется в младших семействах этой платформы.
Особенностью системы прерываний семейства PIC18Fxxx является возможность настройки системы прерываний на работу в режимах одноадресного и двухадресного обработчика.
В режиме двухадресного обработчика прерываний источники
прерываний делятся по приоритетам: прерывания с высоким приоритетом и прерывания с низким. Внутри каждой группы определение источника прерывания осуществляется программным спосо95
бом. При этом обеспечена возможность приписать источники прерываний в ту или иную группу на этапе конфигурирования системы прерываний.
Прерывания с большим приоритетом прерывают выполнение
обработки прерывания с меньшим приоритетом. С этой точки зрения обработчик конкретного прерывания представляет обыкновенную программу, реализуемую стандартными средствами. При обработке прерывания может возникнуть ситуация появления еще
одного прерывания с этим же уровнем приоритета. Эта ситуация
естественна для систем с несколькими источниками прерываний,
приписанных к одной и той же группе по приоритету. Однако при
наличии асинхронных событий при определенных условиях она
может возникать даже при одном источнике прерываний.
Для того чтобы обработчики прерываний не мешали друг другу,
имеется возможность программным способом блокировать сигналы
от любого источника вплоть до отключения системы прерываний
целиком. Эта возможность просто необходима на этапе конфигурировании микроконтроллера, так как возникновение прерываний
на этом этапе может привести систему в неработоспособное состояние из-за неправильной конфигурации и инициализации модулей.
В принципе, блокирование системы прерываний на этапе конфигурирования и инициализации является общей рекомендацией для
всех микроконтроллерных реализаций систем управления.
Применительно к рассматриваемым микроконтроллерам блокирование системы прерываний требуется при операциях чтениязаписи в память программ и EEPROM.
Как следствие, для реализации всех этих возможностей каждому источнику прерывания в систему прерываний соответствует три
бита:
бит флага прерывания, сигнализирующий о наличии сигнала
прерывания;
бит блокирования сигнала прерывания;
бит приоритета.
Эти биты находятся в разных регистрах, обеспечивающих управление системой прерываний. В рассматриваемых микроконтроллерах таких регистров в сумме набирается 10.
С практической точки зрения в системах управления на базе
этого микроконтроллера оказывается целесообразным использовать двухуровневую систему прерываний. При этом источник прерывания с высоким приоритетом всего один, а именно – модуль, на
котором реализован системный таймер.
96
Управление энергопотреблением. В современных микроконтроллерах повсеместно используется режим пониженного энергопотребления. Микроконтроллеры семейства nano Watt обеспечивают возможность многоступенчатой регулировки уровня энергопотребления.
В стандартный SLEEP-режим пониженного энергопотребления
микроконтроллер переводится ассемблерной командой «sleep».
Выполнение этой команды отключает генератор тактирующих импульсов, что приводит к остановке конвейера обработки команд
и, соответственно, снижению уровня энергопотребления. Выход
из этого режима осуществляется при появлении любого сигнала
прерывания, после чего возобновляется нормальное функционирование микропроцессора. Для систем управления с низкой интенсивностью поступающих сигналов, требующих обработки с малым
количеством арифметических и логических операций, реализация
цикла «обработка сигнала» – «sleep» обеспечивает снижение энергопотребления пропорциональное средней скважности входных
сигналов.
По сравнению с микроконтроллерами предыдущих семейств микроконтроллеры, образующие семейство nano Watt, имеют группу
режимов IDLE-mode. Управление этими режимами осуществляется программным способом.
В этих режимах производится отключение CPU-микроконтроллера, в то время как периферийные модули продолжают работать.
Выход из этого режима осуществляется при появлении любого сигнала прерывания. При этом возобновление возможности обработки
команд происходит с временной задержкой 10 мкс, требующейся
для запуска электроники CPU. Имеются несколько способов уменьшить эту задержку.
Следует помнить, что микроконтроллер представляет собой целую систему электронных модулей, управляемых программным
образом. Соответственно, можно достичь снижения энергопотребления, отключая не требующиеся для функционирования системы модули.
§5. Подсистема обеспечения надежности
Как видно из рис. 2.16, подсистема обеспечения надежности состоит из:
трех таймеров Power-up, Oscillator Start-up, Watch-dog;
97
схем рестарта программы при включении питания и при обнаружении провалов питающего напряжения Power-on Reset и Brownout Reset;
монитора наличия тактирующих импульсов (Fail-Safe Clock
Monitor).
В основе построения всей подсистемы лежит тот факт, что микроконтроллер представляет собой сложную систему, образуемую
электронными компонентами и становится системой программного управления при наличии стабильного питания и тактирующих
импульсов.
Контроль уровня питающего напряжения. При включении
питания требуется подождать, чтобы уровень питающего напряжения достиг специфицированного значения. Это бывает особенно
важно для систем с автономным питанием в конце срока службы
батарей или аккумуляторов. Эту задержку обеспечивает схема таймера Power-up.
Однако в процессе работы, а это особенно важно для систем встраиваемого класса, возможно возникновение нарушений в системе
питания, связанное с провалами питающего напряжения. Понятно, что снижение уровня питающего напряжения ниже специфицированного может привести к произвольному изменению значений битов регистров и система программного управления перестанет быть таковой. А что особенно неприятно, может в переходном
режиме выдавать некорректные управляющие сигналы, способные
вывести управляемый объект из строя.
Для отслеживания провалов питающего напряжения используется компонент подсистемы Brown-out Reset. Этот компонент
обеспечивает рестарт программы с фиксацией причины в соответствующем регистре. Наличие проверки причин рестарта, в принципе, позволяет предотвратить потерю важных данных за счет выполнения операций по их сохранению. Для того чтобы на это хватило времени, имеется возможность задания порога срабатывания
детектора провала питающего напряжения. Этот порог задается
при прошивке соответствующих значений в конфигурационную
память микроконтроллера.
Контроль системы тактирования. Наличие питания обеспечивает возможность запуска схем генерации тактирующих
импульсов. Для того чтобы эти схемы вышли на стационарный режим работы, используется таймер Oscillator Start-up. Этот таймер,
отсчитав заданное количество циклов, запускает схему рестарта
программы по включению питания Power-on Reset. Результатом
98
работы этого компонента подсистемы регистры микроконтроллера
инициализируются предписанными начальными значениями. При
этом счетчик команд PC полагается равным 0, и начинается выполнение прошитых в память программ команд, начиная с команды
номер 0. После этого имеется возможность программным уже способом осуществить конфигурирование ядра микропроцессора, конфигурирование и инициализацию периферийных модулей и т. д.
И только после этого система цифрового программного управления может выполнять свои функции. В связи с широким применением цифровых датчиков в системах управления реального времени задержки старта и рестарта становятся важным параметром,
влияющим на параметры системы в целом.
Имеется возможность контролировать наличие тактирующих
импульсов в процессе работы. Для этого используется монитор наличия тактирующих импульсов. Этот компонент обеспечения надежности опционален и для его использования микроконтроллер
должен быть соответствующим образом сконфигурирован при прошивке программного обеспечения. При этом предполагается использование внешнего источника тактирующих импульсов. Будучи
включенным, монитор при обнаружении отсутствия этих импульсов
обеспечивает дальнейшее выполнение программы путем перехода на
использование тактирующих импульсов от внутреннего источника.
Сторожевой таймер. Основное назначение сторожевого таймер – контроль хода выполнения программы с целью предотвращения зацикливания. Этот таймерный модуль при переполнении
приводит к рестарту программы в отличие от других таймерных
модулей, которые генерируют сигналы прерываний. Соответственно, программное обеспечение должно быть организовано таким образом, чтобы в течение выбранного интервала рестарта программы
из-за срабатывания сторожевого таймера регистр этого таймера
очищался (инициализировался нулем). В противном случае осуществляется рестарт программы. Очистка осуществляется с помощью специальной команды CLRWDT.
Сторожевой таймер использует собственную схему тактирования. Сторожевой таймер подключается опционально, заданием соответствующих битов конфигурации. Биты конфигурации подключают и конфигурируют схему 16-битного постделителя импульсов
для этого таймера.
Минимальное время срабатывания для этого таймера составляет 4 мс, максимальное – несколько больше 2 мин и соответствует
максимальному значению коэффициента постделителя.
99
На практике этот таймер часто используется также для снижения энергопотребления. Для этого микропроцессор после выполнения операций по обработке данных переводится в режим энергосбережения, из которого он выводится по сигналу прерывания от
сторожевого таймера.
Защита программного кода. Конфигурационная память
микроконтроллера состоит из 13 регистров. Значения конфигурационных регистров определяются на этапе прошивки в микроконтроллер программного обеспечения средствами программноинструментальной среды поддержки разработки MPLAB. Имеется
возможность защитить память программ от считывания как всей
целиком, так и отдельных ее страниц.
2.5. Системы управления с распределенной структурой
Бытует мнение, что система управления современного автомобиля сложнее системы управления самолета. Высказывание не бесспорное, но определенные основания для такого утверждения имеются.
Современный автомобиль представляет собой сложный симбиоз электромеханической конструкции и распределенной системы
управления. Считается, что существенное наращивание возможностей современного автомобиля в значительной степени обусловлено
развитием систем управления. Доля стоимости системы управления в нем составляет уже 20 % и имеет тенденцию к быстрому дальнейшему росту.
Например, система управления современного Мерседеса S-класса
содержит как минимум 70 электронных устройств, объединенных в
сеть. Динамику развития этого сегмента систем управления позволяет оценить тот факт, что еще 10 лет назад в большинстве моделей
таких устройств было три. В качестве еще одного примера можно
привести тот факт, что система управления современного карьерного самосвала Caterpiller включает в себя более 700 разнообразных
датчиков и цифровую многоканальную систему цифрового видео.
§ 1. Системы управления современного автомобиля
Многообразие функций систем управления современным транспортным средством привело к тому, что эти системы представляют
собой совокупность нескольких типов сетей.
100
Американская ассоциация SAE (Society of Automotive Engineers)
предложила формальную классификацию типов автомобильных
сетей, основанную на характерной скорости информационного обмена. Эта классификация приведена в табл. 2.7.
Таблица 2.7
Классификация информационно-управляющих сетей автомобиля
Класс
Скорость обмена
Примеры применения
Управление конфигурацией положения
стекол, зеркал, дверных стекол, багажника,
климат-контроль
B
Передача информации общего типа: с датчи10–125 кБит/с
(средняя)
ков, системы питания и т. п.
Управление в реальном режиме времени:
C
0,125–1 Мбит/с активная подвеска, система предотвращения
(высокая)
столкновений, управление двигателем
Мультимедийное оборудование: цифровое
D
>1 Мбит/с
радио и аудиосистемы для управления и прослушивания разнообразного контента
А
(малая)
< 10 кБит/с
В настоящее время идет активное насыщение автомобиля системами класса D за счет широкого использования голосового управления системами автомобиля. С помощью этого интерфейса обеспечивается:
доступ в Internet;
голосовое чтение сообщений электронной почты в движении;
посылка голосовых сообщений по электронной почте;
получение сообщений от системы планирования маршрута;
использование компьютерные игр и систем развлечения пассажирами заднего сидения.
Следует подчеркнуть, что с точки зрения эксплуатации автомобиль представляет собой очень агрессивную среду для используемых электронных устройств и каналов передачи информации.
Эта характеристика формируется из-за совокупного воздействия
факторов: вибрации, необходимости работать в широком температурном диапазоне –40 – + 80 °С при наличии загрязнений маслом,
бензином, водой, льдом и пылью.
Принципиально важно при этом обеспечить высокую надежность и детерминизм поведения сетей контура управления реального времени в условиях воздействия сильных электромагнитных
воздействий (напряженность поля > 200 В/м) и помех, нестабильности питающих напряжений и потенциально возможных нарушений, связанных с короткими замыканиями. Этот набор требований
101
нужно обеспечить при необходимости вписаться в жесткие требованиях по стоимости и времени разработки, а также стоимости систем в производстве.
Повышение функциональных возможностей систем управления приводит к непрерывному росту доли расходов на разработку
этого компонента. В значительной степени этому способствует несовместимость электронных блоков от разных производителей по
причинам использования разных интерфейсов и протоколов, что
приводит к существенным затратам при разработке сетевой составляющей системы управления.
Для сетей классов A, B, C наиболее распространенной технологией передачи данных является применение витой пары. В Европе
доминирующее положение в этой области занимает стандарт CAN
(Controller Area Network), разработанный фирмой Robert Bosch
GmBH еще в середине 1980-х годов для Mercedes Benz S-класса.
Этот стандарт с 1991 года применяется ведущими европейскими и
американскими производителями. В 1994 году SAE использовала
его при разработке стандарта J1939 для сетей класса С, применяемых в грузовиках и автобусах. Этот стандарт впоследствии стал
широко использоваться компаниями большой тройки FORD, GM,
Crysler для сетей классов SAE A,B,C.
Соответственно, вслед за ведущими производителями международная организация по стандартам ISO приняла спецификацию
CAN-стандарта в виде спецификаций ISO 11898 и ISO 11519-2.
Область сетей класса D только формируется. Как всегда в таких
случаях, работа начинается с внутрифирменных стандартов. Представления о ситуации в этой области дает табл. 2.8.
Таблица 2.8
Автомобильные сети класса SAE D
Максимальная скорость,
Компания или вариант
Наименование сети
cреда передачи данных
использования
D2B Domestic Digital
Bus
MOST Media Oriented
Systems Transport
MML Mobile Media Link
102
12 Мбит/ с,
оптоволоконо
25 Мбит/ с,
оптоволоконо
110 Мбит/ с,
оптоволоконо
Optical Chip Consortium
Мерседес S-класса
Delphi Automotive
Systems
AMIC (Automotive
Multimedia Interface
Collaboration:
GM,FORD,TOYOTA,
DAIMLER,CRYSLER,
RENAULT)
Из этой таблицы следует однозначный вывод о неизбежности использования оптоволоконных сетей в качестве структурной основы
класса D.
Сложность систем управления и высокий темп обновления модельного ряда приводит к тому, что даже гиганты автомобильной
промышленности не в состоянии самостоятельно разрабатывать
и производить полный спектр оборудования. Это в значительной степени является причиной широкого использования COTSтехнологий в автомобильной промышленности.
Необходимость обеспечить совместимость электронных узлов,
получаемых от разных производителей, в свою очередь, потребовала разработки и внедрения ряда стандартов, которые, с одной стороны, относятся к программному обеспечению, но с другой – учитывают специфику автомобильных систем управления и являются
частью соответствующих платформ поддержки разработки.
В настоящее время в европейской автомобильной промышленности при разработке систем управления широко применяются три
стандарта:
AUTOSTAR (Automative Open System Architeture);
OSEK/VDK (Open System and the corresponding interfaces for
automotive Electronics/Vehicle Distributed eXecutive);
MISRA C (Motor Industries Software Reliability Association).
§2. Платформенный подход
Системы управления встраиваемого класса представляют собой
пространственно распределенную структуру. Эта структура образована электронными блоками, реализуемыми на микроконтроллерах и объединенных между собой коммуникационными каналами.
Узлы такой сети представляют собой программируемые интеллектуальные датчики, исполнительные устройства, локальные системы обработки данных.
Для современных систем управления распределенного класса
характерным является разнородность используемой элементной
базы. Разработка такого рода систем требует использование ряда
технологий, совокупность которых принято называть платформой.
Платформа представляет собой набор взаимоувязанных решений
по элементной базе, по способу организации сетевой структуры и
по применяемым технологиям разработки программного обеспечения.
103
¶Ä¾Å¾ÆËƹغ¹À¹
ºÁËÆÔ¾
ÅÁÃÉÇÃÇÆËÉÇÄľÉÔ
ǽÆÇÈĹËÆÔ¾
ÃÇÅÈÕ×˾ÉÔ
ª¾Ë¾»Ô¾Ê˹ƽ¹ÉËÔ
-*/$"/&UIFSOFUc
ªÉ¾½ÊË»¹Á
˾ÎÆÇÄǼÁØ
ɹÀɹºÇËÃÁ
ÈÉǼɹÅÅÆǼÇ
Ǻ¾ÊȾоÆÁØ
«ÇÈÇÄǼÁØ
ʾËÁ
ÌÈɹ»Ä¾ÆÁØ
ªÁÊ˾Ź
ÈÁ˹ÆÁØ
ªÉ¾½ÊË»¹
Èǽ½¾É¿ÃÁ
ÈÉǼɹÅÅÆǼÇ
Ǻ¾ÊȾоÆÁØ
Рис. 2.17. Базовые компоненты и технологии разработки
сетевых систем управления
Обобщенная структура платформы для разработки распределенной системы управления изображена на рис. 2.17.
На физическом уровне распределенные системы управления
представляют собой множество электронных блоков, соединенных
каналами связи, по которым осуществляется обмен информацией.
Современные системы управления этого класса используют цифровой способ передачи данных и сигналов управления между узлами
и уровнями системы управления. При описании физической структуры вычислительной сети используют два базовых понятия – топология и узел.
§3. Топология сети
Топология сети – это структура, описывающая способ объединения узлов в распределенной сети управления. На практике широко
используются две типовых топологии: «звезда», «шина». Примеры
этих топологий приведены на рис. 2.18. На их базе реализуются в
случае надобности многоуровневые сети с топологиями, отличающимися от канонических.
В литературе в качестве базовых топологий также иногда указывают «кольцо» и «дерево». Кольцо представляет собой вариант
шины, у которой соединены крайние точки коммуникационного
104
±Áƹ
¬À¾Ä
¬À¾Ä
¬À¾ÄL
¥Ç½ÁÍÁùÏÁØÑÁÆÔ»ÃÇÄÕÏÇ
¬À¾Ä
¬À¾Ä
¬À¾ÄL
»¾À½¹
¬À¾Ä.
Рис. 2.18. Базовые топологии физического уровня сетей
канала, который в этом случае оказывается дублированным. Таким образом, в случае однократного повреждения типа «разрыв»
сеть будет сохранять свою работоспособность при условии соответствующей реализации программного обеспечения.
Для реализации топологии «дерево» требуется наличие узлов с
двумя и более коммуникационными модулями либо специальных
узлов ветвления. Этот вариант можно рассматривать как симбиоз
топологий «звезда» и «шина».
Следует различать физическую и логическую топологии сетей.
Например, если в сети с физической топологией «шина» один из
узлов имеет возможность управления доступом к коммуникационному каналу и обеспечивает поочередный опрос и обмен информации с другими узлами, то такая сеть характеризуется как «физическая шина» и «логическая звезда».
Матричный способ описания структуры информационного
обмена. Наиболее универсальным способом описания структуры
сети и структуры информационного обмена является граф обмена,
описываемый матрицей. В матрице описания наличие связи между
i и j узлами описывается 1 в позиции (i,j), отсутствие связи обозначается как 0. Этот способ иллюстрируется рис. 2.19.
В случае шинной топологии матрица является полностью заполненной, что отражает тот факт, что каждый из узлов может осуществить обмен с другим узлом этой сети. Для топологии «звезда» все
узлы осуществляют обмен через узел М.
Такой тип матриц носит название «окаймленная диагональная
матрица». В силу принятого соглашения о значениях элементов
матрицы будут симметричными.
105
c
c
#
c
4 c
c
c
Рис. 2.19. Матрицы описания топологий «шина» и «звезда»
Матричный способ описания структуры информационного обмена является ключевым при анализе таких свойств систем управления, как наблюдаемость и управляемость [12].
Узел. Электронное устройство, реализующее специфицированную часть функций системы управления и имеющее в своем составе
модуль реализации физического уровня протокола доступа к коммуникационному каналу.
В качестве узлов в распределенных сетях выступают интеллектуальные датчики, устройства управления, коммуникационные
узлы, контроллеры.
Электронный блок, обеспечивающий реализацию функционально полного набора функций системы управления «измерение –
расчет-управляющее воздействие» и конструктивно обособленный,
называют контроллером.
Для современных распределенных систем управления является
характерным использование узлов, реализованных на базе широкого спектра микроконтроллеров: от 4- до 32-битных, с разными
архитектурами и разных производителей. Так, устройство, контролирующее состояние привязных ремней автомобиля, вполне может
быть реализовано на 4-битном микроконтроллере, в то время как
для системы управления двигателем обычно используются 16- или
32-битные.
§4. Интеллектуальные узлы
Основой распределенных систем управления являются интеллектуальные сетевые датчики и устройства управления. Прилагательное «интеллектуальные» в данном случае означает наличие возможности реализации сложной обработки информации узлом сети.
Современная элементная база обеспечивает возможность использования микроконтроллеров в непосредственной близости от
чувствительных элементов. Датчики этого класса обеспечивают
106
возможность аналого-цифрового преобразования сигналов с аналоговых сенсоров, их локальной обработки и передачи по цифровому каналу связи на верхний уровень системы управления. При
этом достигается возможность существенного улучшения качества
управления за счет существенного ослабления помех в канале передачи данных.
Следует подчеркнуть, что на базе современных микроконтроллеров возможна реализация как прямых, так и косвенных измерений, а также создание датчиков активного типа. В качестве примера можно указать ультразвуковые датчики расстояний. В этом
случае микроконтроллер осуществляет управление излучающим
элементом и ультразвуковым микрофоном. Встроенные таймеры микроконтроллера позволяют осуществить задержку времени
между моментом начала излучения зондирующего импульса и началом приема отраженного импульса. На основании этих данных
имеется возможность рассчитать расстояние до препятствия. При
этом следует отметить, что микроконтроллер обеспечивает возможность многоканального измерения.
Дополнительно возможна реализация функций локального
управления и индикации. Компактность реализации обеспечивается за счет использования периферийных модулей микроконтроллера. Универсальность системы обеспечивается за счет возможности
настраивания параметров посредством цифрового интерфейса.
Обобщенная структура сетевого интеллектуального узла изображена на рис. 2.20. Такой узел вполне может быть реализован
на микроконтроллере PIC18F4220/4320, который рассматривался
¤ÇùÄÕÆǾ
ÌÈɹ»Ä¾ÆÁ¾
¤ÇùÄÕƹØ
ÁƽÁùÏÁØ
¨Á˹ÆÁ¾
ªÁ¼Æ¹ÄÔ
ʹƹÄǼǻÔÎ
ʾÆÊÇÉÇ»
ªÁ¼Æ¹ÄÔ
ÊÏÁÍÉÇ»ÔÎ
»Îǽǻ
¯ÁÍÉÇ»ÇÂ
ÁÆ˾É;ÂÊ
Рис. 2.20. Структура интеллектуального узла
107
выше. Микроконтроллеры этого семейства обеспечивают возможность обработки сигналов по 13 каналам с 10-битным разрешением. При этом имеется возможность выработки управляющих воздействий по нескольким каналам.
Имеющийся в составе коммуникационный модуль обеспечивает
возможность работать по шинам SPI и UART (топология сети «звезда») или I2C (топология «шина»). Наличие универсальных портов
входа-выхода существенно расширяет возможности разработчиков
в части реализации сервисных функций.
По определению, распределенные системы управления подразумевают наличие унифицированных решений на сетевые компоненты. В качестве примера такого решения можно указать спецификацию SDS (Smart Distributed System), разработанную компании
Honeywell Inc. (Micro Switch Division, www.honeywell.sensing.com),
которая является одним из ведущих поставщиков элементов систем управления для аэрокосмических применений.
Стандарт SDS представляет собой недорогое и законченное решение для сетевого управления интеллектуальными датчиками и исполнительными устройствами от центрального контроллера (PLC,
компьютера) в системах промышленной автоматизации. По степени завершенности от спецификаций физической среды до прикладного уровня, ориентировке на снижение стоимости SDS-стандарт
напоминает DeviceNet. Шинная топология представляет собой линейную шину (магистраль или транк) с короткими отводами.
Определены два базовых типа кабельной разводки:
Mini (применяемый при сборке сегмента сети) 4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем;
Micro (для подключения физических устройств к сети)
4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта для экрана кабеля.
В сети SDS допускается и обычная проводная разводка с использованием открытых клеммных соединителей. Всеми типами
кабельной разводки предусмотрено подведение питающего напряжения к узлам.
Сеть SDS всегда требует наличия единственного мастераменеджера сети как минимум на этапе включения для выполнения
автонастройки скорости передачи модулей. В процессе работы сети
допускается наличие нескольких мастеров на шине, но они должны функционировать в пределах своих адресных доменов, а при
включении сети только один из них может брать на себя функцию
сетевого менеджера для автонастройки скорости устройств.
108
§5. Шина CAN
В автомобильной промышленности в качестве основы распределенной системы управления повсеместно используется шина CAN.
Физический и канальный уровень для такого рода сетей реализуется
в виде отдельных микросхем, называемых CAN-контроллерами.
Впервые идея CAN была предложена в середине 80-х немецкой
компанией Robert Bosch, которая задумывала ее в качестве экономичного средства для объединения контроллеров, расположенных
внутри автомобиля. Традиционный способ связи распределенных
по объекту контроллеров жгутами проводов по своей технической
сложности, по ценовым и по весовым параметрам для массового изделия, которым является автомобиль, оказался непригоден.
Требовалось альтернативное решение, сокращающее количество
проводов, поэтому был предложен протокол CAN, для которого достаточно любой проводной пары. Среди многочисленных факторов,
обеспечивших взлет популярности CAN в последние годы, следует
отметить разнообразие и доступность элементной базы CAN и низкую стоимость.
Протокол CAN обеспечивает высокий уровень защиты данных
от повреждения даже при работе в сложных условиях (сильные помехи). При этом достигается достаточно большая скорость передачи
данных (до 1 Мбит/с). Высокая степень и надежности сети достигается благодаря развитым механизмам обнаружения и исправления
ошибок, самоизоляции неисправных узлов. Нечувствительность к
высокому уровню электромагнитных помех обеспечивает сети широчайшую сферу применения.
Существенной особенностью этого протокола является использование контекстной адресации передаваемой информации. При
таком подходе кадр передаваемой информация маркируется типом
содержащейся в нем информации и доступен всем узлам сети, которые сами определяют необходимость ее использования. По сути
дела, это вариант широковещательного доступа, который не требует использования сетевого и сеансового уровней протокола классической семиуровневой модели OSI.
Важным достоинством CAN является также то, что разработчик
системы может влиять на приоритет сообщений, с тем чтобы самые
важные из них не ожидали в очереди на отправку. Это свойство
CAN позволяет создавать на его основе распределенные системы
управления реального времени с малыми временами реакции на
приоритетные события.
109
Топология сети CAN. Наиболее распространена спецификация стандарта ISO 11898. Этот стандарт в качестве среды передачи
определяет двухпроводную дифференциальную линию с импедансом 120 Ом.
Топология CAN-сети управления показана на рис. 2.21. CANконтроллеры соединяются с помощью шины, которая имеет как
минимум два провода CAN_H и CAN_L, по которым передаются
сигналы при помощи напряжений относительно общей земли, формируемые специализированными приемопередатчиками. Передаваемый бит кодируется с помощью двух импульсов напряжений,
подаваемых одновременно на CAN_H и CAN_L. Минимальная длина импульса составляет 1 мкс.
Приемопередатчики реализуют ряд дополнительных функций,
включающих:
регулировку скорости нарастания входного сигнала путем изменением тока на входе;
ограничение тока встроенной схемой, которая защищает выходы передатчиков от повреждения при возможных замыканиях линий CAN_H и CAN_L с цепями питания, а также от кратковременного повышения напряжения на этих линиях;
внутреннюю тепловую защиту;
режим пониженного энергопотребления, в котором приемники
продолжают сообщать контроллеру о состоянии шины, для того
чтобы при обнаружении на шине информационных сигналов он мог
вывести приемопередатчики в нормальный режим работы.
Максимальная скорость передачи данных в соответствии с этом
стандартом 1 Mбит/с на расстояния до 40 метров. Ограничение на
длину кабеля связано с конечной скоростью распространения сигнала и механизмом побитового арбитража. Во время арбитража
шины все узлы сети должны получать текущий бит передачи одно§ºÒ¹ØÀ¾ÅÄØ
¬ ž¤
¬ ž¤c
¬ ž¤/
$"/@)
Δ6
3ÇÅ
$"/@-
Рис. 2.21. Физическая среда ISO 11898-2
110
временно, т. е. сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети.
Немалую роль в популярности этого стандарта играет и возможность поддержки разнотипных физических сред передачи данных –
от дешевой витой пары до оптоволокна и радиоканала.
Физический уровень. Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т. п. Существует несколько спецификаций
на физический уровень протокола CAN: ISO 11898, ISO 11519, SAE
J2411.
Общая схема реализации физического уровня разрабатывалась
с целью обеспечения высокой помехозащищенности и использует
дифференциальную схему представления битов.
Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Типовое значение напряжений
для представления логической единицы: СAN_H = 3,5 В, a CAN_L
= 1,5 В (импульсы с минимальной длительностью 1 мкс).
Логическая единица регистрируется, когда сигналы CAN_HI и
CAN_LO одинаковы (отличаются менее чем на 0,5 В). Типовое значение напряжений 2,5 В.
Логический ноль называется доминантным битом, а логическая
единица – рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN.
При одновременной передаче в шину логического нуля и единицы на шине будет зарегистрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).
Структура формата передачи данных. Данные по CAN-сети
пересылаются в виде отдельных кадров стандартного формата. Разрешено использование четырех видов кадров:
кадр для передачи данных (data frame);
кадр для запроса на передачу кадра данных (remote frame);
кадр перегрузки (overload frame) для обеспечения промежутка
между кадрами данных;
кадр ошибки (error frame) для передачи сообщения об ошибке.
Кадры данных и запроса отделяются от предыдущих кадров межкадровым промежутком. Формат кадра данных бывает
двух типов: базовый и расширенный. Формат базового кадра приведен в табл. 2.9.
Как правило, CAN-контроллер позволяет задавать лишь два
поля – поле идентификатора и поле данных. Остальные поля ис111
пользуются для передачи специфических данных, необходимых
для функционирования узла в сети.
Таблица 2.9.
Поле
Формат базового кадра данных CANbus
Длина
Описание
в битах
Начало кадра (SOF)
1 бит
Идентификатор
Запрос на передачу (RTR)
Бит расширения идентификатора (IDE)
Зарезервированный бит (R0)
Длина данных (DLC)
Поле данных
11 бит
1 бит
1 бит
Сигнализирует начало передачи
кадра
Уникальный идентификатор
1 бит
Резерв
1 бит
Длина поля данных в байтах (0–8)
0–8 байт Передаваемые данные (длина
определяется значением DLC)
15 бит Контрольная сумма всего кадра
1 бит
Контрольная сумма (CRC)
Разграничитель контрольной суммы
Промежуток подтверждения 1 бит
(ACK)
Разграничитель подтверж- 1 бит
дения
Конец кадра (EOF)
7 бит
Поле идентификатора служит уникальным именем для типа сообщения и определяет то, кем будет принято и как будет интерпретировано следующее за ним поле данных. Чему именно (арифметически) равно это число, в общем случае не имеет значения. Такая контекстная адресация обладает рядом достоинств для сетей небольшого масштаба. Она обеспечивает максимально возможную простоту
модернизации. Поскольку децентрализованные контроллеры никак
не связаны между собой логически, добавление нового элемента в систему никак не повлияет на поведение всех остальных.
Арбитраж шины CAN. Одной из уникальных особенностей
стандарта CAN является механизм так называемого недеструктивного арбитража шины посредством сравнения бит-идентификаторов
конкурирующих сообщений.
Синхронизация шины осуществляется битом начала передачи
кадра – SOF. Перед началом передачи узел выставляет единичный
доминантный бит SOF, который маркирует передаваемый кадр. Все
узлы контролируют состояние шины и при наличии на ней активно112
сти не начинают передачу до тех пор, пока шина не освободится. Это
рано или поздно происходит, так как длина передаваемых сообщений ограничена. Таким образом, ситуация коллизии на шине возможна в случае начала одновременной передачи SOF-битов разными
узлами. Вслед за этим битом передаются биты идентификатора.
Пример реализации механизма недеструктивного арбитража
шины приведен на рис. 2.22.
Идентификаторы используются в качестве основного инструмента, используемого в процедуре разрешения коллизий. В CAN в
качестве основного критерия для разбора коллизий, для принятия
решения, кому отдать канал, используется приоритет сообщений.
Если одновременно несколько узлов начали передачу, и при
этом произошла коллизия, происходит суперпозиция передаваемых идентификаторов. Идентификаторы последовательно, побитно (bitwise), начиная со старшего, налагаются друг на друга и в их
«противоборстве» выигрывает тот, у кого меньше арифметическое
значение идентификатора, а значит, выше приоритет. Доминантный «ноль» подавит единицы, и в любом случае к концу передачи
поля идентификатора оно станет равно более приоритетному значе-
¬À¾Ä5Y
4
3
%BUB
0 šÁËÔÁ½¾ÆËÁÍÁùËÇɹ
5 $POUSPM
'JFME
cc 3 'JFME
' ɾ¿ÁÅÈÉÇÊÄÌÑÁ»¹ÆÁØ
ÑÁÆÔ
¬À¾Ä5Y
¬À¾Ä5Y
¬À¾Ä5Y
ɾ¿ÁÅÈÉÇÊÄÌÑÁ»¹ÆÁØ
ÑÁÆÔ
%-$
¹ÆÆÔ¾
ɾ¿ÁÅÈÉÇÊÄÌÑÁ»¹ÆÁØÑÁÆÔ
¬ÉÇ»¾ÆÕɾϾÊÊÁ»ÆǼǺÁ˹
ªÍÇÉÅÁÉÇ»¹ÆÆÔ¹½É¾Ê
»Ä¹½¾ÄÕϹÑÁÆÔ3Y
¬ÉÇ»¾ÆÕ½ÇÅÁƹÆËÆǼǺÁ˹
Рис. 2.22. Механизм арбитража шины CAN:
Tx – режим передачи; Rx – режим приема
113
нию. Таким образом, на этапе разработки определение идентификатора для любого сообщения в системе предопределяет его приоритетность в обслуживании.
Соответственно, приоритетность сообщения определяется значением идентификатора. Приоритет тем больше, чем идентификатор меньше.
Скорость передачи данных. Хорошие показатели шины и широкая доступность элементной базы обеспечили возможность использования этой шины для систем управления с существенно
большими линейными размерами, чем автомобиль.
Спецификация CAN исходит из предположения, что все CANконтроллеры принимают сигналы с шины одновременно, т. е. в
одно и то же время один и тот же бит принимается всеми контроллерами в сети. С одной стороны, такое положение вещей делает возможным побитовый арбитраж, а с другой стороны, ограничивает
длину CANbus. Сигнал распространяется по CANbus с конечной
скоростью и для правильной работы CAN нужно, чтобы все контроллеры «услышали» его почти одновременно. Почти – потому что
каждый контроллер принимает бит в течение определённого промежутка времени, отсчитываемого системным часам. Таким образом,
чем меньше максимальное расстояние между контроллерами, тем
выше достижимая максимальная скорость передачи данных.
Зависимость достижимой скорости передачи по шине CAN в зависимости от расстояния показана в табл. 2.10.
Таблица 2.10
Длина шины, м
30
50
100
250
500
1000
2500
5000
Скорость передачи данных для шины CAN
Максимальная скорость передачи
Битовое время, мкс
1 Мбит/с
800 Кбит/с
500 Кбит/с
250 Кбит/с
125 Кбит/с
62.5 Кбит/с
20 Кбит/с
10 Кбит/с
1
1,25
2
4
8
20
50
100
Контрольные вопросы и задания к главе 2
1. Какое минимальное количество шин требуется для реализации микропроцессора ?
114
2. В чем преимущество использования шинных топологий в распределенных системах управления ?
3. В чем различие в назначении систем прерываний в микропроцессоре и микроконтроллере ?
4. Как осуществляется подсчет времени в цифровых системах
управления и от чего зависит точность измерения временных интервалов ?
5. Как выглядит матрица описания структуры «логическое
кольцо»?
6. Возможна ли организация системы управления с топологиями: аппаратная шина – логическое кольцо ?
7. Какая топология используется в системе управления марсохода Spirit?
8. Проанализируйте недостатки использования системы управления, реализованной в формате PC-104 с 16-битным модулем АЦП
с точки зрения точности и надежности системы.
9. Оцените сверху интенсивность информационных потоков в
распределенной системе управления современного автомобиля.
10. Как может быть реализован анализ целостности информационно-управляющей сети автомобиля ?
Литература к главе 2
1. Turing A. M. (1936), «On Computable Numbers, with an
Application to the Entscheidungsproblem» // Proc. of the London
Mathematical Society, 2 42: 230–65, 1937.
2. Gordon E. Moore. Cramming more components onto integrated
circuits. // Electronics, Volume 38, Number 8, April 19, 1965.
3. Amdahl G. M. Validity of the single-processor approach to
achieving large scale computing capabilities..// Proc. of the AFIPS
Conference, 1967, pp. 483–485.
4. Gustavson J. Re-evaluating Amdahl’s law. // Communications
ACM, 1988, v. 31.
5. Grama A., Gupta A., Kumar V. Isoefficiency: Measuring the
scalability of parallel algorithms and architectures. // IEEE Parallel
and Distributed Technology, 1993, pp. 12–21.
6. PC/104-Plus Specification Version 1.1 PC/104 Consortium June
1997.
7. Володин А. Ю., Горбачев С. В., Шейнин Ю. Е. Шина PCI в высокопроизводительных микропроцессорных системах: учебное пособие/ СПбГУАП. СПб., 1999. 100 c.
115
8. PICMG 2.0 R3.0 CompactPCI Specification, Revision 3.0. PCI
Industrial Computers Manufacturers Group (PICMG), 1 October
1999.
9. PICMG 2.1 CompactPCI Hot Swap, Revision 1.0. PCI Industrial
Computers Manufacturers Group (PICMG), 3 August, 1998.
10. PICMG 1.1 R1.0. PCI-PCI Bridge Board Connector For
Single Board Computer. Revision 1.0. PCI Industrial Computers
Manufacturers Group (PICMG).
11. PICMG 2.11 R1.0.CompactPCI Power Interface. Revision 1.0.
PCI Industrial Computers Manufacturers Group (PICMG), October 1,
1999.
12. Гроп Д. Методы идентификации систем. М.: Мир, 1979.
С. 302.
116
Глава 3. СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Одной из главных тенденций развития современной техники
является массированный переход к интеллектуальным системам
управления за счет использования встроенных систем программного управления. Наличие встроенной системы управления становится обязательным элементом любого современного конкурентного товара, начиная от бытовых систем и заканчивая элементами
сложных автоматических комплексов, работающих в экстремальных эксплуатационных условиях.
Система управления реального времени встраиваемого класса должна обеспечивать выработку управляющих воздействий на
основании задаваемого режима управления и обработки показаний
датчиков о состоянии системы. Принципиально важным является
необходимость обеспечения сбора данных и выработки управляющих воздействий по многим каналам со специфицированными временными параметрами, обеспечивающими актуальность данных и
воздействий.
Система управления включает в себя аппаратные и программные компоненты. Наличие аппаратного обеспечения, адекватного
по структуре и составу функциям системы управления, является необходимым условием для возможности реализации системы
управления. Однако даже идеально спроектированная с аппаратной точки зрения система неработоспособна без соответствующего
программного обеспечения.
3.1. Технологические циклы разработки
В современных сетевых информационно-управляющих системах
число процессоров и задач может достигать нескольких десятков и
даже сотен штук. Причем, когда речь идет о распределенных системах управления, сложность программного обеспечения существенно выше по сравнению с автономными системами управления. Эта
глава ставит своей задачей введение базовых понятий и рассмотрение основных технологий разработки программного обеспечения.
§1. Введение
Разработка программного обеспечения для систем управления является частью технологического процесса производства, во
117
многом определяющей ключевые параметры конечного изделия.
Оценивая ситуацию в целом, можно констатировать, что, несмотря
на важность задачи и огромные усилия, технология разработки
программного обеспечения для систем встраиваемого класса существенно отстает от технологии разработки новых чипов.
В первом приближении все множество задач разработки систем
управления можно разбить на два класса. В первый попадают системы, для которых аппаратный компонент собирается из готовых
модулей, и под него разрабатывается программное обеспечение.
Этот класс обычно называют системной интеграцией. Во второй –
системы, для которых требуется выполнить разработку как аппаратного, так и программного компонента. Разработки этого класса
будем называть разработками полного цикла.
Настоящий этап в развитии аппаратного обеспечения систем
управления характеризуется двумя тенденциями: переходом к
использованию многоядерных микропроцессоров и широкому использованию сетевых технологий. Фактически это означает, что в
системе управления одновременно могут выполняться параллельно до нескольких сотен задач (процессов), которые, как правило,
имеют временные ограничения на скорость выполнения, накладываемые объектом управления. При этом на первоначальных этапах
разработки временные характеристики, как правило, известны
недостаточно точно и требуется обеспечение возможности быстрой
перестройки алгоритмов обработки и управления, вплоть до изменения структуры не только программного обеспечения, но и используемых схемотехнических решений.
В настоящее время в авиационной промышленности используется большое количество стандартов. При этом стандарты следует
рассматривать как систематизированный опыт разработок систем
управления, проверенный и проверяемый практикой. Их обилие,
с одной стороны, является косвенным показателем проделанной
к настоящему времени работы, а с другой – свидетельством отсутствия единого рецепта на все случаи жизни.
Есть еще один важный аспект, связанный со стандартизацией.
В мире не так уж много стран, имеющих полномасштабную аэрокосмическую индустрию. Эти страны, с одной стороны, конкурируют на глобальном рынке, а с другой – сотрудничают. Например,
российские компании являются ключевым партнером в создании и
поддержке международной космической станции. Создание и поддержка этой научной лаборатории требовала и требует аппаратной
и программной совместимости большого количества систем. В этом
118
случае следование стандартам обеспечивает возможность участия в
таких проектах и позволяет существенно снизить издержки на их
реализацию.
Эти объективные реальности способствуют сближению национальных стандартов. Соответственно, привязка отечественных
стандартов к международным является одним из ключевых факторов обеспечения конкурентоспособности российских компаний,
работающих в аэрокосмической сфере.
§2. Базовые понятия
Цифровые системы управления состоят из двух взаимозависимых компонентов: аппаратного и программного. Аппаратный компонент обеспечивает возможность реализации алгоритмов управления, описываемых с помощью программного компонента.
Программный компонент системы управления представляет собой упорядоченную последовательность команд, записанную в память программ и называемую программным кодом. Введем развернутые определения для ряда базовых понятий.
Алгоритм (ГОСТ Р 51904). Конечное множество четко определенных правил, которые задают последовательность действий при
выполнении конкретной задачи.
Команда. Представляет собой битовую строку, состоящую из
нескольких полей:
£Ç½ÃÇÅ¹Æ½Ô ™½É¾Ê¹ÇȾɹƽǻ
¨¹É¹Å¾ËÉÔ
Размер поля кода команды зависит от максимального количества команд для используемого ядра. Структура поля адресов зависит от архитектуры ядра, которая определяет максимальное количество адресов операндов: один, два, три. Размер этого поля зависит
от значения максимально возможного адреса операнда. В технической литературе часто употребляется термин «адресное пространство». Суммарный размер битовой строки, описывающей команду,
определяет количество разрядов в шине (ширину шины) считывания команд из памяти. Соответственно, набор команд определяется
архитектурой используемого микропроцессора.
Поле параметров содержит параметры, определяющие вариант реализации команды. Например, параметр может определять
адрес, где будет храниться результат выполнения команды. Это
119
может быть адрес одного из операндов или рабочий регистр CPU.
Использование этого поля часто является опциональным.
Компонент (ГОСТ Р 51904). Представляет собой замкнутую
часть, комбинацию или элемент, который выполняет в системе отдельную функцию. Компонент представляет собой набор команд,
оформленный в соответствии с правилами, определяемыми используемым программным инструментарием.
Программный код. В соответствии с ГОСТ Р 51904 код – это способ реализация конкретных данных или конкретной компьютерной программы в символьной форме, например как исходный код,
объектный код или машинный код. В англоязычной литературе и
документации этому понятию соответствует «code» или «program
code», которые обозначают программу, представленную в виде набора команд.
Программные коды реализуют специфицированные для конкретного применения алгоритмы и представляют собой их пошаговое описание с помощью системы команд конкретного микроконтроллера или микропроцессора. Полный набор команд для
конкретного микропроцессорного или микроконтроллерного ядра
представляет собой низкоуровневый язык, свой для каждого ядра,
который называется ассемблером (assembler). Трансляция описания алгоритма функционирования, выполненная на ассемблере, в
программный код осуществляется компиляторами.
Для высокоуровневого описания алгоритмов в настоящее время
очень популярно использование языка С, который стал стандартом де-факто языка программирования для встраиваемых систем
управления. Соответственно, компиляторы с этого языка входят в
состав программно-инструментальных средств.
В последнее время начинает набирать популярность язык JAVA,
который является средством разработки программного обеспечения
для виртуальной вычислительной машины. Виртуальная вычислительная машина представляет собой универсальную модель, а процесс выполнения JAVA-программы представляет собой эмуляцию.
Реализация виртуальной машины требует ресурсов микропроцессора и такого рода ПО будет работать медленнее. Принципиально важным обстоятельством является легкая переносимость кода и, как
следствие, возможность организации распараллеленной разработки.
Для того чтобы система управления встраиваемого класса была
работоспособна, в память программ микроконтроллера(ов) должен
быть записан программный код, представляющей файл из битовых
строк, представляющих собой команды.
120
Для микропроцессоров эта операция, как правило, выполняется с помощью специального устройства, называемого программатором, а сама операцию называют «прошивкой программного обеспечения». В микроконтроллерах последних поколений начали реализовывать возможность автономной работы с памятью программ,
что обеспечивает принципиальную возможность самостоятельного
перепрограммирования.
Для систем управления, реализуемых на микропроцессорах,
программный код записывается в схему памяти под управлением
ядра операционной системы. Эта операция выполняется в специальных режимах и обеспечивает возможность обновления кода с
разных носителей. В общем случае следует говорить о схемах памяти или даже устройствах памяти и сложной дисциплине распределения отдельных фрагментов кода.
Единицы измерения времени. Применительно к системам программного управления целесообразно использовать безразмерную
единицу в виде количества командных циклов [1]. Пересчет безразмерных единиц в размерные и наоборот осуществляется посредством учета тактовой частоты f и количества тактов, необходимых
для реализации одного командного цикла Nt
t[сек] = 1/(f×Nt)[ команд]
(3.1)
Интегрированная среда разработки (Integrated Development
Environment – IDE). Представляет собой комплекс взаимоувязанных программно-аппаратных решений, обеспечивающих полный
цикл разработки прикладного программного обеспечения.
Современные IDE обеспечивают поддержку набора аппаратных
средств, используемых при разработке: внутрисхемные эмуляторы,
программаторы и т. д., а также их программно-инструментальных
оболочек. Интегрированные среды включают в себя весь доступный арсенал программно-инструментальных средств, неполный
перечень которых включает в себя средства управления проектами, редакторы, компиляторы с ассемблеров и языка С, симуляторы, средства отладки в реальном времени и т. п.
Разработка программного обеспечения для встраиваемых систем управления – это итеративный процесс, который, в первом
приближении, представляет собой многократно повторяемый
цикл, показанный на рис. 3.1. Оговорка «в первом приближении»
отражает принципиальную возможность возникновения необходимости разработки новых схемотехнических решений. Например,
из-за невозможности реализовать специфицированные параметры
121
§ÈÁʹÆÁ¾¹Ä¼ÇÉÁËŹ
ƹ¹Êʾźľɾ
ŹÃÉǹÊʾźľɾ
ØÀÔþª
£ÇÉɾÃËÁÉǻù
ÇÈÁʹÆÁعļÇÉÁËŹ
ÅǽÁÍÁùÏÁØ
¹Ä¼ÇÉÁËŹ
«É¹ÆÊÄØÏÁØÁÄÁ
ÃÇÅÈÁÄØÏÁØÃǽ¹
ʺÇÉùÃǽ¹
§ËĹ½Ã¹
ÊÁÊÈÇÄÕÀÇ»¹ÆÁ¾Å
ÊÁÅÌÄØËÇɹ
ʺÇÉùÃǽ¹
¨ÉÇÑÁ»Ã¹Ãǽ¹»Å¹Ã¾Ë
ÌÊËÉÇÂÊË»¹ÁÄÁ
»ÇÈÔËÆÔÂǺɹÀ¾Ï
§ËĹ½Ã¹ÊÁÊÈÇÄÕÀÇ»¹ÆÁ¾Å
»ÆÌËÉÁÊξÅÆǼÇÖÅÌÄØËÇɹ
Рис. 3.1. Стандартный цикл разработки программного обеспечения
системы управления на выбранном типе микроконтроллера или изза ошибок при проектировании аппаратного компонента системы.
Отладка. Это ключевой элемент цикла разработки систем
управления встраиваемого класса, заключающийся в проверке возможности обеспечения специфицированных параметров на макете
или опытном образце системы при использовании текущей версии
программного обеспечения.
Существенная доля объема работ, выполняемых при отладке,
выполняется с фрагментами (модулями) разрабатываемого программного обеспечения, реализуемыми в виде тестовых задач. При
разработке отдельных компонентов системы может использоваться отладка с использованием математической модели конкретного
микроконтроллера, реализуемого с использованием симулятора.
Этот цикл разработки эффективен для наполнения специализированных библиотек математической обработки.
§3. V-модель
В стандарте МЭК 61508 «Функциональная безопасность систем
электрических, электронных, программируемых электронных,
связанных с безопасностью» описана так называемая V-модель
процесса разработки программного обеспечения сложных систем
управления для ответственных применений. Эта модель показана
на рис. 3.2.
Как следует из этого рисунка, восходящая ветка V-модели процесса разработки программного обеспечения состоит из тестирования. Успешное прохождение этой ветви процесса разработки яв122
¨É¾½ÈÉǾÃËÆÔ¾ÁÊÊľ½Ç»¹ÆÁØ
ÊȾÏÁÍÁùÏÁØËɾºÇ»¹ÆÁÂÁ
ɹÀɹºÇËù˾ÎÆÁоÊÃǼÇ
«¾ÊËÁÉÇ»¹ÆÁ¾ÊÁÊ˾ÅÔ
ƹÈÉÁ¾ÅÇʽ¹ËÇÐÆÔÎ
ÁÊÈÔ˹ÆÁØÎ
¡Æ˾¼É¹ÏÁØÁÃÇÅÈľÃÊÆǾ
˾ÊËÁÉÇ»¹ÆÁ¾
ÊÁÊ˾ÅÔ ©¹ÀɹºÇËù
À¹½¹ÆÁØ
¹ÉÎÁ˾ÃËÌÉÔ
ÊÁÊ˾ÅÔ ¨ÉǾÃË
ÊÁÊ˾ÅÔ
ÊÁÊ˾ÅÔ
¡Æ˾¼É¹ÏÁØÁ˾ÊËÁÉÇ»¹ÆÁ¾
ÈÉǼɹÅÅÆǼÇ
Ǻ¾ÊȾоÆÁØ
¨ÉǾÃËÔ
ÅǽÌľÂ
«¾ÊËÁÉÇ»¹ÆÁ¾
ÅǽÌľ £Ç½ÁÉÇ»¹ÆÁ¾
Рис. 3.2. V-модель разработки прикладного программного обеспечения
ляется необходимым условием для начала использования разработанной системы.
Для систем управления, относящихся к первому классу, характерно широкое использование готовых компонентов. Это находит
свое отражение в размере объемов кода. Среднее количество строк
исходного кода в приложении выросло с 8000 в начале 90-х годов до
1000000 к 2005 году [2]. При этом операции тестирования занимают от 50 до 70 % от общей трудоемкости по разработке программного обеспечения. Соответственно, сам процесс разработки приобретает черты сложного технологического процесса, выполняемого
большими коллективами разработчиков, что приводит к специализации и регламентации базовых операций.
Формализация применяемых процедур тестирования и привязка их к международным стандартам является одним из ключевых
условий возможности организации международной кооперации в
аэрокосмической сфере. Соответственно, естественным следствием
этого является появление отечественного аналога американского
авиационного стандарта DO-178B в виде ГОСТ Р 51904, введенного
в действие в 2002 году.
Применительно к процедурам тестирования этот стандарт не
только определяет цели и методы тестирования для каждой из ступеней V-модели, но содержит перечень типичных ошибок. Так как
стандарт это – не учебное пособие, то наличие такого перечня явля123
ется, по сути дела, минимальным набором тестов, который должно
пройти разработанное программное обеспечение.
В качестве содержательного примера рассмотрим набор типичных требований, предъявляемых этим стандартом к тестовым процедурам для модулей. Приведенная ниже цитата из ГОСТа содержит минимальные правки: «Целью тестирования модулей, основанного на требованиях, является обеспечение гарантии того, что
программные компоненты удовлетворяют требованиям нижнего
уровня.
Типичные ошибки, выявляемые этим методом тестирования:
1) ошибка алгоритма в реализации требований к ПО;
2) некорректная работа в цикле;
3) некорректные логические решения;
4) отказ при обработке правильно сформированных комбинаций
входных условий;
5) некорректная реакция на отсутствующие или искаженные
входные данные;
6) некорректная обработка исключительных ситуаций типа
арифметических ошибок или выхода за границы массива;
7) некорректная последовательность вычислений;
8) неадекватная точность вычисления в алгоритме, точность
представления данных или выполнение расчетов».
Полный объем ГОСТа составляет 67 страниц, и он свободно распространяется. Приведенная цитата объясняет необходимость использования сертифицированных библиотек как единственно возможного способа выполнить разработку в срок и по разумной цене.
§4. Системная интеграция
Возможность создания системы управления с максимальным
использованием готовых решений существенным образом зависит
от ее назначения и специфицированных требований к разрабатываемой системе. Основная мотивация такого подхода заключается
в необходимости вписаться в ограничения проекта по срокам и стоимости его реализации.
Процесс разработки структуры и выбора компонентной базы
для реализации аппаратного компонента для систем первого класса обычно относят к классу задач системной интеграцией. Обзор
современных тенденций в разработке аппаратного обеспечения
был сделан в предыдущей главе. При чем этот выбор, как правило,
124
диктует и выбор соответствующей программно-инструментальной
платформы.
Разработка аппаратного компонента – дело дорогостоящее, а главное, занимающее много времени, что и объясняет широкое использование COTS-технологий. Как правило, аппаратное обеспечение типовых систем промышленной и бытовой автоматизации создается с
применением этой технологии. Компоненты для систем такого класса разрабатываются и производятся целым рядом специализированных компанией. Эти же компании берут на себя функции отслеживания тенденций развития рынка и разработки спецификаций или
проектов стандартов, обеспечивающих возможность создания самосогласованных аппаратно-программных решений.
Системы управления, отнесенные к первому классу, как правило, реализуются на базе одноплатных компьютеров и специализированных модулей. Соответственно, программное обеспечение для
встраиваемых систем управления этого класса разрабатывается на
основе готовых решений в виде операционных систем реального
времени и специализированных программно-инструментальных
средств.
При этом возникает ряд сложностей с гарантией качества конечного продукта. Стандарт европейской организации по стандартизации космической техники ECSS-E-40C представляет собой попытку формализации процесса разработки программного обеспечения.
Этот стандарт идейно совместим со стандартами DO-178B и ГОСТ Р
51904, но не так детализирован.
Программное обеспечение, согласно положениям этого стандарта, делится на три группы, определяемые как: COTS (commercialoff-the-shelf), OTS (off-the-shelf) и MOTS (modified-off-the-shelf).
При этом группы COTS и OTS, по сути дела, не имеют различий.
Сам процесс разработки программного обеспечения для встраиваемых систем управления трактуется как сложный технологический
процесс, требующий регламентирующих документов для всех стадий жизненного цикла программного продукта.
С практической точки зрения программное обеспечение для систем встраиваемого класса для применений в аэрокосмической технике разрабатывается на базе операционных систем реального времени встраиваемого класса QNX, VxWorks, надежность которых
доказана многолетним опытом использования. Развитие возможностей современных микропроцессоров обеспечило возможность
использования специализированных клонов Unix для встраиваемых применений.
125
§5. Разработка полного цикла
К классу разработок полного цикла относятся специализированные системы управления, для которых ведется разработка, как
аппаратного, так и программного компонента. На рис. 3.3 показана
спиралеобразная модель жизненного цикла системы управления с
полным циклом разработки. Эта модель описывает характерные
стадии жизни систем управления этого класса. Модель описывает
ряд принципиально важных моментов для этого класса.
Во-первых, разработка системы управления подразумевает наличие набора компетенций у компании, отвечающей за разработку. Этот набор косвенно оценивается стоимостью know-how.
Во-вторых, это итерационный характер разработки. На рис. 3.3
изображена модель разработки с макетированием и двумя полно§Ï¾ÆùȹɹžËÉÇ»
ǼɹÆÁоÆÁÂÁ
¹ÄÕ˾ÉƹËÁ»
§Ï¾Æù˾ÎÆÇÄǼÁоÊÃÁÎÁ
ÍÁƹÆÊÇ»ÔÎÉÁÊÃÇ»
¡À¼ÇËǻľÆÁ¾
¹ÈȹɹËÆǼÇÁ
ÈÉǼɹÅÅÆǼÇ
ÃÇÅÈÇƾÆËÇ»
©¹ÀɹºÇËù
¹ÈȹɹËÆǼÇÁ
ÈÉǼɹÅÅÆǼÇ
ÃÇÅÈÇƾÆËÇ»
©¹ÀɹºÇËù
ÃÇÆϾÈÏÁÁÁ ÊȾÏÁÍÁùÏÁ ¥¹Ã¾ËÁÉÇ
»¹ÆÁ¾
©¹ÀɹºÇËùÁ
ÊǼĹÊÇ»¹ÆÁ¾« ƹÇÈÔËÆÔÂǺɹÀ¾Ï
¥¹Ã¾Ë
ªËÇÁÅÇÊËÕ
LOPXIPX
«¾ÊËÁÉÇ
»¹ÆÁ¾
§ÈÔËƹØ
ÖÃÊÈÄ̹˹ÏÁØ
§ÈÔËÆÔÂ
ǺɹÀ¾Ï
ª¾ÉÁÂÆÔÂ
ǺɹÀ¾Ï
ªÁÊ˾ÅƹØ
ÁÆ˾¼É¹ÏÁØ
™»ËÇÆÇÅÆǾ
˾ÊËÁÉÇ»¹ÆÁ¾
£ÇÅÈľÃÊÆǾ
˾ÊËÁÉÇ»¹ÆÁ¾
¨Ä¹ÆÁÉÇ»¹ÆÁ¾Êľ½Ì×Ò¾Â
Á˾ɹÏÁÁ
§Ï¾Æùɾ¹ÄÁÀ̾ÅÇÊËÁ
ËɾºÇ»¹ÆÁÂ
Рис. 3.3. Спиралеобразная модель разработки полного цикла
126
масштабными итерациями, что является характерным циклом в
современных условиях. Цикл макетирования, как правило, можно
провести на COTS-компонентах.
Понимание факта, что время выхода на рынок в современных
условиях является одним из ключевых факторов, привело к тому,
что компании-разработчики элементной базы поставляют также
наборы плат для макетирования. Эти платы носят разные названия: evolution boards, developments board и т. д. С этими платами
зачастую поставляется комплект конструкторско-технологической
документации в виде принципиальной схемы и схемы разводки
платы, библиотек драйверов (Board Support Paсage-BSP) и т. д.
В качестве примера можно указать аппаратную платформу ОMAP
фирмы Texas Instruments.
В-третьих, это наличие существенных рисков, связанных с использованием элементной базы экстерриториального происхождения и риска прекращения разработки на промежуточных этапах по
внешним причинам. Диаграмма отражает тот факт, что остановка
разработки на промежуточных этапах приводит к полномасштабным потерям для заказчика, а для разработчика она, как правило,
обеспечивает возможность наращивания компетенции. Перефразировав известное высказывание «наука – это средство удовлетворения любопытства за счет государства», получаем «разработка – это
средство развития компании за счет заказчика».
В современных условиях подавляющее число систем управления
встраиваемого класса разрабатывается с использованием микроконтроллеров. Микроконтроллерные реализации систем управления обеспечивают возможность существенного уменьшения габаритов и энергопотребления. При достаточно больших партиях это
утверждение применимо и к конечной суммарной стоимости системы управления.
При этом достаточно часто используются смешанные решения,
включающие в себя одноплатный компьютер, контроллеры периферийных устройств, реализуемые на базе микроконтроллеров и
программируемой логики.
Современные микроконтроллерные платформы состоят из семейств, ориентированных на использование в системах управления, ориентированных на относительно узкие применения. Изначальная ориентация на специализированные применения предполагает доступность и поддержку средств разработки программного
обеспечения для систем этого класса. Одновременно с развитием
возможностей микропроцессоров и усложнением прикладного
127
программного обеспечения бурно развивались соответствующие
программно-инструментальные средства поддержки разработок,
представляющие собой программный инструментарий. Профессиональные средств разработки, как правило, имеют в своем составе
аппаратную часть и, по сути, представляют собой специализированные программно-аппаратные комплексы.
Как правило, фирмы, работающие в области электронного инжиниринга, специализируются на относительно узких сегментах
рынка, что естественным путем приводит к возможности многократного использования одних и тех же программных модулей.
Эти модули, как правило, представляют собой внутрифирменные
know-how и оформляются в виде библиотек функций, обладающих
той или иной степенью общности.
Использование функций позволяет сократить не только размер
программы, но, при наличии хорошо организованных и разветвленных библиотек, обеспечивает сокращение времени на разработку и существенное повышение качества прикладного программного обеспечения. При этом специализированные подразделения
фирм-поставщиков микроконтроллеров обеспечивают разработку
типовых решений и их свободную раздачу. Такая система носит название системы поддержки разработок.
Современная микроконтроллерная платформа включает в себя
комплекс программно-инструментальных и аппаратно-программных средств, обеспечивающих разработку формирующих IDE.
В заключение следует подчеркнуть, что системы управления
для аэрокосмических применений, начиная с самых первых космических аппаратов, которые были относительно просты, имеют
сложную структуру. Эта структура характеризуется разнородностью как по функциям, так и по способу реализации. В силу этого,
ее разработка и поставка принципиально невозможны с использованием какой-либо одной IDE. Фактически при принятии решения
о выборе инструментальных средств речь идет о необходимости выбора нескольких таких сред, обеспечивающих разные уровни разработки системы.
3.2. Классификация способов разработки
программного обеспечения
Разработка программного обеспечения является составной частью цикла разработки системы управления. Этот элемент техно128
логической цепочки при создании систем управления в настоящее
время приобретает критическую важность по такому параметру,
как время выхода изделий на рынок (time to market).
§1. Иерархическая структура методов разработки
На рис. 3.4 приведена иерархическая структура применяемых
методов разработки программных кодов для систем управления
встраиваемого класса. Эта классификация была предложена достаточно давно [3]. В известном смысле она отражает базовые этапы
развития систем программного управления за 50 лет. За это время
существенное развитие получил маршрут разработок ветки DOWNUP, который является основой современных технологических циклов разработки программного обеспечения.
В отличие от аппаратного обеспечения, для которого характерно вытеснение устаревающей аппаратной базы, методы разработки
программных кодов, описанные в предлагаемой иерархии, образуют взаимосвязанную и взаимодополняющую систему.
¥¹ÉÑÉÌË
ɹÀɹºÇËÃÁ
6Q%08/
œ¾Æ¾É¹ËÇÉÔÈÉÁÄÇ¿¾ÆÁÂ
š¹ÀǻԾÖľžÆËÔƹÊËɹÁ»¹¾ÅǾÈÉÁÄÇ¿¾ÆÁ¾
§ÈÁʹÆÁ¾¹Ä¼ÇÉÁËŹÈɾ½ÈÇĹ¼¹¾Ë
ÁÊÈÇÄÕÀÇ»¹ÆÁ¾ÊȾÏÁ¹ÄÁÀÁÉÇ»¹ÆÆǼÇ
ÈÉǼɹÅÅÆǼÇÁÆÊËÉÌžÆ˹ÉÁØ
ǺÊÄÌ¿Á»¹×Ò¾¼ÇȹɹžËÉÁÀÇ»¹ÆÆǾÇÈÁʹÆÁ¾
¹Ä¼ÇÉÁËŹ»ÊÇÊ˹»¾¼ÇËǻǼÇÁÀ½¾ÄÁØ
¥¹ÉÑÉÌË
ɹÀɹºÇËÃÁ
%PXO6Q
¨ÉǼɹÅÅÁÉÇ»¹ÆÁ¾ÊÁÊÈÇÄÕÀÇ»¹ÆÁ¾Å§ª©›ÁN§ª©›
š¹ÀǻԾÖľžÆËÔÆÁËÕÈÉÇϾÊÊÈÇËÇÃ
§ÈÁʹÆÁ¾¹Ä¼ÇÉÁËŹÈɾ½ÈÇĹ¼¹¾ËÁÊÈÇÄÕÀÇ»¹ÆÁ¾
ÊȾÏÁ¹ÄÁÀÁÉÇ»¹ÆÆÇÂÊËÉÌÃËÌÉÔÈÉǼɹÅÅÆǼÇ
Ǻ¾ÊȾоÆÁØÊȾÏÁ¹ÄÁÀÁÉÇ»¹ÆÆÔκÁºÄÁÇ˾ÃÁ
ÊȾÏÁ¹ÄÁÀÁÉÇ»¹ÆÆÇÂ*%&
£ÇÅÈÇƾÆËÆǾÈÉÇϾ½ÌÉÆǾ
ÈÉǼɹÅÅÁÉÇ»¹ÆÁ¾
š¹ÀÇ»ÔÂÖľžÆËÔÃÇÅÈÇƾÆËÍÌÆÃÏÁØ
ÁºÁºÄÁÇ˾ÃÁÍÌÆÃÏÁÂ
™Ä¼ÇÉÁËÅÇÈÁÊÔ»¹¾ËÊØÊÁÊÈÇÄÕÀÇ»¹ÆÁ¾Å¹ÊʾźľɹØÀÔùª
+"7"
ÄØÊÇÀ½¹ÆÁØÈÉǼɹÅÅÆǼÇÃǽ¹ÁÊÈÇÄÕÀÌ×ËÊØÁÆÊËÉÌžÆ˹ÄÕÆÔ¾
ÈÉǼɹÅÅÔǺÊÄÌ¿Á»¹ÆÁغÁºÄÁÇ˾ÃÁʺÇÉÃÁÈÉǼɹÅÅÆǼÇÃǽ¹
¤ÁƾÂÆÔÂÃǽ
š¹ÀÇ»ÔÂÖľžÆËsÀ¹½¹Ð¹
™Ä¼ÇÉÁËÅÇÈÁÊÔ»¹¾ËÊØÊÁÊÈÇÄÕÀÇ»¹ÆÁ¾Å¹Êʾźľɹ
ŹÃÉǹÊʾźľɹÁÁÄÁØÀÔÃÇ»ª+"7"
Рис. 3.4. Иерархия методов разработки программных кодов
129
В настоящее время идет интенсивная наработка методов обеспечения разработок по маршруту UP-DOWN. Инструментальные
средства для разработки этого подхода время от времени анонсируются, но действительно универсальное решение промышленного
значения пока неизвестно.
Этот подход требует разработки методов высокоуровневого описания алгоритмов функционирования многоканальных и многокомпонентных систем управления реального времени. Ряд современных подходов к решению этой проблемы рассмотрен в литературе [1, 2, 4].
§2. Линейный подход
Линейный подход использует описание алгоритма с простой
структурой и на практике применим для систем управления с небольшим количеством каналов управления.
В сложных системах этот подход используется для написания
компонентов, требующих непосредственной работы с периферийными модулями в режимах, не поддерживаемых стандартными
библиотеками. Обычно такого рода компоненты используются в
виде ассемблерных вставок.
В первых вычислительных машинах этот способ был очень распространенным, и программирование велось непосредственно в кодах команд, что позволяло, в принципе, достигать очень эффективной
работы кода. В современных системах управления максимальный
уровень приближения к архитектуре микропроцессора или микроконтроллера обеспечивает реализация алгоритма на ассемблере. Ассемблер представляет собой набор мнемонических команд, позволяющий программировать микроконтроллеры конкретного семейства.
Для описания алгоритмов, реализуемых с помощью линейного
подхода, используются стандартные блок-схемы. Коды, реализуемые только на ассемблерах, плохо обозримы.
Для решения этой проблемы ряд современных IDE поддерживает
возможность использования текстовых подпрограмм, обрабатываемых препроцессором. Эти текстовые подпрограммы состоят из совокупности ассемблерных команд, оформленных соответствующим
образом и имеющим собственное уникальное имя. Их называют
макросами. Ассемблер с такими возможностями называется макроассемблером. Макросы могут иметь параметры, которые на этапе
предварительной обработки заменяются на фактические адреса. Эти
130
адреса могут описываться и в символьном виде. Предварительная обработка текста для IDE c макроассемблером осуществляется соответствующим программным инструментарием, называемым транслятором с макроассемблера. В таком варианте программный код представляет собой совокупность команд ассемблера и макроассемблера.
Другим способом увеличения обозримости кода является широкое использование как синтаксиса, так и собственно языка С для
написания модулей. Как правило, описание алгоритма, выполненное на С, транслируется компилятором в описание на языке ассемблера. При этом естественным образом обеспечивается возможность использования ассемблерных вставок.
Как правило, IDE, используемые для разработки встраиваемых
применений, обеспечивают возможность дезассемблирования, под
которым подразумевается возможность просмотра ассемблерной реализации описания алгоритма, выполненного на высокоуровневом
языке, например С. Эта возможность оказывается совсем не лишней на практике, так как компиляторы, как и весь остальной инструментарий, пишутся в спешке. В современных условиях совсем
не редкость, что программный инструментарий содержит ошибки
либо в документировании возможностей, либо в реализации.
§3. Компонентное программирование
Компонентное или процедурное программирование – это способ
разработки программных кодов с широким использованием предварительно разработанных компонентов. Этот подход ориентирован на применение специализированных библиотек, поставляемых
разработчиками электронных компонентов, внутрифирменных библиотек и библиотек компонентов текущего проекта.
Компоненты разрабатываются с помощью всего набора средств
используемой программной платформы: ассемблер, С, JAVA.
При программировании на ассемблере минимальный компонент
представляет собой подпрограмму. Подпрограмма – это набор команд микропроцессора, имеющая собственное имя и размещаемая
в памяти программ по адресу, задаваемому при сборке программного кода. Работа с подпрограммой осуществляется посредством двух
команд вызова – подпрограммы и возврата.
Синтаксис команд для разных платформ отличается, хотя общий принцип практически не различается. Например, на ассемблере MPASM фирмы Microchip структура подпрограммы имеет вид
131
PROC //Cимвольное имя_подпрограммы
[Тело подпрограммы: последовательность команд на ассемблере]
return //
Выполнение команды CALL PROC приводит к переходу на выполнение первой команды подпрограммы (адрес размещения подпрограммы). Перед этим средствами ядра микроконтроллера производится запись значения счетчика команд в стэк. После завершения выполнения тела подпрограммы выполняется команда return.
По этой команде из стэка извлекается значение счетчика команд,
соответствующее состоянию перед вызовом подпрограммы, инкрементируется на 1 и записывается в счетчик команд.
При использовании языков высокого уровня компонент представляет собой функцию, обеспечивающую реализацию соответствующего алгоритма.
В соответствии с определением компонент может быть достаточно сложным и включать вызов нескольких подпрограмм, т. е. речь
идет о вложенном вызове. Механизм реализации вызовов вложенных подпрограмм ничем не отличается от стандартного вызова подпрограммы. Понятно, что глубина вложенности зависит от размера
стека, определяемого архитектурой ядра. При использовании высокоуровневого языка программирования С используется такой его
базовый элемент, как функция.
Есть важное отличие компонента, реализованного в виде подпрограммы на ассемблере и в виде функции языка C.
Как правило, подпрограмма на ассемблере использует абсолютные адреса, пусть даже и описанные в виде символических имен.
При использовании функций ее текст обрабатывается компилятором, в результате работы которого формируется набор так называемых объектных кодов с символьным описанием адресов.
При сборке объектных кодов в программный код символьные описания адресов заменяются на абсолютные адреса. Эта операция выполняется специальным программным средством, называемым сборщиком (linker). При этом важно понимать, что на уровне программного
кода используется механизм вызова подпрограмм, описанный выше.
Компонентное программирование, рассматриваемое как технология, существенно повышает эффективность работы коллектива
программистов в смысле интегральной скорости разработки и качества создаваемого программного обеспечения. Интегральная скорость разработки повышается за счет распараллеливания процесса
разработки, а качество – за счет возможности использования уже
проверенных на практике компонентов.
132
Введение библиотек компонентов в виде исходных текстов и
объектных кодов в современных IDE обеспечивает библиотекарь
(librarian).
В сложных микропроцессорных системах с большим объемом
кода оперативная память программ ядра может не обеспечивать
возможность записи в нее всего требуемого объема программного
кода. В этом случае в памяти ядра хранится лишь его часть, а требуемые компоненты подгружаются в память программ из внешней
памяти по мере надобности для реализации соответствующей ветки реализуемого алгоритма. В самом общем случае возможно использование динамической актуализации адресов подгружаемых
кодов. Эти операции выполняются уже в процессе функционирования системы специальными служебными программами, которые
обобщенно называются загрузчиками. Иногда используется название dynamic linker – динамический сборщик или динамический
редактор связей. Этот служебный компонент программного кода
относится уже к уровню операционной системы.
§4. Разработка с использованием
технологии ОСРВ
С точки зрения разработчика система управления реального
времени является многоканальным устройством обработки информации, которая должна обеспечить возможность реализации
предписанных алгоритмов обработки информации в соответствии
со специфицированными для каждого из каналов управления временными параметрами во всех режимах эксплуатации. При этом
под обработкой информации понимается как обработка входных
сигналов, так и выработка управляющих воздействий.
В этом определении ключевым является свойство многоканальности в сочетании с фактическим определением свойств системы
управления в виде специфицированных требований на временные
параметры реализации предписанного алгоритма управления.
Понятие реального времени. В соответствии с пунктом 3.2.1
стандарта IEE 610.12:1990 понятие реальное время (real-time) относится к системе или режиму функционирования, для которого
вычисления выполняются за характерное время внешнего процесса, для того чтобы результат вычислений мог быть использован для
управления, мониторинга или ответа во временном темпе, определяемым внешним процессом.
133
С одной стороны, это определение достаточно древнее, а с другой – оно перекочевало в современную систему европейских стандартов для аэрокосмических применений.
В микропроцессорных системах управления обработка информации осуществляется ядром микропроцессора с использованием
специально разрабатываемых компонентов. Для обеспечения специфицированного темпа обработки информации требуется обеспечить компоненты каждого из каналов управления рядом ресурсов,
важнейшим из которых является количество команд CPU. Реализация этой функции подразумевает наличие единого системного
компонента, который называется диспетчером. Такой режим обработки информации является по сути псевдопараллельным. Для
описания структуры алгоритма такого рода систем удобно, а фактически, и необходимо использовать многоуровневое описание в
адресно-временной области.
С точки зрения технологии разработки программного обеспечения ОСРВ является структурной основой разрабатываемого программного кода. Эта структура определяется принятыми соглашениями и моделями базовых объектов. Она формируется комплексом
программно-инструментальных средств IDE с использованием библиотек системных компонентов для работы с базовыми объектами.
При применении этой технологии разработчику, по сути дела,
предлагается полуфабрикат программной части системы, который
дополняется прикладными компонентами для обеспечения требуемого набора функциональных свойств. Прикладные компоненты
также разрабатываются в этой среде в соответствии с правилами,
принятыми для данной ОСРВ, и включают в себя системные компоненты, которые и обеспечивают подключение их к базовой структуре кода. Все операции по интеграции кода осуществляются средствами IDE.
В силу этого, при использовании ОСРВ-технологии возможности
программиста ограничиваются из-за необходимости использования моделей, описаний и системных компонент конкретной ОСРВ.
Результирующий программный код будет состоять из системных
и пользовательских компонентов. Обеспечение учета специфики
конкретной разработки осуществляется путем написания соответствующих компонентов и интегрируемых в программный код с использованием средств ОСРВ.
Наличие такой структуры является коренным отличием программного кода, разработанного с применением этой технологии,
от технологии компонентного программирования. Предлагаемое
134
развернутое определение ОСРВ ориентировано на технологический
аспект разработки и отличается от стандартизованного определения системы управления реального времени. Следует подчеркнуть,
что оно не противоречит этому определению и, вместе с тем, позволяет учитывать возможные модификации определения этого базового понятия [5].
Эффективность использования технологии ОСРВ обеспечивается возможностью повторного использования системных компонентов, что начинает сказываться для систем управления выше
определенного уровня сложности. Соответственно, ОСРВ общего
назначения используют как можно более универсальные модели,
которые поддерживаются достаточно объемными библиотеками
системных компонентов.
Классические ОСРВ берут начало от систем управления, реализуемых на базе микропроцессоров и одноплатных компьютеров. При
использовании коммерчески поставляемых ОСРВ для этого типа
аппаратной составляющей требуется использование соответствующих IDE, ориентированных на конкретные типы микропроцессоров. Таким образом, в этом случае платой за скорость и качество
разрабатываемой системы управления являются ограничения по
возможности выбора способа реализации аппаратного компонента.
Диспетчер. Представляет собой системный компонент, обеспечивающий порядок обработки информации в многоканальных системах управления, путем запуска соответствующих компонентов
кода. Запуск компонента на выполнение подразумевает выделение
ему требуемых ресурсов.
ОСРВ включает в себя диспетчер очереди фоновых потоков и
диспетчер обработки прерываний. В полномасштабных ОСРВ диспетчеризация осуществляется с учетом приоритетов задач.
Ключевая функция этого системного компонента заключается
в бесконфликтном распределении ресурсов аппаратных компонентов системы управления между компонентами, обеспечивающими
обработку информации для разных каналов. Для этого диспетчер
обрабатывает таблицы описаний очереди компонентов (задач),
определяет их текущее состояние и наличие условий для их реализации и обеспечивает передачу управления соответствующему компоненту. Структура таблиц описаний определяется соглашениями
для конкретной ОСРВ. Их содержание определяется средствами
IDE на этапе генерации программного кода.
Одной из важнейших функций диспетчера является обеспечение
ресурсами компонентов, обрабатывающих сигналы прерываний.
135
При этом требуется обеспечить корректную приостановку процесса реализации текущей задачи, с тем чтобы после обработки сигнала прерывания его можно было возобновить без возникновения
ошибок. При этом не следует забывать о необходимости выполнять
временные ограничения по времени выполнения прерванного компонента. Эту часть диспетчера иногда называют диспетчером прерываний.
Следует отметить, что использование сетевых (распределенных)
систем управлений требует согласованной работы системы микропроцессоров. В этом случае речь идет об истинной параллельности
обработки информации узлами, реализующими псевдопараллельную обработку. Организация сетевого взаимодействия в полномасштабных ОСРВ осуществляется системными компонентами.
Дисциплины диспетчеризации RR и FIFO. Наиболее распространенные на практике дисциплины диспетчеризации FIFO (First
Input First Output) и RR (Round Robin) – диспетчеризация с квантованием времени. Рассмотрим общие принципы реализации этих
дисциплин диспетчеризации.
Диспетчеризация FIFO подразумевает последовательный вызов
компонентов, обеспечивающих обработку информации по каналам
управления. Обработка данных канала начинается по завершении
обработки информации для предыдущего канала. Обработка информации для каналов повторяется циклически. На рис. 3.5 показан иллюстрирующий пример процессограммы для трех потоков,
реализуемых в фоновой очереди с одинаковым приоритетом.
¯ÁÃÄ
ÇÈÉÇʹ
5DÇоɾ½Á
À¹½¹Ð5D
ªÁÊ˾ÅÆÔ»ÔÀÇ»
½ÁÊȾËоɹ
5TZT5JTS5EJTQ
¨ÇËÇÃ
ÅÁÃÉÇؽɹ
ÂÈÇËÇÃ
ÂÈÇËÇÃ
ÂÈÇËÇÃ
›É¾Å¾ÆÆÇÂÊÄÇË5J
¯ÁÃÄ,¯ÁÃÄ,¯ÁÃÄ,›É¾ÅØ
Рис. 3.5. Пример процессограммы для FIFO диспетчера
136
Переключение между компонентами разных потоков осуществляется вызовом диспетчера, который определяет номер следующего вызываемого компонента. При диспетчеризации FIFO возврат
управления на уровень микроядра осуществляет сам компонент после завершения своих функций по обработке информации. Соответственно, временные слоты Ti для каждого из компонентов разные.
Цикл опроса очереди равен суммарной длительности всех слотов с
добавленным временем на реализацию системного вызова.
Диспетчеризация с квантованием времени подразумевает выделение каждой из задач определенного кванта времени, во время
которого обрабатывается информация i-канала из списка. Обработка информации по каналам при этом реализована циклически. По
истечении кванта времени, ресурсы микропроцессора передаются
следующей задаче из списка, обеспечивающей обработку канала
с номером i+1. Диспетчер RR при этом обеспечивает сохранение
всей необходимой информации, требующейся для корректного возобновления обработки информации для i-го канала, когда до него
вновь дойдет очередь.
При диспетчеризации RR системный вызов диспетчера осуществляется с уровня системы прерываний от системного таймера.
В простейшем варианте реализации диспетчера RR всем задачам выделяется одинаковый квант времени. Диспетчер RR при
каждом прерывании от системного таймера определяет – не истек
ли очередной квант времени? В зависимости от результата сравнения продолжается выполнение компонента текущего процесса
либо осуществляются операции по запуску компонента следующего потока.
Ряд критериев, влияющих на выбор операционной системы, рассмотрен в литературе [6]. Ряд особенностей построения и применения сетевых операционных систем рассмотрен в учебнике [7]. Этот
же учебник содержит описание структурных особенностей ОСРВ.
§5. Микрооперационные системы
реального времени
Развитие элементной базы создало предпосылки для применения технологии разработки ОСРВ для систем, реализуемых на
базе микроконтроллеров. При этом существенное развитие получили системы распределенного управления. При таком подходе
система управления реализуется как микроконтроллерная сеть с
137
использованием интеллектуальных сенсоров и исполнительных
устройств.
Эффективность применения микроконтроллеров в системах распределенного управления с точки зрения реализации аппаратной
составляющей обеспечивается широкой номенклатурой микроконтроллеров с разнообразным составом периферийных модулей.
Оптимизация системы достигается путем устранения избыточности по функциям за счет выбора микроконтроллеров со структурой
периферии, которая соответствует функциям конкретного узла.
Совместимость компонентов аппаратной составляющей средствам
разработки и поддержки обеспечивается за счет преимуществ использования платформенного подхода.
Термин «микрооперационная система реального времени», обозначаемый как mОСРВ, сравнительно новый [1]. В монографии
рассмотрены особенности применения технологии разработки программного обеспечения с использованием ОСРВ для автономных
многоканальных систем управления реального времени. Для этого
круга применений характерно наличие существенных ограничений
на память программ и данных. В названии этого класса отражается
тот факт, что из-за ограниченности ресурсов микроконтроллера невозможно использовать полномасштабную операционную систему,
так как сама операционная система требует ресурсов для реализации своих базовых функций.
В силу этого приходится решать задачу многокритериальной
оптимизации по разделению ресурсов между микрооперационной
системой и прикладными задачами применительно к конкретной
реализации. Существенным обстоятельством, обеспечивающим
применение этой технологии, является то, что у систем управления этого класса набор задач, реализуемых на этапе функционирования, и набор компонентов, осуществляющих обработку информации для каналов управления, однозначно определяется на этапе
разработки.
В силу аппаратных ограничений для микроконтроллерных реализаций использование технологии mОСРВ подразумевает генерацию оптимизированной под конкретное применение структуры
программного кода, включающего лишь необходимые для реализации конкретного программного кода системные компоненты.
Микрооперационные системы реального времени предопределяют внутреннюю структуру программного обеспечения, но имеют
жесткие ограничения по ресурсам микроконтроллера на реализацию системных функций.
138
Для автономных систем управления эта структура определяется
соглашениями об использовании системы прерываний, диспетчеризации обработчиков прерываний и очереди прикладных задач,
обеспечения надежности системы за счет аппаратно-программного
мониторинга хода реализации программного кода. Применительно
к распределенным системам управления в этот набор включаются
аппаратные модули поддержки сетевых коммуникаций, набор соглашений и протоколов сетевого обмена, поддерживаемых сетевыми функциями.
Целью применения данной технологии, особенно применительно к системам распределенного управления, является увеличение
скорости разработки и качества программного кода. Это достигается за счет возможности распараллеливания разработки и широкого
использования библиотек готовых компонентов.
Прикладное программное обеспечение для конкретного узла и
применения может разрабатываться с использованием разных технологий. Однако в системах распределенного управления целесообразно использовать единые модели описания базовых объектов и,
желательно, общих библиотек компонентов.
При этом использование тех или иных функций в современных
условиях становится зависимым от выбора, привычек и опыта разработчика. Это означает, что на основе некой универсальной модели операционной системы разрабатывается конкретная реализация с помощью определенных стандартных средств. В этом смысле
микрооперационные системы являются частью соответствующей
программно-инструментальной среды и, в известном смысле, ограничивают свободу творчества, взамен обеспечивая резкое увеличение скорости разработки и качества программных кодов.
При этом следует подчеркнуть, что современные системы управления представляют собой сложный конгломерат аппаратнопрограммных решений, состоящий из разнородных узлов, реализуемых на разнородной элементной базе, что создает существенные
сложности при создании программно-инструментальных сред поддержки разработки. Принципы построения IDE для микроконтроллерных реализаций, обеспечивающих возможность использования mОСРВ-технологии разработки программного обеспечения,
отличаются от принципов построения IDE для систем управления,
реализуемых на одноплатных компьютерах.
Для современных ОСРВ характерным является использование
универсальных моделей с возможностью управления структурой
системной части кода и набора используемых системных функций.
139
Эти свойства обеспечиваются за счет использования микроядерных
архитектур. Это направление развития ОСРВ, по сути дела, является конвергенцией технологий ОСРВ и mОСРВ. В качестве практически значимой реализации можно указать ОСРВ Neutrino, являющейся частью программно-инструментальной платформы QNX6.
Для mОСРВ характерным является использование максимально простых моделей системных объектов в целях минимизация
ресурсов на их реализацию. В настоящее время эта технология интенсивно развивается применительно к распределенным системам
управления.
Локомотивом развития данного направления является автомобилестроительная отрасль. Индикатором этой ситуации явилось
появление семейства стандартов OSEK. Высказывание «автомобиль это больше, чем одна микроконтроллерная сеть» отражает
реальную ситуацию в этой области. В рамках разработки стандарта были предложены и разработаны сетевые mОСРВ OSEK OS и
OSEKtime, служащие основой программно-инструментальных среды поддержки этого стандарта.
Влияние важности технологии mОСРВ нашло отражение в архитектурах ряда современных микроконтроллеров. Речь, в частности, идет о широком использовании аппаратной реализации
нижних уровней сетевых протоколов в виде периферийных модулей микроконтроллеров. В качестве еще одного примера можно
указать модули аппаратного сохранения контекста при фиксации
прерывания, которые появились в архитектуре некоторых микроконтроллерных платформ. Это несложное усовершенствование в
сочетании с векторной системой прерываний обеспечивает существенное уменьшение времени реакции на внешнее воздействие.
§6. Платформа Eclipse
Современные системы управления, используемые в аэрокосмической области, как правило, являются многокомпонентными. Это
объясняется рядом факторов, но важнейшим из них является необходимость оптимизации массогабаритных параметров системы,
что особенно важно для систем управления встраиваемого класса,
когда счет идет на граммы.
Такие системы разрабатываются коллективами разработчиков,
что приводит к необходимости организации соответствующих технологических циклов, обеспечивающих управление разработкой.
140
Разнородность используемой элементной базы требует использования программно-инструментальных сред разных производителей.
При этом возникает необходимость интеграции проекта в единое
целое, синхронизации версий разрабатываемого программного обеспечении, организации процесса документирования и т. д.
Возможность объединения программно-инструментальных сред
разных производителей объясняется тем, что базовый цикл, лежащий в основе разработки прикладного программного обеспечения,
один и тот же. Он включает в себя описание алгоритма на соответствующем языке программирования с помощью текстового редактора, его компиляцию, сборку и контролируемое выполнение, в
процессе которого разработчик должен иметь возможность получать значения регистров (переменных).
Eclipse представляет собой универсальную расширяемую платформу, обеспечивающую возможность создания и поддержки специализированных сред поддержки разработки путем объединении
компонентов IDE. Архитектура и способ реализации Eclipse обеспечивают его переносимость и расширяемость.
В качестве примера применения Eclipse для создания среды
разработки приложений реального времени можно указать QNX
Momentics Tool Suite. Эта среда может эксплуатироваться на персональных компьютерах с операционными системами Windows и
Linux и обеспечивать возможность разработки приложений на стандартном ANSI C, С++ и embedded С++. Возможно также получение
информации о состоянии системы и параметрах запускаемого приложения, возможность анализа состояния памяти и получения параметров аппаратного компонента разрабатываемой системы.
Универсальность платформы Eclipse обеспечивается ее реализацией на платформо-независимом языке JAVA. Синтаксис языка
JAVA во многом схож с языком C и легко осваивается даже начинающими программистами. Непрерывное наращивание возможностей современных микропроцессоров и микроконтроллеров в принципе позволяет использовать язык JAVA для разработки прикладного программного обеспечения для систем управления встраиваемого класса. При этом считается, что этот язык проще чем СС++ и
обеспечивает получение программных кодов лучшего качества, но
требует больших ресурсов как по памяти, так и по производительности.
Язык JAVA. Механизм обеспечения универсальности обеспечивается трансляцией описания в программный код, выполнение
которого предполагается на виртуальной машине (Java Virtual
141
Machine – JVM). Программный код для виртуальной машины
JVM представляет собой набор команд, называемых байткодами
(bytecode). Виртуальная машина представляет собой модель вычислительной системы, реализуемой средствами используемой
программно-аппаратной платформы, которая обеспечивает выполнение байткодов. Исполнение программного JAVA-кода представляет собой интерпретацию байткодов, что и обеспечивает переносимость приложений на различные программно-аппаратные платформы. Общая схема обработки программы, написанной на JAVA,
показана на рис. 3.6.
Структура простейшего JAVA-компонента иллюстрируется следующим классическим примером:
class Hello {
// Объявление класса, сохраняется с
// расширением *. java
public static void main(String args[]) // Объявление метода
{
// Тело метода
double pi=3.14159;
// Объявление и инициализация переменной
System.out.println(«Lesson_1»);
// Печать строки с переходом на новую строку
System.out.println(«Hello, world!»); // Классическое приветствие
System.out.println(pi);
// Вывод значения числа
}
}
Готовые к выполнению программные компоненты Java распространяются в виде набора файлов описания классов (*.class).
Реализации JVM на разных аппаратно-программных платформах, естественно, будут отличаться по скорости реализации байткодов. Соответственно, для обеспечения переносимости приложений реального времени, разрабатываемых на JAVA, требуется, как
минимум, запас по производительности. Однако, когда речь идет о
программно-инструментальных средствах, этот фактор, как правило, не является определяющим.
Кроме этого, при создании инструментальной среды имеется возможность использовать различные варианты ее реализации JVM,
оптимизированные под ресурсы конкретной программно-аппаратной платформы, для которых разрабатывается приложение.
Как следует из рис. 3.6, в настоящее время платформа JAVA
включает в себя три базовых варианта реализации, которые в свою
очередь могут дополняться соответствующими модулями расширения.
142
¡ÊÎǽÆÔÂ
˾ÃÊË
KBWB
+BWBÃÇÅÈÁÄØËÇÉ
KBWBD
+BWBÈĹËÍÇÉŹ
¨¹Ã¾ËÔ
ɹÊÑÁɾÆÁØ
¨¹Ã¾ËÔ
ɹÊÑÁɾÆÁØ
+&&
&OUFSQSJTF
&EJUJPO
+4&
4UBOEBSU
&EJUJPO
š¹ÂËÃǽ
ÊMBTT
›ÁÉË̹ÄÕƹØ
¥¹ÑÁƹ
+7.
+.&
.JDSP
&EJUJPO
§È¾É¹ÏÁÇÆƹØÊÁÊ˾Ź
8JOEPXTYYY-JOVY4PMBSJT
™ÈȹɹËÆÔÂÃÇÅÈÇƾÆË
Рис. 3.6. Структура JAVA платформы
Варианты реализации моделей виртуальной машины приведены в табл. 3.1.
Таблица 3.1
Реализация
Модели виртуальной машины
Обозначение машины
Базовое назначение
J2EE и JDSE JVM
CVM
J2ME
KVM
Java Card
JCVM
Стандартная модель
Модель для аппаратных реализаций с
минимизированными ресурсами
Модель для смарт-карт
Архитектура виртуальной машины. Обобщенная структура
виртуальной JAVA-машины приведена на рис. 3.7.
Реализация виртуальной машины строится вокруг виртуального вычислительного ядра, управление которым реализуется посредством команд JAVA-ассемблера. Следует отметить, что на ассемблер для виртуальной JAVA-машины не существует стандарта.
При реализации JAVA-программы загрузчик осуществляет
прием ее бинарной презентации, (*.class). Редактор связей (linker)
обеспечивает верификацию (verification), подготовку (preparation),
конкретизацию (resolution) и инициализацию (initialization).
Верификация представляет собой оценку структурной целостности принимаемой бинарной презентации. В фазе подготовки выделяется необходимая память или интерфейсы, которая инициализируется значениями по умолчанию. Для обозначения этой памяти
используется термин static fields. Под конкретизацией понимается
143
¡Æ˾ÉÈɾ˹ËÇÉ+"7"
+BWB3VOUJNF4ZTUFN
+"7"º¹ÂËÃǽ
DMBTT
¹¼ÉÌÀÐÁÃÁ
»¾ÉÁÍÁùËÇÉ
ÃĹÊʹ
§ºÄ¹ÊËÕ
ÃĹÊʹÁ
žËǽ¹
šÁºÄÁÇ˾ù
ÃĹÊÊÇ» §ºÒ¹Ø
ȹÅØËÕ
)&"1
¦ÁËÁ
ÁÊÃÄ×оÆÁØ
º¾ÀÇȹÊÆÇÊËÕ
+BWBÊËÖÃÁ
ɾ¼ÁÊËÉÔ
š¹ÀÇ»ÔÂ
žËǽ ÃĹÊÊÇ»
©¾½¹ÃËÇÉ Ê»ØÀ¾Â º¹ÀǻǼÇ
žËǽ¹
§ºÄ¹ÊËÕ
º¹ÀǻǼÇ
žËǽ¹
¥Ç½ÌÄÕÁÊÈÇÄƾÆÁØ
FYFDVUJWFFOHJOF
§È¾É¹ÏÁÇÆƹØÊÁÊ˾Ź
Рис. 3.7. Виртуальная JAVA машина
определение фактических значений констант по их символическим описаниям в принятом бинарном файле. В фазе инициализации происходит присвоение значений константам и переменным
исполняемого класса.
Модуль исполнения виртуальной машины имеет регистры, в которых хранятся программные счетчики, свой для каждой JAVAнити. Эти счетчики содержат адрес исполняемой команды для виртуальной машины конкретной нити.
Каждая нить имеет свой собственный JVM-стэк, который создается в момент ее создания. В стэке хранятся локальные переменные
и промежуточные результаты. Эти значения используются при запуске и остановке исполняемых методов. Стэк также используется для
динамического редактирования связей подгружаемых модулей.
Структура платформы Eclipse. Современная система управления является многокомпонентной и требует для разработки программного обеспечения использования программно-инструментальных сред разных производителей. Eclipse является способом и
средством интеграции средств поддержки разработки такого класса систем за счет того, что архитектура и способ реализации Eclipse
обеспечивают его переносимость и расширяемость.
Переносимость обеспечивается его реализацией на языке JAVA,
а расширяемость – за счет возможности подключения внешних мо144
дулей, в том числе и разрабатываемых под нужды конкретного проекта. Подключаемый модуль имеет англоязычное название plug-in.
Ядро платформы было разработано компанией IBM, что обеспечило высокое качество разработки. Совокупность этих качеств в
сочетании со свободным распространением ядра привели к тому,
что Eclipse является одним из самых распространенных корпоративных стандартов для разработки приложений. Представление
об общей структуре специализированной среды разработки на базе
Eclipse дает рис. 3.8.
Платформа Eclipse включает в себя несколько вариантов реализации ядра. Функциональность среды разработки обеспечивается
подключаемыми программно-инструментальными средами. При
запуске ядро производит диагностику наличии подключаемых
программно-инструментальных сред и обеспечивает их совместную работу через специфицированные интерфейсы.
Разработка специализированных программно-инструментальных сред с применением этой платформы в свою очередь обеспечивается специализированным пакетом Eclipse SDK (Software
Development Kit – SDK).
Состав пакета:
Eclipse Platform – базовая платформа Eclipse, функционирующая в среде Java Runtime Environment;
Eclipse Java Development Tools (JDT) – библиотека специализированных модулей, для использовании которых требуется JAVA SDK;
Eclipse Plug-in Development Environment – программный инструментарий для разработки модулей расширения Eclipse (plug-in).
Основными языками разработки программного обеспечения
для встраиваемых систем управления является С ( нижний уровень
системы) и С++ (верхний уровень). Платформа Eclipse включает в
¨Ç½ÃÄ×й¾ÅÔ¾ÈÉǼɹÅÅÆÇ
ÁÆÊËÉÌžÆ˹ÄÕÆÔ¾Êɾ½Ô
ªÉ¾½ÊË»¹É¹ÀɹºÇËÃÁ+"7"
ÈÉÁÄÇ¿¾ÆÁÂ
¨Ä¹ËÍÇÉŹ&DMJQTF
›ÁÉË̹ÄÕƹØ+"7"ŹÑÁƹ
1%&
1MVHJO%FWFMPQNFOUT&OWJSPONFOUT
+%5
+"7"%FWFMPQNFOUT500-4
&1
&DMJQTF1MBUGPSN
+7.
+"7"7JSUVBM.BDIJOF
Рис. 3.8. Укрупненная структура корпоративной среды разработки
145
себя компонент Eclipse CDT, обеспечивающий возможность разработки приложений на языках С и С++. Этот инструментарий в настоящее время играет доминирующую роль на рынке программноинструментальных сред поддержки разработки.
§7. Генераторы приложений
Генераторы приложений – это специализированный программный инструментарий, обеспечивающий возможность автоматической генерации программного кода по заданным параметрам
разрабатываемой системы управления. Применительно к системам управления реального времени встраиваемого класса можно
утверждать, что в основе таких систем будет лежать параметризованное описание ОСРВ и функциональных компонентов системы.
Процесс разработки с помощью такой технологии будет представлять настройку системы управления путем задания параметров
с помощью специализированного программного инструментария.
К этому классу следует относить системы управления на базе нечеткой логики и системы управления на базе нейронных сетей или
их комбинации.
Алгоритм управления, описанный с использованием нечетких
переменных, представляет собой параметризованный программный код. Эти параметры должны быть тем или иным способом подобраны в процессе настройки системы на реальные условия эксплуатации. Нейронные системы управления подразумевают использование большого количества единообразных элементов, называемых искусственными нейронами, каждый из которых обладает
набором свободных параметров в виде весов и нижнего и верхнего
порогов. Структура сети при этом может быть как заданной, так и
настраиваемой. Для систем этого класса требуемая функциональность определяется путем описания требуемых реакций системы
на набор обучающих воздействий. Фактическое значение параметров будет определяться с применением собственных средств системы управления, переведенной в режим обучения.
Такого рода технологии в настоящее время интенсивно разрабатывается, но до уровня стандартизованных решений они еще не
доведены. Текущее положение дел в этой области достаточно полно
освещено в литературе [1, 8, 9].
В качестве подтверждения можно привести изложение сообщения с ленты новостей сайта rbc.ru от 16 августа 2011 года.
146
«В китайском национальном университете оборонных технологий сделаны впечатляющие разработки. Речь идет о беспилотном
автомобиле на базе серийной модели FAW Hohgqui HQ3, который
проделал путь 286 км со средней скоростью 90 км/ч по загруженной автомагистрали. Автомобиль проехал от одного административного центра до другого без использования GPS, используя только видеокамеры, радарные датчики и систему управления на базе
искусственного интеллекта. Во время испытаний была установлена максимальная скорость, которую машине было запрещено
превышать. В остальном система управления принимала решения
самостоятельно, т. е. анализировала дорожные знаки и дорожные
развязки, управляла скоростным режимом, контролировала положение других участников дорожного движения и т. п.»
Эта информация, помимо всего прочего, означает, что на рынке
систем управления появился новый серьезный игрок.
3.3. Операционные системы реального времени
Аэрокосмическая отрасль предъявляет жесткие требования к
вычислительным средствам, влияющим на степень безопасности
целевой системы. Практическая важность ОСРВ-технологии разработки программных кодов для встраиваемых систем управления
была понята достаточно давно. Работа над стандартами в этой области велась и ведется параллельно с наработкой практического
опыта использования этой технологии.
Данный раздел содержит краткое описание системы стандартов,
относящихся в той мере иной степени к разработке программного
обеспечения для авиационных и космических применений. Следует особо подчеркнуть, что, несмотря на работу по стандартизации в
этой области, до сих пор существует терминологическая путаница.
Поэтому приведенные ниже описания наиболее популярных ОСРВ
используют «родные» определения, взятые из фирменной документации. Соответственно, зона действия базовых понятий локальная
и распространяется лишь на соответствующий раздел.
§1. Стандарты POSIX
Операционная среда, предоставляемая операционной системой –
ее архитектура, базовые понятия и доступные для прикладных про147
грамм сервисы и услуги, описывается спецификацией программного интерфейса операционной системы для выполняемых в ее среде
прикладных программ – (API – Application Program Interface).
Одной из основных спецификаций существующих современных
ОС, как и отправной точкой для разработки спецификации новых
операционных систем, является спецификация POSIX [10].
Хотя стандарт POSIX был разработан на основе ОС UNIX, он не
является стандартом только на операционные системы семейства
UNIX. Наследуя многие оправдавшие себя решения этой операционной системы (основные атрибуты процессов, параллельное исполнение процессов, иерархическая организация файловой системы и др.), POSIX в то же время является обобщением UNIX, что достигается заменой конкретных реализаций их обобщенными, более
абстрактными понятиями, свойствами, возможностями.
POSIX специфицирует на уровне исходных текстов интерфейс
прикладных программ с обобщенной операционной средой, которой в реализации может соответствовать как некоторая версия реализация UNIX, так и любая другая операционная система, либо
прямо своими системными вызовами, либо через посредство системных библиотек, реализующая для прикладных программ операционную среду, соответствующую стандартам POSIX.
Существенным фактором открытости системы стандартов
POSIX является то, что, абстрагируясь от конкретной версии или
реализации ОС, специфицируя API в обобщенных терминах виртуальной операционной среды, POSIX не делает различия между
системными вызовами ядра ОС и обращениями к функциям системных библиотек или библиотек компонентов промежуточного
уровня (middleware).
POSIX специфицирует виртуальную машину, которая представляет собой модель операционной среды для прикладных программ
безотносительно к методам ее реализации. Это позволяет относительно просто строить POSIX-согласованную среду почти для любой операционной системы. Такой подход обеспечивает универсальность за счет широкого набора средств реализации. Возможно
использование как прямой реализации ядра ОС (например, Linux,
Solaris и др.), так и создание системных библиотек разного уровня
и организации (например, системные библиотеки в IBM OS/390,
использования подпрограмм обеспечения частичной совместимости со стандартами POSIX в не UNIX-подобной ОС VxWorks и др.).
Стандарту POSIX соответствует целый набор действующих стандартов на ОСРВ.
148
В целом POSIX представляет обширный набор стандартов, которые надо иметь в виду при разработке системного программного обеспечения перспективных вычислительных машин, систем и
комплексов, их операционных систем, систем программирования,
библиотек программ и прикладных программных систем.
К настоящему времени стандарт POSIX представляет собой семейство родственных стандартов: IEEE Std 1003.n (где n – это номер). Поскольку структура POSIX является совокупностью необязательных возможностей, поставщики ОС могут реализовать только часть стандартного интерфейса и при этом говорить о POSIXсовместимости своей системы.
Для ОСРВ наиболее важны семь спецификаций POSIX (1003.1a,
1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую
поддержку в коммерческих ОС получили только три первых.
Стандарт 1003.1a (OS Definition) содержит базовые интерфейсы ОС – поддержку единственного процесса; поддержку многих
процессов; управление заданиями, сигналами, группами пользователей, файловой системой, файловыми атрибутами; управление
файловыми устройствами, блокировками файлов, устройствами
ввода/вывода, устройствами специального назначения, системными базами данных, каналами, очередями FIFO, а также поддержку
языка C.
Стандарт 1003.1b (Realtime Extensions) содержит расширения
реального времени – сигналы реального времени, планирование
выполнения (с учетом приоритетов, циклическое планирование),
таймеры, синхронный и асинхронный ввод/вывод, ввод/вывод с
приоритетами, синхронизация файлов, блокировка памяти, разделяемая память, передача сообщений, семафоры.
Чтобы стать POSIX-совместимой, ОС должна реализовать не менее 32 уровней приоритетов. POSIX определяет три политики планирования обработки процессов:
SCHED_FIFO – процессы обрабатываются в режиме FIFO и выполняются до завершения;
SCHED_RR – round robin – каждому процессу по очереди выделяется квант времени;
SCHED_OTHER – произвольная дисциплина диспетчеризации,
не переносимая на другие платформы.
Стандарт 1003.1c (Threads) касается функций поддержки многопоточной обработки внутри процесса – управление потоками,
планирование с учетом приоритетов, мьютексы (специальные
синхронизирующие объекты в межпроцессном взаимодействии,
149
подающие сигнал, когда они не захвачены каким-либо потоком),
приоритетное наследование в мьютексах, переменные состояния
(condition variables).
§2. Потоки (threads) POSIX
При всем разнообразии моделей, предложенных за 50 лет развития операционных систем, понятие потока или нити, используемое в POSIX, является фундаментальным для этой области техники. Следует подчеркнуть еще раз, что речь идет о многоканальных
системах, для которых требуется обеспечить бесконфликтное разделение ресурсов между компонентами кода и информационный
обмен между ними.
Поток представляет собой системный компонент, требующий
меньше аппаратных ресурсов для своей реализации, чем процесс,
являющейся также базовой сущностью стандарта POSIX. Введение
потока в виде «облегченного процесса » (light-weight process) обеспечивает:
экономию времени, так как создание потока может занимать
меньше 10% времени создания «полноценного» процесса;
упрощение организации обмена информацией между параллельно реализуемыми потоками, так как потоки одного процесса
разделяют адресное пространство процесса.
Минимальный набор атрибутов и ресурсов для реализации потока приведен в табл. 3.2.
Таблица 3.2
Минимальный набор атрибутов нити POSIX
Потоки одного процесса разделяют
Каждый поток имеет свой собственный
(совместно используют)
Коды команд процесса
Набор регистров, включая РС и указатель стека
Данные
Стек (хранит локальные, динамические
переменные и адреса возвратов из подпрограмм)
Открытые файлы (дескрипторы) Идентификатор потока
Текущий рабочий каталог
Маска сигналов
Обработчики сигналов, настрой- Приоритет
ки для обработки сигналов
Идентификатор пользователя и Errno
группы
150
Инициализация потока подразумевает выделение ему ресурсов.
В POSIX предлагается следующий механизм. При запуске программы (процесса) вызовом exec создается начальный поток (initial
thread). Добавочные потоки создаются вызовом системной функции pthread_create (), посредством которого задается компонент,
который вызывается при запуске потока. Эта функция возвращает
идентификатор порожденного потока pthread_t.
После завершения исполняемых компонентов потока, для освобождения ресурсов выполняются системные вызовы, обеспечивающие корректное завершение потока.
Потоки завершаются двумя разными способами:
явное завершение потока обеспечивается функцией pthread_exit;
неявное завершение потока представляет собой возврат из начальной функции потока и обеспечивается функциями:
pthread_self – возвращает идентификатор потока,
pthread_join – ожидание завершения потока (одного!),
pthread_detach – «отсоединение» потока.
§3. Стандарты DO-178B и ARINC-653
Стандарт DO-178B создан Радиотехнической комиссией по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для
разработки ПО бортовых авиационных систем [DO178B]. Первая
его версия была принята в 1982 году, вторая (DO-178A) – в 1985-м,
текущая DO-178B – в 1992 году. Готовится принятие новой версии – DO-178C. Стандартом предусмотрено пять уровней серьезности отказа, и для каждого из них определен набор требований к
программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов
данного уровня серьезности.
Данный стандарт определяет следующие уровни сертификации:
А (катастрофический);
В (опасный);
С (существенный);
D (несущественный);
Е (не влияющий).
Для авиационных систем управления выполнение требований
этого стандарта в США являются обязательными.
В Европе применяется стандарт ED-12B, который является аналогом DO-178B.
151
Стандарт ARINC-653 (Avionics Application Software Standard
Interface) разработан компанией ARINC в 1997 году. Этот стандарт определяет универсальный программный интерфейс APEX
(Application/Executive) между ОС авиационного компьютера и прикладным программным обеспечением (ПО).
Требования к интерфейсу между прикладным ПО и сервисами
операционной системы определяются таким образом, чтобы разрешить ПО контролировать диспетчеризацию, информационный
обмен и состояние исполняемых компонентов.
В 2003 году принята новая редакция этого стандарта – ARINC653. Эта версия в качестве одного из основных требований для ОСРВ
в авиации вводит архитектуру изолированных (partitioning) виртуальных машин. Каждое приложение (возможно, состоящее из нескольких процессов) должно выполняться обособленно относительно других приложений и помещается в свой собственный раздел.
При этом операционная система должна обеспечить:
невозможность доступа для приложения из одного раздела в
память другого раздела (пространственное разделение – spatial
partitioning);
наличие у каждого раздела гарантированного бюджета времени,
который будет ему предоставлен, даже если один или несколько
других разделов имеют приложения с более высоким приоритетом
(временное разделение – temporal partitioning).
Применение разделов, помимо повышения надежности систем
автоматического управления, дает следующие преимущества:
независимость разработки. Поскольку разделы работают независимо друг от друга, они могут проектироваться, разрабатываться
независимо (но с учетом ограничения бюджета времени и памяти).
Большую часть верификации приложений (за исключением совместной доводки изделия) также можно провести независимо;
гибкость в развертывании системы. Если в системе есть несколько вычислительных модулей, то раздел может быть при необходимости перенесен с одного вычислителя на другой без изменения
кода приложений (при условии, что оба вычислителя работают под
управлением одной операционной системы).
§4. Стандарт OSEK/VDX
В настоящее время становится популярным стандарт OSEK/
VDX. Стандарт OSEK/VDX является комбинацией стандартов,
152
которые изначально разрабатывались в двух отдельных автомобилестроительных консорциумах, впоследствии слившихся. OSEK
берет свое название от немецкого акронима консорциума, в состав
которого входили ведущие немецкие производители автомобилей –
BMW, Bosch, Daimler Benz (теперь Daimler Chrysler), Opel, Siemens
и Volkswagen, а также университет в Карлсруэ (Германия). Проект
VDX (Vehicle Distributed eXecutive) развивался совместными усилиями французских компаний PSA и Renault. Команды OSEK и
VDX слились в 1994 году.
Стандарт OSEK/VDX разрабатывался как стандарт открытой
архитектуры ОС и стандарт API для систем, применяющихся в
автомобильной промышленности. Однако стандарт получился
более абстрактным и начал использоваться и в других областях.
Стандарт соответствует стандартам программной модели AutoStar
(Automotive Open System Architecture).
OSEK/VDX состоит из нескольких частей, главные из которых:
стандарт для операционной системы (OS), коммуникационный
стандарт (COM) и стандарт для сетевого менеджера (NM). В дополнение к этим стандартам определяется язык реализации (OIL).
Первым компонентом стандарта OSEK является стандарт для ОС,
поэтому часто стандарт OSEK ошибочно воспринимается как стандарт ОСРВ. Хотя ОС и есть ключевой элемент стандарта, мощность
его состоит в интеграции всех его компонентов.
С появлением и внедрением этого стандарта начался отсчет нового поколения в технологии разработки программного обеспечения
для встраиваемых систем управления. Этот стандарт предназначен
для создания программно-инструментальных сред разработки распределенных систем управления, реализуемых на разнородных
компонентах и эксплуатируемых в условиях индустриальных помех в необслуживаемом режиме.
Разработчики стандарта существенным образом изменили классическую семиуровневую модель взаимосвязи открытых систем
(OSI). Эта модель дополнена компонентами управления сетью NM и
слоем взаимодействия IL.
Компонент управления сетью предназначен для осуществления
динамического контроля сохранности структуры сети и работоспособности ее узлов. Это свойство системы управления является немаловажным обстоятельством для средства передвижения, так как
отказ узла чреват аварией и человеческими жертвами.
Слой взаимодействия обеспечивает надежность коммуникаций при передаче сообщений по сети и также во взаимодействии
153
с компонентом управления предоставляет возможности для организации динамического контроля работоспособности узлов сети и
системы в целом.
В стандарт входит два типа микрооперационных систем реального времени. Первая – OSEK OS использует классические алгоритмы диспетчеризации FIFO и RR. Вторая – OSEKtime кардинальным
образом меняет подход к диспетчеризации задач.
В этой системе для обеспечения специфицированных времен отклика используется таблица времен запуска задач, формируемая
на этапе разработки алгоритма управления. Этот тип диспетчеризации носит название time triggered dispatcher или, сокращенно,
tt-диспетчер. Классические типы диспетчеризации, основанные
на прерываниях, в настоящее время принято относить к классу
event triggered. Кажется естественным назвать этот класс диспетчеризацией с событийным диспетчером и обозначать его как etдиспетчер.
Реализация tt-диспетчера в OSEKtime позволяет на время выполнения задачи заблокировать работу системы прерываний. При
этом возможность появления прерываний также регламентируется соответствующим табличным расписанием. Использование
OSEKtime возможно при одновременном использовании специализированной подсистемы, реализующей отказоустойчивую реализацию слоя взаимодействия.
Анализ и сравнение свойств систем управления при использовании разных типов диспетчеризации (tt и et) приведен в литературе [11, 12]. Подробно ряд важных деталей реализации стандарта
OSEK/VDX будет разобран в следующей главе.
§ 5. Измерение времени
в микропроцессорных системах
Принципы формирования и измерения временных интервалов
относятся к разряду ключевых элементов систем управления реального времени. Особенную значимость этот элемент приобретает
в распределенных системах управления, использующих автономные источники тактирующих импульсов. В таких системах появляется необходимость временной синхронизации устройств, разнесенных в пространстве.
При разработке технического задания на систему управления
для описания временных характеристик используется стандарт154
ная система измерений: секунда, миллисекунда, микросекунда.
Реализация этих требований в виде аппаратно-программных решений выявляет целый ряд особенностей.
В качестве иллюстрации рассмотрим систему управления встраиваемого класса, структурная схема алгоритма которой изображена на рис. 3.5.
Пусть система включает в себя Ns измерительных каналов и Nа
каналов управления. Цикл работы системы заключается в получении показаний датчиков (поток 1), их обработки (поток 2) и выработки на основании этих данных сигналов управления с периодом
Tc (поток 3). Это время определяется спецификой объекта управления и реализуемыми алгоритмами управления. Измерение времени организуется с помощью системного таймера и системы прерываний. Укрупненное описание алгоритма в адресно-временном
пространстве показано на рис. 3.9.
Система содержит четыре уровня: системный, измерительный,
вычислительный и уровень управления. Каждый из этих уровней
обслуживается своим компонентом, каждый из которых размещается в своей области памяти программ (ось А) и требует определенного количества командных циклов для своей реализации. Во время выполнения компонента он монопольно занимает ресурсы ядра,
и другие компоненты не могут им пользоваться. Для реализации
предписанного алгоритма функционирования компоненты должны запускаться в предписанном порядке, получать, использовать и
передавать другим компонентам информацию. Требуемый порядок
запуска прикладных компонентов обеспечивается системным компонентом и на рис. 3.9 отражается тонкими стрелками.
"
"
"
"
"
5
5G
5Ê
5
Рис. 3.9. Многоуровневое описание алгоритма функционирования
модельной системы
1 – системный компонент; 2 – измерительный компонент по NS каналам;
3 – вычислительный компонент; 4 – компонент выработки команд управления
по NA каналам
155
Системный компонент, обеспечивающий требуемый порядок
запуска прикладных компонентов, называется диспетчером. В рассматриваемом примере используется диспетчеризация с дисциплиной FIFO. Соответственно, исполняемый компонент получает в свое
распоряжение все ресурсы микропроцессора, и после завершения
он передает управление системному компоненту.
Передача информации с уровня на уровень (от компонента к
компоненту) на рис. 3.9 отражена утолщенными стрелками. Результат работы компонента зависит от корректной реализации
предписанного алгоритма, корректного приема данных от компонента предыдущего уровня. Соответственно, компонент должен
обеспечить корректное формирование и передачу данных на компонент следующего уровня.
В универсальных ОСРВ такая передача должна учитывать возможность передачи разнообразных типов данных: от бита до массива разнородных данных и должна быть адресной, т. е. содержать
информацию о компоненте – получателе данных. Как правило,
обмен данными осуществляется через специальные зоны памяти,
иногда называемые почтовыми ящиками, что делается в целях экономии требуемой памяти.
В соответствии с рис. 3.9 суммарное выполнение цикла измерение
– обработка – выработка команд управления осуществляется за время
Tf. Это время складывается из суммарных затрат на выполнение трех
вызовов системного компонента и вызовов прикладных компонентов.
В рассматриваемом примере возможность выполнение условия
Tf < Tc
(3.2)
должна быть обеспечена и проверена на этапе разработки программного кода. Выполнение этого соотношения является необходимым
условием возможности реализации системы с заданным специальным свойством, которое в рассматриваемом примере было количественно определено в виде требований на период запуска цикла:
измерение – расчет – управление. Для выполнения этого требования после предоставления ресурсов компоненту, обеспечивающему
выработку управляющих воздействий, системный компонент должен обеспечить задержку времени (Tс–Tf), перед тем как снова запустить измерительный компонент.
На рис. 3.10 представлено описание алгоритма реализации временной задержки на число командных циклов Tc–Tf, который является дополнением к описанию на рис. 3.9. В общих чертах алгоритм реализации задержки реализуется следующим образом.
156
UJD
5JNFS@
"
"
UJD
5G
¡ÆÁÏÁ¹ÄÁÀ¹ÏÁØ
5JNFS@5
EFMBZ@DPVOUFS
%FMBZ5Ds5G
¹ÈÌÊÃ˹žɹ
5D
§ºÉ¹ºÇËÐÁÃ
ÈɾÉÔ»¹ÆÁÂ
ÊÇÎɹƾÆÁ¾ÃÇÆ˾ÃÊ˹
5JNFS@5
EFMBZ@DPVOUFS
»ÇÊÊ˹ÆǻľÆÁ¾
ÃÇÆ˾ÃÊ˹»ÇÀ»É¹Ë ÁÀÈɾÉÔ»¹ÆÁÂ
ÁÊȾËоÉ
JGEFMBZ@DPVOUFS%FMBZ
À¹ÈÌÊËÁËÕ
ÁÀžÉÁ˾ÄÕÆÔÂ
ÃÇÅÈÇƾÆËFMTFSFUVSO
»ÇÊÊ˹ÆǻľÆÁ¾
ÃÇÆ˾ÃÊ˹»ÇÀ»É¹Ë
ÁÀÈɾÉÔ»¹ÆÁÂ
Рис. 3.10. Реализация задержки с помощью таймерного модуля
Таймерный модуль имеет собственный регистр (пусть это будет,
например, Timer_0) с разрядностью 2N. Число, записанное в этот
регистр, инкрементируется аппаратно на каждом командном цикле. При переполнении этого регистра, т. е. при попытке записать
в него число, равное 2N+1, модуль таймера вырабатывает сигнал
прерывания, и ядро микропроцессора осуществляет аппаратную
передачу управления на обработчик прерываний.
Обработчик прерываний выполняет ряд действий, главные из
которых в контексте рассматриваемого примера инкрементирование величины счетчика delay_counter, выделенного для организации задержек, и инициализация регистра таймера Timer_0. Далее
управление передается компоненту, который осуществляет диспетчеризацию. В нашем, простейшем случае, это проверка условия по
обеспечению требуемой длительности задержки. Если условие выполнено диспетчер осуществляет запуск очередного цикла, начав
его с передачи управления на измерительный компонент.
Период появления сигнала прерываний, обозначенный на
рис. 3.10 tic, зависит от разрядности N используемого таймера и
от его начального значения, записываемого в процессе инициализации. В рассматриваемом примере этот регистр инициализируется значением T0. Соответственно, оценка шкалы времени в
командах
tic [к] = 2N–T0.
(3.3)
157
Для пересчета в размерные единицы следует воспользоваться
формулой (3.1), что потребует конкретизации архитектуры ядра и
используемой тактовой частоты
tic [сек] = 1/(f * Nt)( 2N–T0).
(3.4).
По сути дела формулы (3.3), (3.4) определяют в первом приближении максимально возможную точность, достижимую в многоканальных системах управления. На эту точность можно влиять
за счет выбора частоты f, разрядности используемого таймера N и
значения параметра T0 (значение регистра при начальной инициализации).
Оговорка «в первом приближении» достаточно важна. Для реализации рассматриваемого модельного алгоритма требуется знание величины Tf, и, соответственно, встает вопрос о его измерении
в процессе выполнения компонентов базового цикла 2, 3, 4.
Необходимость такого усложнения диктуется тем обстоятельством, что в реальных многоканальных системах для обработки
сигналов, как правило, используются алгоритмы с многими возможными вариантами реализации по количеству требуемых команд, которое зависит от обрабатываемых данных и реализуемого
режима управления.
Для организации возможности измерения временных интервалов в течение всего цикла реализации алгоритма следует использовать один из таймеров, который принято называть системным. Графическая иллюстрация процесса реализации алгоритма функционирования для модельной системы изображена на
рис. 3.11.
"
"
"
¨É¾ÉÔ»¹ÆÁØÇËÊÁÊ˾ÅÆǼÇ˹žɹ
5
Рис. 3.11. Использование системного таймера
158
Это совершенно необходимое в ряде случаев усовершенствование введет к целому ряду усложнений как в описании алгоритма,
так и в способе его реализации.
На время обработки прерываний от системного таймера производится приостановка выполнения алгоритма, реализуемого компонентом, работа которого была прервана. Соответственно, для того
чтобы компонент мог после завершения обработки прерывания
корректно возобновить реализацию алгоритма в процессе обработки прерывания, должны быть, как минимум, сохранены значения
ряда регистров ядра, так как при возврате из прерывания значения
этих регистров должны быть восстановлены.
Кроме этого, корректная передача управления требует введения
атрибутов текущего состояния компонента, хранения их в таблицах описания диспетчера и, конечно же, командных циклов на их
обработку. Все эти операции, по сути дела, приводят к увеличению
длительности реализации компонента, обеспечивающего обработку прерывания от системного таймера. Но самая неприятная особенность заключается в зависимости от особенностей реализации
прикладных задач.
Эта особенность организации процесса измерения описывается
следующим соотношением:
Tp* [к] = Ntic * tic [к] = Tp [к] + Ntic* Tisr[к],
(3.5),
где Tp* [к] – измеренная длительность интервала в командах; Ntic –
разница между значением счетчика числа прерываний и значением
в момент начала измерений; tic [к] – период системного таймера в
командах; Tp[к] – чистая длительность измеряемого интервала при
выключенном системном таймере; Tisr[к] – количество команд,
требующихся на обработку прерывания.
Интересно отметить, что эта формула демонстрирует наличие
глубоких параллелей с квантовой механикой. В частности, из нее
следует невозможность измерить временной интервал, меньший,
чем период системного таймера. При этом сама возможность измерения времени подразумевает внесение искажений в измеряемую
величину.
Спецификация временных параметров. Существование ограничения на точность измерения временных интервалов приводит
к тому, что наиболее распространенный способ спецификации временных параметров заключается в требовании обеспечить каждому из прикладных компонентов необходимые ресурсы для выполнения за время, не превышающее предельное, обозначаемое,
159
как tdeadline. Англоязычный термин «deadline» для определения
предельного времени выполнения слегка мрачноват, но для систем
жесткого реального времени его использование оправдано. Конкретная величина этого параметра, в общем случае, для каждого
из каналов управления своя и может, кроме этого, зависеть от конкретного режима эксплуатации.
Для спецификации временных требований на практике используются еще два способа.
Первый заключается в спецификации худшего времени выполнения. Звучит не очень благозвучно, но соответствует переводу
определения « Worst Case Execution Time» (WCET). Строго говоря,
для реальных систем управления такая спецификация требует конкретизации режимов и, в лучшем случае, относится к нормальным
режимам эксплуатации системы управления.
Второй способ спецификации более реалистичен и предполагает использование среднего времени выполнения (Average Case
Execution Time – ACET). Эти времена связаны собой следующим
соотношением:
tACET < tWCET < tdeadline.
(3.6)
В работе [1] предложена более радикальная точка зрения на
временные характеристики цифровых систем управления, заключающаяся в утверждении, что это вероятностные характеристики.
Соответственно, их следует описывать с использованием функций
плотности случайной переменной или функции распределения.
Рассмотрим в общих чертах использование этого подхода. В этом
случае в качестве среднего времени реакции следует использовать
математическое ожидание M() случайной величины treact, описывающей время реакции системы:
tACET = M (treact).
(3.7)
Радикализм предложения заключается в утверждении, что невозможно обеспечить выполнения условия (3.6) и всегда существует вероятность того, что время реакции превысит tdeadline, которая
рассчитывается по формуле
tdeadline
P(treact > tdeadline ) = 1 −
∫
f (x)dx.
(3.8)
0
Реализация предлагаемого подхода предполагает знание функции плотности распределения f(x) для времени реакции системы.
160
Простейший вариант такой оценки – использование статистических методов оценки и набора соответствующих образом построенных тестов в процессе отладки.
Как правило, в реальных многоканальных системах управления разные каналы обслуживаются различными компонентами и
реализуют разные функции. В этом случае специфицированные
максимальные интервалы по предоставлению ресурсов для разных
групп определяются раздельно. Спецификация временных параметров в таких системах будет представлять вектор с компонентами
tACET, tWCET.
Следует указать, что в реальной жизни в процессе проектирования, кодирования и тестирования системы управления может выявиться невозможность выполнения специфицированного временного ограничения. Далее в соответствии с V-моделью рассматриваются возможности оптимизации вариантов реализации компонентов, изменения скорости выполнения требуемых операций за счет
использования тактовой частоты, других периферийных модулей
и т. п.
Как крайняя мера, рассматривается возможность изменения архитектуры аппаратной части или изменения спецификации на систему управления. По сути дела, это означает необходимость проведения разработки полного цикла и, как правило, свидетельствует о
низкой квалификации команды разработчиков.
Контрольные вопросы и задания к главе 3
1. Какими свойствами должен обладать диспетчер задач, чтобы
ОСРВ была POSIX-совместимой?
2. Оцените количество команд, которое выполнит за 50 мс процессор с RISC архитектурой, реализующей команду за 4 такта и работающий на частоте 20 МГц.
3. Выведите формулу для оценки времени реакции системы
управления с N каналами, временем обслуживания каждого канала Ti и диспетчеризацией FIFO. В качестве времени реакции используйте время опроса цикла очереди задач Tc.
4. Как изменится эта оценка при использовании системного таймера, реализованного на прерывании с наивысшим приоритетом?
Время обслуживания прерывания TISR.
5. Постройте процессограмму диспетчеризации RR для системы
управления с тремя потоками.
161
6. Какую аппаратную структуру должна иметь система управления, требующая одновременного использования глобального времени и атомарных операций?
7. Разберите базовые особенности схемы синхронизации показаний датчиков, получившей название Burredo и описанную в литературе [13].
8. Оцените точность измерения временных интервалов при использовании внешних часов реального времени.
Литература к главе 3
1. Астапкович А. М. Микрооперационные системы реального
времени. СПб.: Политехника, 2002. 246 с.
2. Зыль С. Н. Проектирование, разработка программного обеспечения систем реального времени. СПб.: БХВ-Петербург, СанктПетербург, 2010. 336 с.
3. Астапкович А. М. Семинары ASK Lab 1997. СПб.: Политехника, 1998. 134 с.
4. Astapkovich A. M. Introduction to Theory of Real-Time MocroOperating Systems for Embedded Control Systems. Proc. 6-th Seminar
of Finish-Russian University Cooperation in Telecommunications
(FRUCT) Program. Helsinki. Finland. 3–6 November 2009.
С. 3–18.
5. Гленн Сайлер. Операционные системы VxWorks и Wind River
Linux: подходы к реализации реального времени //авторизованный перевод Горбунова Н.//Современные технологии автоматизации. 2001. № 3. С. 14–18.
6. Горбунов Н. О выборе встраиваемой ОС для проекта// Современные технологии автоматизации. 2011. № 3. С. 14–18.
7. Олифер В. Г, Олифер Н. А. Сетевые операционные системы.
СПб.: Питер, 2001. 544 с.
8. Хайкин Саймон. Нейронные сети. Полный курс. М.: Изд. дом.
«Вильямс», 2006. 1104 с.
9. Барский А. Б. Логические нейронные сети: учеб. пособие.
Интернет-Университет Информационных Технологий; БИНОМ.
Лаборатория знаний, 2007. 352 с.
10. IEEE Standard 1003.1-1988. Portable Operating System
Interface for Computer Environments.
11. Kopetz H. TIME-TRIGGERED REAL-TIME COMPUTING –
Institut fur Technische Informatik TU Vienna, Austria.
162
12. Fabian Scheler, Wolfgang Schröder-Preikschat, FriedrichAlexander. Time-Triggered vs. Event-Triggered: A matter of
configuration? University Erlangen-Nuremberg, Department of
Computer Science 4.
13. Джон Перри (John Perry), Джошуа Чайлдс (Joshua Childs).
Синхронизация датчиков для прямой геодезической привязки на
небольших беспилотных летательных аппаратах (БПЛА)//Встраиваемые системы. 2010. № 2. С. 15–19.
163
Глава 4. СОВРЕМЕННЫЕ ПРОГРАММНОИНСТРУМЕНТАЛЬНЫЕ ПЛАТФОРМЫ
В современных условиях ключевым компонентом успеха является время вывода продукта на рынок (time to market), немалую
долю которого составляет разработка прикладного программного
обеспечения. Необходимость повышения производительности разработчиков привела к широкому использованию ОСРВ-технологий
разработки, которые являются ядром современных программноинструментальных платформ. Основной тенденцией, оформившейся в течение последних десяти лет, является повсеместное использование технологий разработки ОСРВ и mOСРВ, обеспечивающих
не только требуемую функциональность разрабатываемых систем,
но и технологичность проведения разработок, а также ряд сервисов, облегчающих сопровождение изделия.
Глава посвящена рассмотрению современных программноинструментальных платформ.
Описание платформ делалось по технической документации,
которая имеется на сайтах компаний. В силу этого, имеется существенный терминологический разнобой при описании различных
платформ, который нивелировался, насколько это было возможно.
В качестве предостережения к дальнейшему изложению подходит
цитата из Киплинга: «В джунглях так много слов, звук которых
расходится со смыслом», которая наиболее полно отражает ситуацию, сложившуюся в настоящее время в этой области.
4.1. Платформа QNX6
Операционная система QNX является самой распространенной
ОСРВ, имеющей многолетнюю историю. В настоящее время на
практике используются две версии QNX4 и QNX6.
В этом разделе будут рассмотрены ключевые особенности платформы QNX6, ядром которой является ОСРВ Neutrino. Структура
и построение Neutrino обеспечивают возможность ее эффективного
использования в распределенных системах управления.
Система реализована в соответствии со стандартами POSIX, и
это рассмотрение будет являться также иллюстрацией к ряду базовых положений этой системы стандартов. Вместе с тем ориентация
на использование в сетевых системах потребовала существенного
развития механизмов информационного обмена между процессами
по сравнению с ОСРВ QNX4.
164
Архитектура Neutrino обеспечивает возможность масштабирования как «вверх» (добавляя новые сервисы и расширяя функциональность), так и «вниз» (урезая функциональность, чтобы «втиснуться» в ограниченные ресурсы). Иными словами, QNX Neutrino
можно установить там, где QNX4 не уместилась бы.
§1. Общие сведения
Операционная система QNX6, выпущенная в 2001 году, имеет и другое название – QNX Neutrino. Глобальной целью проекта
Neutrino было создание масштабируемой и развиваемой универсальной ОСРВ. Эта операционная система должна была быть пригодной для построения систем реального времени на самом широком спектре реализаций аппаратного компонента, начиная с одноядерных автономных устройств и до сетевых систем управления на
базе многоядерных процессоров как уже выпускаемых, так и новых модификаций.
В сочетании с несколькими интегрированными средами поддержки разработки ОСРВ формируют программно-инструментальную
платформу QNX6. Успешное решение задачи по созданию универсальной ОСРВ потребовало применения как известных решений,
так и ряда концептуально новых подходов, связанных с переходом
на микроядерную структуру.
Реализация базовых компонентов микроядра Neutrino соответствует следующим стандартам POSIX: 1003.1, 1003.1a, 1003.1b
Realtime, 1003.1c Threads, 1003.1d Realtime Extensions, 1003.13
Realtime Profile Support. Стандарты семейства POSIX 1003.1 используют модель операционной системы с возможностью выполнения многих процессов в квазипараллельном режиме. При этом
предполагается, что каждый процесс имеет свою защищенную память, недоступную для компонентов другого потока. По сути дела,
это соответствует требованиям стандарта ARINC-653.
§2. Состав платформы QNX6
За десять лет, прошедшие со дня выхода в свет ОСРВ Neutrino,
существенное развитие получила инструментальная составляющая
этой платформы.
В настоящее время платформа QNX6 включает в себя:
165
операционную систему реального времени QNX Neutrino;
программно-инструментальную среду QNX Momentics, реализованную на базе IDE Eclipse;
пакеты программного обеспечения промежуточного слоя QNX
Aviage.
Состав инструментального компонента платформы QNX6 показан на рис. 4.1.
Платформа обеспечивает возможность разработки программного обеспечения для систем управления, реализуемых на базе микропроцессоров:
Intel x8, AMD – CISC-архитектура фирмы INTEL;
MIPS – RISC-архитектура фирмы MIPS Technologies;
ARM, StrongARM – RISC-архитектура фирмы Advance Risc
Machine;
SH-4 – RISC-архитектура фирмы Renesas;
PowerPC – RISC-архитектура фирмы IBM.
При этом обеспечивается поддержка наиболее распространенных шин ISA, PCI, VME,STD, STD 32 и PC/104.
¡¦ª«©¬¥ž¦«™¤µ¦´¢£§¥¨µ·«ž©ª0$
8*/%08440-"3*42/9/&653*/0
¡ÆÊËÉÌžÆ˹ÉÁ½ÄØ
ɹÀɹºÇËÃÁÃǽ¹
ÈÉÁÄÇ¿¾ÆÁØƹØÀÔùÎ
$$+"7"
¥ÇÆÁËÇÉ
Ͼľ»ÔÎ
ÊÁÊ˾Å
ªÁÅ»ÇÄÕÆÔÂ
©™š§°žž
ÇËĹ½ÐÁÃ
¨©§ª«©™¦ª«›0
¨ÉÇ͹ÂľÉ
*%&
ƹº¹À¾&$-*14&
ÈÉÁÄÇ¿¾ÆÁÂ
¨ÇÊËÉÇÁ˾ÄÕ
ÈÉÁÄÇ¿¾ÆÁÂ
1)050/
ªÁÊ˾ÅÆÔÂ
ÈÉÇ͹ÂľÉ
¨ÇÊľ½Ç»¹Ë¾ÄÕÆÔÂ
ÃÇÅÅÌÆÁùÏÁÇÆÆÔÂ
ùƹÄ&5)&3/&5
™¨¨™©™«¦™¸ª§ª«™›¤¸·²™¸
©™ ©™š™«´›™ž¥§¢ª¡ª«ž¥´
Рис. 4.1. Структура инструментальной платформы QNX6
166
В отличие от предшествующих версий, работавших только в
PC-совместимых архитектурах, QNX Neutrino обеспечивает возможность адаптации к широкому спектру возможных аппаратных
конфигурации. Гибкость по отношению к аппаратной реализации
конкретной системы обеспечивается использованием библиотек
компонентов запуска и инициализации микропроцессора и библиотек драйверов периферийных модулей (Board Support Package –
BSP). Эти драйверы, насколько это было возможно, реализованы в
универсальном виде, обеспечивающем широкий спектр микропроцессорных реализаций. Исходные коды более чем сотни BSP можно найти на портале Foundry27.
Базовый состав BSP обеспечивает возможность осуществить:
запуск и инициализацию платы одноплатного компьютера;
запуск BIOS, поиск и копирование образа QNX Neutrino в ОЗУ
микропроцессора;
конфигурирование и инициализацию ядра ОС.
При этом у разработчика имеется свобода по разработке собственных драйверов устройств, которая поддерживается менеджером ресурсов OC Neutrino.
§3. Концепция ОСРВ Neutrino
Концепция OC Neutrino основывается на следующих базовых
принципах:
использование микроядерной архитектуры;
модульная организация системы;
информационный обмен между процессами посредством сообщений;
поддержка платформенного подхода.
В соответствии с концепцией ОСРВ строится вокруг относительно небольшого ядра, которое обеспечивает минимально необходимый набор функций обслуживания для опционально подключаемых системных и прикладных компонентов. Модульная организация подразумевает наличие широкого спектра компонентов,
реализующих функции операционной системы, но подключаемых
в программный код по мере необходимости.
Алгоритм функционирования многоканальной системы реального времени представляет собой некоторое множество взаимодействующих нитей и процессов. Реализация компонентов осуществляется под управлением базовой сущности OC Neutrino, называ167
емой нитью (thread). Понятие нить введено в стандарте POSIX, и
оно представляет собой компонент в стадии реализации. В данном
случае представляется уместным использование понятия «компонент», заимствованного из отечественного ГОСТа.
Совокупность нитей образует процесс, который должен иметь
хотя бы одну нить. Процесс обладает собственным защищенным
адресным пространством. Процессы могут реализовываться как на
одном аппаратном модуле, так и на системе модулей, объединенных
в сеть. Информационный обмен между нитями внутри процесса и
нитями в разных процессах осуществляется с использованием регламентированных правил. Реализация обмена обеспечивается набором системных компонентов и осуществляется через программно
реализованную шину.
Считается, что Neutrino – это первая коммерчески поставляемая система, использующая универсальный механизм сообщений
для обмена между всеми компонентами.
Обобщенная структура ОСРВ Neutrino приведена на рис. 4.2.
Выполнение системных и прикладных компонентов осуществляется под управлением микроядра и менеджера процессов (Process
Manager). Эта пара базовых элементов ОС называется procnto.
Пользовательский процесс имеет доступ к функциям микроядра
и функциям менеджера процессов. Доступ к функциям микроядра
осуществляется через непосредственные вызовы, а доступ к функциям менеджера процессов осуществляется путем посылки сообщений для procnto.
š¤§£130$/50
¥¡£©§¸©§
§ª©›/FVUSJOP
§ºÊÄÌ¿Á»¹ÆÁ¾
ÆÁ˾ÂUISFBE
ÊÁ¼Æ¹ÄÇ»TJHOBM
½ÁÊȾËоÉÁÀ¹ÏÁÁ
TDIFEVMJOH
˹žÉÇ»UJNFS
ÊÁÆÎÉÇÆÁÀ¹ÏÁÁ
TZODISPOJ[BUJPO
¨§¤µ §›™«ž¤µª£§ž¨©§ª«©™¦ª«›§
¥¾Æ¾½¿¾É
ÈÉÇϾÊÊÇ»
QSPDFTT
NBOBHFS
͹ÂÄÇ»¹Ø
ÊÁÊ˾Ź
ÈÉÁÄÇ¿¾ÆÁØ
¨ÉǼɹÅÅÆÇɾ¹ÄÁÀ̾ŹØÑÁƹ
ªË¾Ã
5$1*1
¨ÇÄÕÀ
ÁÆ˾É;ÂÊ
1IPUPO
Рис. 4.2. Структура ОСРВ Neutrino
168
½É¹Â»¾É¹
ÌÊËÉÇÂÊË»
При этом системные процессы практически не отличаются от
прикладных, которые имеют возможность использовать практически все функции микроядра. Соответственно, это способствует расширению возможностей операционной системы путем разработки
специализированных пользовательских приложений.
Менеджер процессов обеспечивает не только управление процессами, но и операции работы с памятью и файловой системой.
Важно подчеркнуть, что Neutrino разрабатывалась с учетом
необходимости обеспечить ее удобную интеграцию в программноинструментальные платформы.
В частности, блок procnto поставляется в двух модификациях, одна
из которых предназначена для использования в процессе отладки.
Данная инструментальная версия называется proconto-instr и
обладает широким наборов средств для трассировки и мониторинга состояния разрабатываемой системы управления в процессе исполнения разрабатываемого кода. Особенно важно в современных
условиях, что proconto-instr обеспечивает работу как с одноядерными, так и с многоядерными архитектурами микропроцессоров.
§4. Реализация защиты памяти
Стандарты семейства POSIX 1003.1, которым соответствует
Neutrino, используют модель операционной системы с возможностью выполнения многих процессов в квазипараллельном режиме.
При этом предполагается, что каждый процесс имеет свою защищенную память, недоступную для компонентов другого процесса.
Ключевое преимущество, которое обеспечивает использование
разделения памяти, заключается в увеличении его робастности
(robustness). Это понятие подразумевает устойчивость программного кода со сложной структурой по отношению к возможным нарушениям в работе его отдельных компонентов. Такой подход защищает данные других процессов от повреждения, что, в принципе,
способствует повышению робастности кода.
Для защиты памяти Neutrino имеет в своем составе опционально подключаемый компонент управления памятью (Memory
Management Unit – MMU). Этот компонент обеспечивает работу с
таблицами описания распределения памяти между процессами.
Таблицы используются аппаратным модулем микропроцессора для
анализа корректности выполняемых действий. Обычно MMU делит
память на страницы по 4 Кбайта.
169
Программный сторожевой таймер. Защита памяти реализуется аппаратными средствами и блокирует возможность несанкционированного доступа к памяти. Как правило, возникновение
такой ситуации возможно из-за ошибок в разрабатываемом программном обеспечении.
Процесс, компонент которого попытался изменить память другого процесса, блокируется и возникшая ситуация протоколируется, что обеспечивает разработчикам возможность анализа возникшей ситуации. Реализация этой возможности, получившей название программный сторожевой таймер, обеспечивает ряд возможностей, существенно облегчающих отладку.
Стандартная реализация аппаратного сторожевого таймера производит теплый рестарт системы при переполнении его регистра.
При этом анализ ситуации затруднен, так как фактически отсутствует информация о состоянии системы. Программный сторожевой таймер обладает большими возможностями, но эти возможности доступны для разработчика лишь при нарушении правил доступа к памяти.
При фиксации нарушения правил доступа к памяти ОС передают управление специализированному компоненту пользователя,
который проводит обработку и протоколирование возникшей ситуации. При этом возможно прекратить выполнение процесса нарушителя и возобновить его выполнение с целью набора статистики
или остановить систему, обеспечив соответствующую световую или
звуковую индикацию.
Следует отметить, что эта возможность существенно облегчает
анализ сбойных ситуаций при опытной и штатной эксплуатации
системы, когда на передний план выходят перемежающиеся отказы для плохо детерминированных условий эксплуатации. Представляется, что название «программный черный ящик» лучше бы
отражало эти возможности ОС Neutrino.
§5. Реализация нитей (потоков)
Реализация компонентов осуществляется под управлением такой сущности, как нить (thread). Понятие «нить» соответствует
стандарту POSIX, но в литературе по ОС Neutrino для обозначения этой сущности используется также понятие «поток». Понятие
«нить» или «поток» можно также определить как фазы состояния
компонента в процессе выполнения. Лучше бы использовать фор170
мулировку «компонент в процессе исполнения», но термин «процесс» уже, к сожалению, занят.
Neutrino поддерживает модель нитей стандарта POSIX 1003.1с.
В соответствии с этой моделью процесс может динамически создавать и уничтожать одну или более нитей. Нити для информационного обмена между собой могут использовать адресное пространство своего процесса. Этот же стандарт определяет, что нити должны иметь собственные уровни приоритетов (до 256).
Некоторое количество потоков образует процесс, для реализации которого выделяется собственное адресное пространство. Процесс должен содержать, по крайней мере, один поток. В работе [1]
нестрогое определение процесса звучит, как «процесс – это контейнер, содержащий потоки». Еще одна напрашивающаяся аналогия,
связанная с названием ОСРВ Neutrinо: поток – это атом, из которого строятся молекулы процессов. При этом следует помнить, что
понятие «атом» уже использовано для обозначения фрагментов
кода, для корректного выполнения которых требуется блокирование системы прерываний.
Описание алгоритма управления представляет собой программу
на языке высокого уровня (C,JAVA) написанную в соответствии с набором правил QNX6. Программа пишется с использованием пользовательских функций, учитывающих специфику реализуемого алгоритма управления, и системных функций. Системные функции обеспечивают работу с базовыми объектами, изображенными на рис. 4.3.
В зависимости от конкретного приложения нити могут исполняться независимо (редко встречающийся случай) или требуют
информационного обмена, определяющего как конечные результаты обработки информации, так временную структуру реализации
реализуемого алгоритма. Соответственно, помимо нитей в набор
объектов микроядра входят компоненты, обеспечивающие информационное взаимодействие потоков между собой в процессе выполнения: connection, channel, pulse.
Разработчики, использующие платформу QNX6, могут по своему
выбору использовать для работы с нитями либо API Neutrino, либо
стандартную библиотеку pthreads, содержащую около 30 функций.
Использование функций из этой библиотеки не приводит к вызову
функций микроядра, обеспечивающего работу с нитями. При этом
каждая функция микроядра для работы с потоками, имеет аналог в
стандартной библиотеке. Это означает возможность использования
технологии компонентного программирования, оставаясь в рамках
платформы QNX6.
171
4DIFE 5ISFBE
5ISFBE
4DIFE ¥
$POOFDUJPO
¡
4ZODI
£
4JHOBM
©
.FTTBHF §
$IBOOFM
¸
5JNFS

$MPDL
%JTQBUDI
5JNFS
7FDUPS
©
$IBOOFM
§
*OUFSSVQU
1VMTF
ªÁÊ˾ÅÆÔ¾ »ÔÀÇ»Ô
§ºÓ¾ÃËÔ
ÅÁÃÉÇؽɹ
Рис. 4.3. Объекты и системные вызовы микроядра Neutrino
Количество потоков внутри процесса может динамически меняться в процессе исполнения. Создание потока осуществляется
посредством вызова функции pthread create(), которая выделяет и
инициализирует все необходимые потоку ресурсы внутри адресного
пространства процесса путем создания стэка потока. После успешного завершения этих операций производится постановка потока в
очередь на выполнение.
Выполнение потока может быть прервано при появлении вызова микроядра, регистрации прерывания или возникновения ошибки (exception).Уничтожение потока осуществляется функциями
pthread exit() или pthread cancel() и приводит к освобождению занимаемых им ресурсов.
В процессе своего жизненного цикла поток может находиться в
разных состояниях, набор которых приведен на рис. 4.4. Описание
этих состояний приведено в табл. 4.1.
С одной стороны, потоки используют общее адресное пространство своего процесса, а с другой – имеют собственные данные, которые обеспечивают идентификацию потоков при информационных
172
$0/%7"3
.65&9
+0*/
3&1-:
4*(4641
4*(
8"*5*/'0
4&/%
3&$&*7&
*/5&33615
3&"%:
/&5@3&1-:
/"/0
4-&&1
/&5@4&/%
4&.
8"*51"(&
8"*5$59
36//*/(
45011&%
%&"%
45"$,
8"*5
5)3&"%
Рис. 4.4. Возможные состояния потока
обменах. Эти данные называются атрибутами потока. Базовый набор атрибутов потока приведен в табл. 4.2.
Таблица 4.1
Состояния нити в ОСРВ Neutrino
Состояние нити
CONDVAR
DEAD
INTERRUPT
JOIN
Описание состояния
Выполнение нити блокировано
условной переменной
Выполнение нити завершено, и
она ожидает присоединения к
другой нити
Нить блокирована и ожидает сигнала прерывания
Нить блокирована и находится в
ожидании присоединения к другой нити
Вызываемые системные
компоненты
pthread condvar
wait()
InterruptWait()
pthread join()
173
Окончание табл. 4.1
MUTEX
NANOSLEEP
NET REPLY
NET SEND
Нить блокирована переменной
разграничения доступа (mutual
exclusion lock) вызовом системного
компонента
Нить переведена в состояние
приостановки исполнения (sleep)
на короткий интервал времени вызовом системного компонента
Нить ожидает сигнала ответа по
сети
Нить ожидает доставки сигнала
или пульса
Нить ожидает ресурса для выполнения, пока процессор исполняет
другую нить с большим или равным приоритетом
RECEIVE
Нить блокирована для получения
сообщением
REPLY
Нить блокирована для отправки
сообщением
RUNNING
Компонент нити выполняется процессором
SEM
Нить ожидает посылки значения
семафора
SEND
Нить блокирована в ожидании,
когда будет получено посланное ее
сообщение
SIGSUSPEND Выполнение нити приостановлено
до получения сигнала
SIGWAITINFO Нить блокирована в ожидании
сигнала
STACK
Нить ожидает предоставления
виртуального адресного пространства для организации стека
STOPPED
Нить блокирована в ожидании
сигнала SIGCONT
WAITCTX
Нить ожидает получения переменной с плавающей запятой
WAITPAGE
Нить ожидает предоставления
физической памяти
WAITTHREAD Нить ожидает, пока создастся дочерняя нить
pthread mutex lock()
nanosleep())
MsgReply()
MsgSendPulse(),
MsgDeliverEvent(,)
SignalKill())
READY
174
MsgReceive()
MsgSend()
SyncSemWait()
MsgSend()
sigsuspend()
sigwaitinfo()
ThreadCreate() вызывается порождающим процессом
ThreadCreate()
Таблица 4.2
Атрибуты потока Neutrino
tid
register set
Порядковый номер внутри своего процесса
Собственный указатель на команду (IP) и указатель
на стэк (SP)
stack
Стэк потока, сохраняемый внутри адресного пространства процесса
signal mask
Маска сигналов
thread local storage Память для хранения локальных данных нити
(Thread Local Storage – TLS), таких как: tid,pid,
stack, stack base, errno
cancellation handlers Функции формирования данных при уничтожении
нити
Диспетчеризация потоков осуществляется автономно, без учета
состояния своего и других процессов. Потоки, готовые к исполнению, образуют очереди, упорядоченные в соответствии с приоритетами. Список дисциплин традиционен для QNX: FIFO, RR и адаптивная. С этой точки зрения, поток может находиться в трех состояниях: выполнения, быть вытесненным другим потоком с большим
приоритетом или быть заблокированным.
В работающей системе приоритет потока может изменяться
либо путем прямой манипуляции, либо средствами микроядра
при получении им сообщения от потока с большим приоритетом.
Существует и ряд других возможностей. Это краткое описание, рисунок и таблицы являются иллюстрацией жизненного правила «за
все надо платить». В рассматриваемом случае большое количество
атрибутов нитей и достаточно большие ресурсы на их реализацию –
это плата за универсальность и гибкость Neutrino. Неслучайно в
фирменном руководстве по Neutrino в разделе, относящемся к описанию нитей, имеется упоминание о ящике Пандоры.
Данное замечание в большей степени относится к стадии начального освоения платформы. Как показывает опыт, на практике такое
обилие возможностей приводит к разработке внутрифирменного
стандарта де-факто, который определяет минимально необходимый
набор опций, обеспечивающих разработку конкретного проекта.
§6. Синхронизация и обмен сообщениями
Поддержка модели потоков подразумевает возможность использования общих данных для реализации своих компонентов. Иерархия
175
способов обмена двухуровневая. Она включает в себя обмены внутри
процесса и обмены информацией нитями из разных процессов.
Для обеспечения корректного использования общих данных применяется целый ряд механизмов синхронизации доступа к данным,
реализуемых соответствующими системными компонентами.
Средства синхронизации доступа к данным включают в себя блоки взаимного исключения (mutex), семафоры (semaphore), условные переменные (condvar) и более удобный вариант его реализации
в виде sleepon locks, барьерный механизм для реализации «матричных» обработок данных потоками (barrier), механизм «много потоков читателей – один поток писатель (reader/writer locks)».
Обмен посредством сообщениями между процессами (Inter
Process Communication, IPC) – ключевая особенность этой операционной системы, которая обеспечивает ее гибкость. Обмен сообщениями, по сути дела, является тем клеем, который связывает модули Neutrino и прикладные компоненты в единое целое.
В табл. 4.3 приведен примерный перечень возможностей для
передачи информации между процессами.
Таблица 4.3
Разновидности типов коммуникаций Neutrino
Тип
Передача сообщений (message-passing)
Сигналы (signals)
POSIX очереди (POSIX message queues)
Разделяемая память (shared memory)
Трубы (pipes)
FIFO
Уровень реализации
Микроядро
Микроядро
Внешний процесс
Менеджер процессов
Внешний процесс
Внешний процесс
Сообщение представляет собой пакет байтов, пересылаемых одним процессом другому. На структуру и содержание сообщения не
накладывается никаких ограничений. Конкретное значение содержания сообщения имеет смысл только для процесса отправителя
и процесса получателя сообщений. Так как речь идет о системах
управления реального времени, требуется обеспечить синхронизацию информационно-взаимодействующих процессов.
В общих чертах это осуществляется следующим образом. Текущее состояние процесса описывается соответствующей переменной. Посылка сообщения, ожидание и прием сообщения соответствующим образом меняют текущее состояние процесса. В частности, нить выполнившая вызов системной функции MsgSend() для
176
¨©§¯žªª
4&37&3@
¨§«§£@
¨§«§£@
¨§«§£@¥
$Ǿ½ÁƾÆÁ¾
$POOFDUJPO
$POOFDU"UUBDI
£¹Æ¹Ä
$IBOOFM
$IBOOFM$SFBUF
¨©§¯žªª
$-*&/5
¨§«§£@
¨§«§£@
¨§«§£@£
Рис. 4.5. Процедура обмена сообщениями
отправки другой нити, которая может находиться внутри другого
процесса, будет блокирована до тех пор, пока нить – адресант сообщения не выполнит вызова системной функции MsgReceive(), обработает полученное сообщение и не выполнит вызова системной
функции MsgReply().
В свою очередь, микроядро использует данные о текущем состоянии процесса и его приоритете для диспетчеризации оптимальным образом всех исполняемых других процессов. Передаваемые
сообщения адресуются не посредством указания адреса нити получателя и адреса нити отправителя, а путем предварительного создания описания каналов и соединений. Эта процедура иллюстрируется рис. 4.5. Нить, которая ожидает сообщения, должна создать
канал для его передачи. Нить, которой требуется послать сообщение, должна сначала установить соединение путем подключения
к каналу. Эти операции выполняются путем вызова соответствующих системных функций ChannelCreate() и ConnectAttach(). У этих
функций есть антиподы ChannelDestroy() и ConnectDetach().
После установления соединения процесс клиент может посылать сообщения, пользуясь системной функцией MsgSend().
Несколько нитей могут посылать сообщения в один канал, при
этом разделяя между собой одно соединение. При этом несколько
нитей могут быть одновременно блокированы в канале. И соединения, и каналы идентифицируются в программах числовыми идентификаторами аналогично файловым дескрипторам.
Существует разновидность укороченных сообщений, называемых «пульсами» (pulses). Пульсы имеют два отличия от обычных
сообщений. Во-первых, для них регламентируется объем сообщения, который составляет 5 байт (4 байта полезной нагрузки), а вовторых, это не блокирующие сообщение. Время доставки информации таким способом существенно меньше, чем при процедуре Send/
Receive/Reply доставки обычных сообщений. Обмен пульсами часто используется при написании обработчиков прерываний.
177
§7. Система прерываний, системные часы
и таймеры
Время обработки аппаратных прерываний является ключевым
моментом для любой ОС реального времени, использующей etдиспетчеризацию. В таких системах минимально возможное время
реакции зависит от механизма реализации обработки прерываний.
При этом принципиально важно помнить, что интерес представляют системы с числом каналов, измеряемых десятками, а ошибкой
является и превышение специфицированного временного темпа обработки информации. В целом ряде случаев это приводит к вероятностному характеру поведения системы [2].
В Neutrino при появлении сигнала прерывания от аппаратного модуля, управление передается на уровень микроядра, которое
осуществляет подготовительные работы по запуску обработчика
прерываний, реализуемых пользовательским компонентом.
В одноканальном приближении ключевым параметром является время реакции на событие (interrupt latency), представляющее
временной интервал между появлением сигнала прерывания и началом выполнения первой команды соответствующего обработчика
прерываний. Это время относительно невелико. Однако оно может
существенно возрасти, если система прерываний будет заблокирована, например, каким-либо системным процессом.
Задержка диспетчеризации. С учетом архитектуры Neutrino
обработка прерываний осуществляется запуском нити обработчика соответствующих прерываний, обладающим высоким приоритетом. Таким образом, содержательная реакция на сигнал прерывания последует лишь после начала выполнения этой нити. Для
определения задержки при таком варианте обработки прерываний
введена характеристика, называемая задержкой диспетчеризации
(scheduling latency). На самом деле речь идет о времени реакции на
прерывание с учетом задержки на диспетчеризацию, но это было
бы слишком длинное название.
Задержка диспетчеризации определяется как временной интервал между моментом исполнения последней инструкции обработчика прерываний, фиксирующего появление аппаратного прерывания, и началом выполнения первой команды нити драйвера,
обрабатывающей это прерывание.
Эти два сценария описывают наиболее часто встречающиеся на
практике случаи относительно редких прерываний.
178
Вложенные прерывания. Для применения оценки времени реакции с помощью методологии наихудшего случая следует рассматривать сценарий с одновременным появлением нескольких прерываний. Этот сценарий разработчики Neutrino называют вложенными прерываниями (nested interrupts).
Модель обработки прерываний в общих чертах выглядит следующим образом. Нить, имеющая соответствующие привилегии,
может динамически устанавливать и удалять обработчики прерываний путем передачи микроядру адреса функции-обработчика
прерываний ISR (Interrupt Service Routine). При возникновении
прерывания обработка передается сначала в микроядро, которое содержит код для его переадресации. Перед вызовом ISR микроядро
сохраняет контекст исполняемой нити и переустанавливает регистры процессора таким образом, что ISR имеет доступ к адресному
пространству нити, в которой он содержится.
Это позволяет ISR выполнить обработку, пользуясь данными и
буферами нити, в которой она содержится, или буферизовать принятые данные для последующей обработки этой нитью. Это также
позволяет ISR осуществлять доступ ко всем устройствам, находящимся в домене ответственности (области префиксов) данной нити,
и непосредственно выполнять операции ввода-вывода. К одному
прерыванию можно присоединить несколько ISR, при этом все они
будут вызваны.
Обработчик прерываний должен вернуть управление по возможности максимально быстро, отложив длительные операции для выполнения соответствующей нитью драйвер и информировав его об
этом, например, с помощью пульса.
Если возвращенное любой из ISR значение указывает на возникновение некоторого события любого типа, то это событие будет буферизовано. После вызова всех ISR микроядро завершает работу с
программируемым контроллером прерываний и возвращает управление из прерывания. Однако возврат происходит не обязательно в
то место, где оно произошло. Если одно из буферизованных событий вызвало переход более высокоприоритетной нити в состояние
READY, то управление будет возвращено в контекст этой нити.
Описанная модель обеспечивает относительно хорошие временные характеристики обработки прерываний (interrupt latency
и scheduling latency), поскольку Neutrino запрещает прерывания
лишь на очень короткие промежутки времени, не зависящие от данных. Максимальное время задержки обработки прерывания можно
179
вычислить на основании задержки, вносимой микроядром, и суммы
суммарного времени выполнения всех ISR, назначенных для прерываний с более высоким аппаратным приоритетом. Эту сумму также
можно контролировать, поскольку Neutrino предоставляет API для
переназначения приоритетов уровней прерываний в контроллере.
Можно также свести ее к нулю, разработав систему таким образом,
чтобы на уровне ISR ничего не делалось, а вся работа происходила
бы на уровне нитей с приоритетами, назначенными разработчиком,
а не в соответствии с приоритетами аппаратных прерываний.
Наконец, помимо обычных прерываний, нить может перехватить некоторые внутренние события Neutrino и даже немаскируемые прерывания процессора (NMI). Заметим, что поскольку механизм системных вызовов основан на программных прерываниях,
работающих так же, как и аппаратные, обработка системных вызовов происходит точно так же, как и обработка прерываний – вытеснение процессов при обработке прерываний и системных вызовов
происходит одинаково быстро.
Системные функции clock(), timer(), synch() используются для
отслеживания времени суток и измерения длительности временных интервалов. С помощью этих функций Neutrino обеспечивает
возможность синхронизации часов между несколькими системами.
Приложение, запрашивающее сервис, нуждающийся в тайм-ауте,
запрашивает у микроядра автоматический запуск таймера в случае
перехода приложения в определенное состояние. Запуск таймера и
запрос сервиса в этом случае реализуются как атомарная операция,
исключающая неоднозначность.
§8. Инструментальная среда
QNX Momentics
QNX6 имеет в своем составе компонент Photon, предназначенный для обеспечения графического интерфейса (Graphic User
Interface – GUI). Его реализация базируется на механизме обмена сообщениями. Этот интерфейс ориентирован на использование
оконных интерфейсов Windows и Unix, с которыми он связывается
посредством использования удаленного пользовательского интерфейса (Remote User Interface – RUI). Разработка этой оболочки велась одновременно с разработкой Neutrino.
В настоящее время для разработки c Neutrino начинает использоваться IDE QNX Momentics. Программно-инструментальная сре180
да QNX Momentics представляет собой унифицированную среду
для разработки многокомпонентных и разнородных систем управления. При этом идет речь как об аппаратной разнородности, так
и программном обеспечении, которое может разрабатываться на
разных языках программирования. На практике это требуется для
обеспечения возможности использования готовых аппаратных модулей и программных компонентов разных производителей.
QNX Momentics состоит из ядра Eclipse, к которому подключены
специализированные QNX-расширения. Общие принципы организации и реализации Eclipse рассмотрены в третьей главе. Реализация на базе Eclipse обеспечивает возможность использования QNX
Momentics под операционными системами Windows, Linux, Solaris,
QNX Neutrino. Важно подчеркнуть при этом, что такое построение
среды разработки не создает альтернативу стандартным средствам
QNX, а существенным образом базируется на их использовании.
Словарь терминов. В настоящее время Eclipse становится
стандартом де-факто для разработки современных программноинструментальных сред. Представляется целесообразным привести ряд определений, введенных при разработке этой платформы.
Workbench (рабочее пространство). Пользовательский интерфейс Eclipse, состоящий из перспектив, видов и редакторов, которые обеспечивают работу с используемыми ресурсами проекта.
Perspective (перспектива). Визуальный контейнер, который
определяет, какие виды и редакторы будут отображаться на рабочем пространстве.
View (вид). Один из способов представления информации на
рабочем пространстве. Например, в перспективе QNX System
Information возможно отображение нескольких возможных видов:
Информация о памяти (Memory Information), Информация о выделении памяти ( Malloc Information) и т. д.
Editor (редактор). Визуальный компонент рабочего пространства, обеспечивающий возможность поиска, чтения и редактирования используемых ресурсов, представляемых в виде файлов. Разные файлы требуют использования разных редакторов, и их может
быть несколько.
Navigator (навигатор). Один из главных видов рабочего пространства, отображающий иерархическую структуру доступных
для использования ресурсов.
Profiler (монитор). Перспектива QNX с видом Profiler, который позволяет получать отображения текущего состояния выполняемого процесса для выявления его особенностей.
181
Outline (выводимая информация). Вид, показывающий иерархию функций и оглавлений (headers) исходных С-файлов.
Ниже приведено краткое рассмотрение базовых компонентов
этой среды, используемых при отладке и тестировании разрабатываемого программного обеспечения.
Символьный отладчик. Одним из основных инструментов разработчика является символьный отладчик. Один из вариантов реализации оконного интерфейса изображен на рис. 4.6.
Символьный отладчик Momentics позволяет:
одновременно отлаживать несколько приложений, написанных
на C, C++ и/или Java;
отлаживать многопоточные приложения, контролируя каждый
поток по отдельности и отслеживая передачу управления между
ними;
отлаживать несколько процессов, выполняющихся одновременно на микропроцессорах с различными архитектурами;
динамически подключаться отладчиком к любому выполняющемуся процессу;
проводить анализ дамп-файлов при аварийном завершении отладочного теста.
Символьный отладчик позволяет отлаживать программное обеспечение в пошаговом режиме или с выбором нескольких типов точек остановки:
условная – точка остановки в соответствии с описанием в виде
выражения;
счетная – остановка по заданному числу итераций;
выполнение до курсора – выполнение до указанной точки. В точках остановки возможен просмотр значений регистров, содержания
стэка и редактирования содержания ОЗУ в пределах рассматриваемого процесса.
Монитор и навигатор. Связь с аппаратным компонентом разрабатываемой системы обеспечивают такие компоненты инструментальной среды, как монитор и навигатор целевых систем. Монитор целевых систем предоставляет информацию о системах и
процессах. Этот инструментарий используется совместно с навигатором целевых систем. Навигатор позволяет разработчику привязывать проекты к IP-адресам аппаратных модулей или именам
хостов, однозначно определяя текущую программно-аппаратную
конфигурацию целевой системы. Эта информация используется
IDE для получения информацию о текущем списке процессов, выполняемых на конкретном аппаратном модуле.
182
183
¨ÉÇÊÅÇËÉÀƹоÆÁÂ
ȾɾžÆÆÔÎ
¨¾É¾Îǽ»Ä׺Ì×
ËÇÐÃÌÁÊÎǽÆǼÇ
˾ÃÊ˹
¨ÉÇÊÅÇËÉ
ÀƹоÆÁÂ
ȾɾžÆÆÔÎ
Êǽ¾É¿ÁÅǼǧ ¬
ÊËÖù
Рис. 4.6. Вариант оконного интерфейса для символьного отладчика
©¾½¹ÃËÁÉÇ»¹ÆÁ¾
ÁÊÎǽÆǼÇ˾ÃÊ˹
ÁÀÇËĹ½ÐÁùÁ
À¹½¹ÆÁ¾ËÇÐÃÁ
ÇÊ˹ÆÇ»¹p½Ç
ÃÌÉÊÇɹq
©¾¿ÁÅp%FCVHq
§ËÊľ¿Á»¹ÆÁ¾
ÈÇËÇÃÇ»Á
Ⱦɾ½¹ÐÁÌÈɹ»Ä¾
ÆÁØž¿½ÌÆÁÅÁ
184
§ÃÉÌ¿¾ÆÁ¾
ÈÉÇϾÊʹ
›ÁÀ̹ÄÕÆǾ
ÇËǺɹ¿¾ÆÁ¾
»À¹ÁÅÆÔÎ
ºÄÇÃÁÉÇ»ÇÃ
™ËÉÁºÌËÔÈÇËÇÃÇ»
ÊÇÊËÇØÆÁ¾
ÈÉÁÇÉÁ˾Ë
ÊËÖÃÁËÈ
Рис. 4.7. Вариант оконного интерфейса монитора целевых систем
ÁƹÅÁù
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
ÈÉÇϾÊÊÇÅ
ȹÅØËÁÁɾÊÌÉÊÇ»
ªÁÊ˾ÅƹØ
ÁÆÍÇÉŹÏÁØ
В процессе отладки IDE с помощью навигатора взаимодействует
с конкретными процессами, добавляя свои собственные операции к
выбранным процессам. Например, посылка процессу сигнала, подключение монитора целевых систем к выполняющемуся процессу
или организация командно-строковой сессии с конкретным аппаратным модулем.
Монитор целевых систем позволяет в режиме исполнения программного кода отследить использование ресурсов конкретными
процессами и потоками. Например, проконтролировать расход памяти и ресурсов процессора как для всей системы в целом, так и
для каждого процесса в отдельности. Монитор позволяет отслеживать ряд атрибутов потока, таких как его текущее состояние, дисциплина планирования, использование процессора, размер стека,
состояния сигналов, карты памяти программы, файловые дескрипторы и т. д. С помощью монитора можно выявлять потенциальные
ситуации взаимных блокировок, просматривая графическую диаграмму отношений блокирования.
Оконный интерфейс монитора целевых систем приведен на
рис. 4.7.
Разработка программного обеспечения для систем управления
обладает рядом существенных отличий по сравнению с разработкой программного обеспечения для чисто информационных систем. Возможность отслеживания динамики поведения каналов
управления при отладке программного обеспечения – опция, которая существенно повышает производительность разработчиков
и качество программного кода. При этом следует подчеркнуть, что
использование описанных выше возможностей по отладке может
выполняться лишь с инструментальной версией ядра.
Разработка полномасштабной системы управления невозможна
без ее тестирования в составе конечного изделия. В силу этого, необходимым этапом разработки является работа с макетами устройств
и реальными сигналами. В этом должна использоваться стандартная версия ядра, и соответственно, тестироваться будет несколько
другая система.
В этом случае процесс отладки требует использования специализированных аппаратных средств, обеспечивающих съем, обработку
и отображение текущего состояния регистров микропроцессоров в
процессе выполнения тестовых задач и конечных версий программного обеспечения. Важно, чтобы целевое программное обеспечение
предусматривало соответствующие возможности, которые должны
закладываться на этапе разработки спецификаций.
185
4.2. Интегрированная среда разработки IDE MPLAB
Фирма Microchip является одним из ведущих производителей
микроконтроллеров для встраиваемых применений. Разработанная ей микроконтроллерная платформа имеет обобщенное название PICmicro. Платформа берет начало с семейства 8-битных
микроконтроллеров PIC5XXX (Peripheral Interface Controller),
предназначенных для малогабаритных периферийных устройств
[2, 3]. В настоящее время эта платформа включает в себя семейства
8-16-32-битных микроконтроллеров и сигнальных процессоров семейства dsPIC.
Платформа обеспечивает возможность разработки устройств
нижнего уровня систем управления: интеллектуальных датчиков и исполнительных устройств, средств обеспечения человекомашинного интерфейса, малогабаритных коммуникационных
узлов для последовательных шин, автономных встраиваемых малогабаритных многоканальных систем управления и т. п. Несмотря
на существенное увеличение объемов памяти программ и данных
в старших семействах ресурсов их недостаточно для реализации
полномасштабной ОСРВ. Предельным уровнем технологии разработки программного обеспечения для систем управления на базе
этой платформы является mОСРВ.
IDE MPLAB представляет собой аппаратно-программную инструментальную среду поддержки разработок полного цикла, реализуемых на базе платформы PICmicro.
§1. Общие сведения
Среда MPLAB унифицирована и обеспечивает разработку с использованием всех семейств микроконтроллеров, сигнальных процессоров и чипов памяти фирмы Microchip. Суммарное число разновидностей поддерживаемых чипов в 2011 году превышала 800.
Эта свободно распространяемая среда обеспечивает возможность
работы с несколькими типами программаторов и внутрисхемных
эмуляторов и работает под операционными средами Windows. В настоящее время выпущена версия под Mac OS и Linux.
Для отладки прикладного программного обеспечения в составе
готового изделия или его макета используются специализированные аппаратные средства, называемыми внутрисхемными эмуляторами. Эти устройства работают под управлением специализиро186
ванного программного обеспечения, устанавливаемого на персональный компьютер разработчика. По сути дела, такая конфигурация выполняет функции специализированного программно управляемого многоканального цифрового осциллографа.
За время развития платформы было разработано несколько поколений внутрисхемных эмуляторов и программаторов. Каждое
из этих устройств требует своего инструментального программного обеспечения, и все они являются частью IDE MPLAB. Эта среда
включает в себя все программные компоненты, необходимые для
реализации полномасштабного цикла разработки и обеспечивает
возможности комфортной работы с ними.
Следует отметить, что эта среда является одной из самых динамичных с точки зрения ее непрерывного обновления, которое нужно для разработки новых типов и семейств микроконтроллеров и
сигнальных процессоров этой фирмы. Она успешно вбирает в себя
все новшества технологий разработки программного обеспечения.
С другой стороны, структура этой IDE остается неизменной уже
второй десяток лет, что и определило интерес к ней и ракурс рассмотрения.
§2. Менеджер проектов
Настройка параметров инструментальной среды под решение
конкретных задач осуществляется с помощью менеджера проектов.
Менеджер проектов обеспечивает возможность настройки среды
MPLAB на использование конкретных типов аппаратного обеспечения рабочего места, микроконтроллера, настройки параметров
пользовательского интерфейса и в процессе отладки обеспечивает
работу со всеми файлами, содержащими описание разрабатываемого кода.
Структура информационных связей, которую обеспечивает менеджер проектов MPLAB, приведена на рис. 4.8.
Для написания алгоритмов с помощью выбранного способа используется специализированный текстовый редактор. Этот редактор обеспечивает ряд функций по предварительному анализу
синтаксиса. Возможно структурирование исходного текста путем
раскраски. Отдельные программные единицы могут обрабатываться с применением индивидуальных параметров. Эта возможность
обеспечивается менеджером проектов. Для расстановки точек остановки также используется редактор текстов.
187
­¹ÂÄÔÁÊÎǽÆÔÎ
˾ÃÊËÇ»
TPVSDFGJMFT
¦¹ÊËɹÁ»¹¾ÅÔ¾
ȹɹžËÉÔ
™ÊʾźľÉ
BTTFNCMFS
£ÇÅÈÁÄØËÇÉ
DPNQJMFS
šÁºÄÁÇ˾ÃÁǺӾÃËÆÔÎÃǽǻ
PCKFDUGJMFMJCSBSJFT
¨¹É¹Å¾ËÉÔʺÇÉÃÁ
MJOLFSTDSJQU
ªºÇÉÒÁÃÃǽ¹MJOLFS
­¹ÂÄÇËĹ½ÇÐÆǼÇÃǽ¹
EFCVHGJMF
­¹ÂÄÁÊÈÇÄÆؾÅǼÇÃǽ¹
FYFDVUBCMFGJMF
Рис. 4.8. Структура информационных связей при генерации кода
§3. Сборщик кода (linker)
Современные технологии разработки программного обеспечения подразумевают широкое использование библиотек компонентов как собственных, так и заимствованных. В современных версиях MPLAB появился такой компонент, как сборщик кода (linker).
Сборщик кода работает с объектными кодами и позволяет разместить эти компоненты по разным начальным адресам памяти программ и организации их связи (linking) в единый программный
код. Эта связь обеспечивается путем соответствующей модификации адресов собираемых программных компонентов c учетом начального адреса размещения.
Сборщик генерирует программные коды в виде исполняемого и
отладочного файлов, а также ряд файлов описаний, используемых
в процессе отладки программного обеспечения. Описание этих файлов приведено на рис. 4.9.
Файл отладочного кода обеспечивает возможность установления однозначного соответствия конкретной команды конкретному
188
QSPHBTN
­¹ÂÄÔ
ÁÊÎǽÆÔÎ
˾ÃÊËÇ»
NBJOD
¹ÊʾźľÉ
.1"4.
.1-"#
$
NBJOP
QSPHP
QSFDPNQP
ºÁºÄÁÇ˾ùÉÕ
.1-*#
­¹ÂÄÔ
ǺӾÃËÆÔÎ
Ãǽǻ
­¹ÂÄ
ÇÈÁʹÆÁØ
ʺÇÉÃÁ
ªºÇÉÒÁÃ
.1-*/,
NBUIMJC
EFWJDFMLS
­¹ÂÄÔ
ÇÈÁʹÆÁØ
ÈÉǼɹÅÅÆǼÇ
Ãǽ¹
QSPHDPG
QSPHDPE
QSPHIFY
QSPHMTU
QSPHNBQ
Рис. 4.9. Структура информационного обмена в IDE MPLAB
для старших семейств микроконтроллеров Microchip
оператору в исходном тексте. Это необходимо для реализации режимов отладки с заданными точками остановки.
§4. Языковые средства
Среда IDE MPLAB обеспечивает возможность разработки программ для нескольких семейств RISC-микроконтроллеров и сигнальных процессоров. Соответственно, в состав средств разработки
входят несколько типов ассемблеров, каждый из которых реализует свой набор команд. Выбор конкретного типа ассемблера осуществляется автоматически при задании наименования используемого
микроконтроллера.
Попытки использовать язык С для описания алгоритмов предпринимались фирмой Microchip с момента начала работ над собственной микроконтроллерной платформой. Однако в силу целого ряда причин в качестве рабочего инструмента этот язык стал
широко использоваться, начиная с микроконтроллеров семейства
189
PIC18. Тем не менее благотворное влияние языка С сказалось на ассемблере MPASM, который позаимствовал аппарат директив препроцессора #define и #include, цикл обработки исходного текста,
аппарат текстовых макросов и т. п.
Использование этих заимствований позволило существенно
улучшить читаемость ассемблерного текста кодов за счет его структуризации и возможностей легкой модификации в процессе разработки. В качестве показательного примера рассмотрим детальнее
использование механизма макросов.
Макрокоманды. Макрокоманда представляет собой специальную языковую конструкцию ассемблера MPASM, называемую макросом. Макрос, по сути, является тестовыми подпрограммами.
Структура макроса описывается следующим образом:
Имя макроса МАСRO [PAR_0,PAR_1,…. PAR_k]
LOCAL INTERNAL_PAR_0, ……, INTERNAL_PAR_k
[ тело макроса ]
ENDM
и в общем случае включает в себя три строки с заданной структурой. Функциональные возможности макроса описывают операторы тела макроса. Первая строка содержит имя макроса, ключевое
слово MACRO и набор параметров макроса. Имя макроса представляет собой набор символов, обеспечивающий его идентификацию.
Набор параметров представляет список символьных параметров
макроса: PAR_0..PAR_k
Возможно использование макросов без параметров. Тело макроса представляет собой последовательность операторов конкретного ассемблера. Завершается макрос ключевым словом ENDM. Для
описания внутренних переменных макроса используется еще одно
ключевое слово LOCAL, за которым следует список внутренних
параметров INTERNAL_PAR_0 …… INTERNAL_PAR_k. Наличие
этой строки является опциональным. При написании тела макроса
возможно использование как символьных имен переменных разрабатываемой ассемблерной программы, символьных параметров
макроса и внутренних параметров.
Для использования макроса пишется его имя и, если это требуется, список фактических параметров, представляющий собой
символьные имена регистров или конкретные числовые значения.
При обработке исходного текста препроцессором на место имени
используемого макроса вставляется тело макроса с заменой символьных параметров именами из списка фактических параметров.
190
Зона действий имен локальных переменных, если они используются, ограничена конкретным макросом.
При написании тела макросов возможно использование других
макросов. Следует подчеркнуть, что аппарат макросов не дает возможность экономить память программ, как это обеспечивает использование подпрограмм, а лишь существенно повышает качество
программного продукта за счет существенного улучшения читаемости исходных текстов.
На практике оказывается полезным использовать симбиоз этих
двух возможностей. Подпрограммы предназначены для экономии
памяти программ за счет использования одного и того же фрагмента
кода путем вызова его из разных мест основной программы. Вызов
осуществляется использованием команды ассемблера CALL имя_
подпрограммы. По этой команде осуществляется передача управления на адрес, по которому расположено тело подпрограммы.
При необходимости вызова подпрограммы из разных мест основной подпрограммы оказывается удобным вызывать эту подпрограмму из тела обслуживающего макроса. При этом макрос перед
вызовом подпрограммы обеспечивает засылку передаваемых ему
параметров по адресам, которые обрабатываются подпрограммой.
Соответственно, в случае надобности аналогичным образом организуется пересылка результатов.
Высокоуровневые языки. Существует ряд общих тенденций,
характерных для технологии разработки программного обеспечения встраиваемого класса. Одна из них заключается в широком
использовании языка С, который уже стал стандартом де-факто.
Платформа PIСmicro обеспечивает возможность написания программ на языке С для семейств PIC18, PIC24, PIC32 и dsPIC.
Следует подчеркнуть, что особенность использования
С-компиляторов применительно к микроконтроллерам заключается в необходимости выполнения жестких ограничений по объему
доступной памяти данных и программ. Это предопределяет необходимость использования компиляторов оптимизирующего типа.
Практически все С-компиляторы обеспечивает возможность использования ассемблерных вставок в тело С-программы.
§5. mОСРВ-технологии разработки
С одной стороны, непрерывное наращивание возможностей микроконтроллеров этой платформы делает недостаточным исполь191
зование одной лишь компонентной технологии разработки прикладного программного обеспечения. С другой стороны, жесткие
ограничения на объемы памяти программ и данных не дают возможности реализовать платформу с универсальной mОСРВ даже с
микроядерной структурой.
Особенности разработки прикладного программного обеспечения с использованием технологии mОСРВ применительно к микроконтроллерам этой платформы детально рассматривались в литературе [2]. За время, истекшее с момента выхода указанной монографии, существенно расширились возможности микроконтроллеров этой платформы, что существенно расширяет возможности
применение данной технологии.
Речь идет об использовании универсальных программных решений в рамках одного класса приборов, реализуемых на микроконтроллерах одного семейства. Технология разработки с использованием mОСРВ в этом случае подразумевает использование стандартизованной в рамках компании структуры прикладного программного обеспечения, поддерживаемой внутрифирменными библиотеками компонентов. Системными компонентами при таком подходе
должны реализовываться диспетчеры очереди задач, диспетчеры
прерываний, системные таймеры и драйвера периферийных модулей выбранного семейства. Набор этих функций существенным образом зависит от семейства микроконтроллеров.
Если для 8-битных микроконтроллеров младших семейств доминирующей является технология компонентной разработки, то
для семейств PIC18XXX и старше началось широкое внедрение
mОСРВ-технологий.
Для использования с 16-битными контроллерами компания Microchip рекомендует микрооперационные системы, разработанные компанией CMX_SYSTEM. Предлагается три различных
варианта: CMX-RTX, СMX-Tiny, CMX-Scheduler.
CMX-RTX. Использует вытесняющую многозадачность и обеспечивает возможность управления задачами, событиями, системными таймерами, ресурсами задач, распределением памяти. Сервисы:
семафоры, сообщения, очереди сообщений. Все функции RTOS требуют наличия 3,6 Кбайт памяти программ. Каждая задача требует
28 байт ОЗУ для хранения сервисной информации.
СMX-Tiny. Представляет собой упрощенную версию с вытесняющей многозадачностью. Требует 2,3 Кбайта памяти программ.
Каждая задача требует 13 байт памяти данных для хранения сервисной информации.
192
CMX-scheduler. Это свободно распространяемый системный компонент, представляющий собой ядро с диспетчером, реализующим
диспетчеризацию с вытесняющей многозадачностью для пяти задач. Ядро совместимо с системами CMX-RTX и CMX-Tiny и может
использоваться для простых, требовательных к ресурсам систем.
Ядро CMX-Scheduler требует наличия 0,9 Кбайт памяти программ.
Каждая задача требует 11 байт памяти данных для хранения сервисной информации.
Кроме RTOS компании CMX System можно упомянуть о mОСРВ
AVIX, uC/OS-II, которые ориентированы на использование в микроконтроллерах компании Microchip.
AVIX. Эта микрооперационная система специально разработана
для микроконтроллеров семейств PIC24, dsPIC и PIC32. Предлагает стандартный набор сервисов для обслуживания нитей: мьютексы (mutex), семафоры, сообщения, пайпы (pipe) и таймера.
При разработке уделено значительное внимание надежности обработки прерываний. Для этого в этой системе запрет прерывания
не может быть осуществлен до тех пор, пока нить не получит связи
с нужным обработчиком прерываний.
Имеет в качестве системной функции трассировщик активности
нити (Real Time Thread Activation Tracing), обеспечивающий возможность разработчику отслеживать поведение нити в процессе
выполнения тестовых задач, используемых при разработке.
uC/OS-II. Представляет собой вариант универсальной mОСРВ
компании Micrium, адаптированный для микроконтроллеров
Microchip. Использует вытесняющую многозадачность, поддерживает семафоры, сообщения, очереди сообщений, управление системными таймерами. Максимальное число задач –256.
Модификаторы. Есть еще один круг задач, которые требуют разработки внутрифирменных стандартов на структуру и способы реализации их системными компонентами, который проходит мимо внимания разработчиков стандартно поставляемых
компонентов. Как показывает практика, поддержка изделий на
протяжении жизненного цикла требует персонификации, инициализации и модификации программного обеспечения готовых
изделий.
Под персонификацией подразумевается процесс внесения информации о серийном номере изделия, версии используемого программного обеспечения и т. д. При этом надо понимать, что на этапе
производства изделие передается от программиста-разработчика к
программисту, обеспечивающему сопровождение изделия в про193
цессе разработки. Инициализация изделия в чем-то родственна
персонификации, но, как правило, относится к кругу вопросов с
настройкой параметров системы. Например, задание калибровочных констант, инициализация счетчиков, системных таймеров
часов глобального времени и т. п. Круг вопросов, связанных с этой
проблематикой, рассмотрен в литературе [2, 4].
Модификация программного обеспечения изделий требует наличия режимов обновления версий программного обеспечения и
проведения возможностей его автономного тестирования в составе
системы.
4.3. Стандарт OSEK/VDX
Стандарт OSEK/VDX представляет собой совместный проект
ряда крупных европейских автомобильных компаний. Основной
мотивацией совместной работы явились результаты анализа затрат
на разработку систем управления современным автомобилем, из
которых следовала возможность уменьшения затрат на разработку
систем управления. Этот стандарт изначально ориентирован на распределенные системы управления и содержит целый ряд радикальных нововведений по сравнению с традиционными технологиями
разработки программного обеспечения.
В дальнейшем изложении для обозначения этого стандарта будет использоваться наименование OSEK.
§1. Общая характеристика
Целью проекта OSEK являлось создания платформы для разработки распределенных систем управления на базе микроконтроллеров, ориентированных на использование в автомобилях. Для
достижения поставленной цели платформа должна обеспечивать
возможность разработки программного обеспечения обладающего
свойствами:
переносимости (portability);
масштабируемости (scalability);
возможности повторного использования (reusability).
Особенностью автомобильных микроконтроллерных сетей является существенная неоднородность используемой элементной
базы. Это приводит к тому, что в рамках одной системы, как пра194
вило, используются микроконтроллеры разных производителей с
разными архитектурными решениями как по разрядности (4-32битные), так и по системе команд (RISC-MISC) и, соответственно,
разной организации ядра. Разнородность, в конечном счете, и является причиной высокой стоимости разработки, так как требует
большого количества времени на стыковку концептуально разных
платформенных решений.
Использование универсальных решений применительно к аппаратной составляющей, с одной стороны, нереально из-за габаритных ограничений нижнего уровня системы, а с другой стороны,
неминуемо приводит к росту стоимости конечного изделия. Универсальность по программной составляющей требует существенных ресурсов для своей реализации: память программ и память
данных.
Соответственно, перед разработчиками проекта OSEK стояла задача создать платформу поддержки разработки, обеспечивающую
возможность создания универсальных настолько, насколько это
будет возможно, решений, реализуемых на микроконтроллерах
разных производителей. При этом в качестве базовой точки в пространстве параметров были приняты память программ около 1–10
Кб и память данных около 1 Кб. При этом необходимым условием
являлось требования обеспечить возможность разработки сетевых
решений, учитывающих специфику автомобильных применений.
В силу этих ограничений OSEK строится на основе:
гибкой архитектуры платформы, обеспечивающей возможность
ее адаптации к условиям конкретной разработки как по программному, так и по аппаратному компоненту;
спецификации пользовательских интерфейсов, независимых от
особенностей аппаратных и сетевых реализаций;
спецификаций на интерфейсы, которые должны быть по возможности максимально абстрагированы от деталей конкретного
проекта в части операционной системы реального времени, сетевых
коммуникаций и управления сетью.
Так как основной целью являлось сдерживание роста расходов
на разработку и стоимости конечных изделий при увеличении
функциональных возможностей сети, то в концепцию платформы
вошел ряд требований по технологичности, учитывающих особенности цикла разработки программных кодов и их поддержки на
стадии эксплуатации.
Концепция OSEK может быть сформулирована в сжатом виде
как обеспечение максимально возможного универсализма и техно195
логичности при заданных ограничениях на ресурсы за счет адаптации к специфике конкретного применения.
§2. Структура системы стандартов OSEK
Реализация этих концептуальных требований привела разработчиков к необходимости применения ряда новых решений, существенно выходящих за рамки сложившейся практики применения
технологии ОСРВ.
Из-за ограничений по ресурсам на реализацию в OSEK используются статические атрибуты для задач и mОСРВ. При этом подходе
конфигурация ядра mОСРВ, набор задач и требуемые для их реализации ресурсы определяются на стадии разработки. Для описания
выбранных параметров используются специальные средства в виде
внутриплатформенных языков описания.
Стандарт OSEK представляет собой взаимоувязанный набор
спецификаций:
OSEK OS operating system;
OSEK Time time triggered operating system;
OSEK COM communication services;
OSEK FTCOM fault tolerant communication;
OSEK NM network management;
OSEK OIL implementation Language;
OSEK ORTI kernel awareness for debuggers.
Сами названия спецификаций отражают ряд инновационных
решений проекта. Так, платформа OSEK обеспечивает возможность использования в одной системе узлов, реализованных на
двух возможных типах mОСРВ: OSEK OS и OSEKTime. Микрооперационные системы являются конфигурируемыми. Конфигурация
ядер mОСРВ описывается на этапе разработки с использованием
специализированного языка OIL.
При этом имеется возможность использования разных типов сетевых компонентов платформы OSEK COM и OSEK FTCOM. Применение OSEK FTCOM по замыслу разработчиков должно обеспечить
отказоустойчивость системы и используется совместно с mОСРВ
OSEKtime.
Реализация концепции потребовала нестандартного подхода к
использованию стандартной семиуровневой OSI применительно к
обменам между узлами и обменами внутри узла. Кроме этого, эта
модель дополнена компонентом управления и мониторинга сети
196
197
04&,$0.
ª¾Ë¾»ÇÂ"1*
¨ÉÁÄÇ¿¾ÆÁ¾"QQMJDBUJPO
™Ä¼ÇÉÁËÅÔ
ÈÉÇËÇÃÇĹ
04&,
¹Ä¼ÇÉÁËÅÔ
04&,/8
¬Èɹ»Ä¾ÆÁ¾Ê¾ËÕ×
/FUXPSL.BOBHFNFOU
Рис. 4.10. Базовые компоненты OSEK OS
™ÈȹɹËƹØɾ¹ÄÁÀ¹ÏÁØÑÁÆÔ
#VTDPNNVOJDBUJPOIBSEXBSF
É¹Â»¾É¹Ê¾Ë¾»ÔÎÅǽÌľÂ
#VT*0ESJWFS
¬ÉÇ»¾ÆÕǺžƹ½¹ÆÆÔÅÁ
%BUBMJOLMBZFS
ª¾Ë¾»ÇÂÌÉÇ»¾ÆÕ
/FUXPSLMBZFS
¬ÉÇ»¾ÆÕ»À¹ÁÅǽ¾ÂÊË»ÁØ
*OUFSBDUJPOMBZFS
£ÇÅÅÌÆÁùÏÁÇÆÆÔÂ"1*
04&,04
­ÁÀÁоÊÃÁÂ
£¹Æ¹ÄÕÆÔÂ
»¾Æ¹
½¹ÆÆÔÎ
ªž«ž›§¢
ª¾ÊÊÁÁ
¨É¾½Ê˹»Ä¾ÆÁØ
¨ÉÁÄÇ¿¾ÆÁØ
¬ÉÇ»ÆÁ04*Åǽ¾ÄÁ
198
¨ÉÁÄÇ¿¾ÆÁ¾
ªÃǽ
É¹Â»¾É¹ÌÊËÉÇÂÊË»
ª"4.Ãǽ
¡ÆÊËÉÌžÆ˹ÉÁÂ
%*-$POGJH5PPM
±¹ºÄÇÆÔ
½É¹Â»¾ÉÇ»
ÌÊËÉÇÂÊË»
035*ÇÈÁʹÆÁ¾
,0*-
§ÈÁʹÆÁ¾
ÃÇÆÍÁ¼ÌɹÏÁÁ
N§ª©›
§ºÓ¾ÃËÆÔÂÃǽ
YYYYP
Рис. 4.11. Структура цикла разработки OSEK
£ÇÅÈÁÄØËÇÉÔ
ª"4.
£ÇÆÍÁ¼ÌɹÏÁÇÆÆÔÂ
ªÃǽ½ÄØN§ª©›
¡ÆÊËÉÌžÆ˹ÉÁÂ
0*-$POGJH5PPM
§ÈÁʹÆÁ¾
ÃÇÆÍÁ¼ÌɹÏÁÁ
½É¹Â»¾ÉÇ»
šÁºÄÁÇ˾ù
ÃÇÅÈÇƾÆË
N§ª©›YYYB
ªºÇÉÒÁÃ
-JOLFS
¨ÉǼɹÅÅÆÔÂÃǽ
CJOBSZJNBHF
YYYYFMG
§ËĹ½ÐÁÃ
%FCVHHFS
OSEK NM. Взаимосвязь базовых компонентов OSEK для варианта
mОСРВ OSEK OS показана на рис. 4.10.
Для поддержки технологического цикла разработки имеется
возможность специального конфигурирования системы под работу в режимах: отладки, диагностики, эксплуатации. Для этого используется специализированный язык OSEK ORTI.
Цикл разработки программного обеспечения на этой платформе
показан на рис. 4.11.
§3. Операционная система OSEK OS
Архитектура OSEK ОС включает три уровня: уровень прерываний, системный уровень и уровень задач. Уровень прерываний
имеет больший приоритет, чем уровень задач. Системный уровень
обеспечивает управление сетевыми возможностями, управление
задачами, событиями, ресурсами, а также обработку счетчика,
ошибок и т. п.
Объектами, с которыми оперирует OC OSEK, являются задачи,
прерывания, события и ресурсы. При этом «задача» и «прерывание» относят к так называемому классу сущностей.
Задача OSEK. Задача находится в одном из четырех состояний:
готова к выполнению, выполняется, ожидает, приостановлена.
Задача, которая готова к выполнению, нуждается в выделении
ей ресурса ядра процессора и находится в очереди задач. Ресурс
на обработку выделяется ей с учетом приоритета задачи и правил
вытеснения. При выделении ресурса ее статус меняется, и она становится выполняемой задачей. При выполнении задачи ей могут
потребоваться результаты работы периферийных модулей или других задач, которые на момент выполнения отсутствуют.
В этой ситуации задача освобождает ядро процессора для других
задач и переходит в режим ожидания. Кроме этого задача может
быть приостановлена, т. е. она находится в пассивном состоянии и
ожидает активацию.
Выделение ресурсов ядра для выполнения задачи осуществляет
диспетчер задач. При этом разработчик может задать описание задачи, определяющее ее свойства для диспетчера. Соответственно,
задачи могут быть допускающими свое вытеснение в любой момент
(full preemptive scheduling) или не допускающие реализации диспетчеризации с вытесняющей многозадачностью (on preemptive
scheduling).
199
Синхронизация выполнения различных задач осуществляется с
помощью атрибута задачи, называемого «событие». Событие – это
состояние соответствующего регистра, приписанного задаче, которая называется собственником события. Только собственник события может изменить его состояние
Прерывания OSEK. В OSEK реализована двухуровневая система обработки прерываний, которые различаются возможностями
вызова системных сервисов. Первый уровень прерывания не использует вызовы системных функций. Это позволяет иметь минимальное время реакции системы управления на ряд прерываний.
Второй уровень обеспечивает выполнение функций приложения,
которые выполняются использованием функций операционной системы.
Обработка сбойных ситуаций. В OSEK обеспечивается возможность управления ошибками и введения пользовательских
функций, обеспечивающих мониторинг состояния системы. При
этом возникающие ошибки делятся на два класса: фатальные и
ошибки приложения. К классу фатальных ошибок относится нарушение целостности внутренних данных. Эта ошибка приводит к
вызову системной функции завершения работы ОС. Ошибки приложения возникают при попытке приложения выполнить несанкционированную операцию.
§4. Коммуникационная подсистема OSEK COM
Распределенная система управления по определению требует
информационного обмена между задачами, выполняемыми на разных узлах. Подсистема OSEK COM – одно из двух возможных решений стандарта OSEK для обеспечения межзадачного информационного обмена. Эта подсистема базируется на сообщениях, которыми
обмениваются приложения.
Модель описания уровней. В стандарте OSEK использует собственную модель описания уровней, которая состоит из уровней
приложения, взаимодействия (Interaction Layer – IL), сетевого
уровня и уровня звена данных.
Их соотношение со стандартной OSI-моделью описывает
рис. 4.12. Рисунок дает представление о ряде новшеств, которые
привнесли разработчики стандарта OSEK в многоуровневую модель путем введения уровня взаимодействия. Уровень взаимодействия обеспечивает обслуживание операций по посылке и приему
200
ªÇǺҾÆÁØÈÉÁÄÇ¿¾ÆÁØ
4FOE.FTTBHF
¬ÉÇ»¾ÆÕ
ÈÉÁÄÇ¿¾ÆÁØ
3FDFJWF.FTTBHF
§ºÓ¾ÃË
.&44"(&
›ÆÌËɾÆÆÁ¾
ÊÇǺҾÆÁØ
›ÆÌËɾÆÆÁ¾
Á»Æ¾ÑÆÁ¾
ÊÇǺҾÆÁØ
¨¾É¾½¹Ð¹
ÊÇǺҾÆÁØ
›Æ¾ÑÆÁ¾
ÊÇǺҾÆÁØ
¬ÉÇ»¾ÆÕ
»À¹ÁÅǽ¾ÂÊË»ÁØ
¡À»Ä¾Ð¾ÆÁ¾
ÊÇǺҾÆÁØ
*1%6
¹ÈÉÇÊ
ƹȾɾ½¹ÐÌ
¡Æ½ÁùÏÁØ
ÈÉÁ¾Å¹
¦Á¿ÆÁ¾
ÌÉÇ»ÆÁ
ÈÉÇËÇÃÇĹ
Рис. 4.12. Модель уровня взаимодействия OSEK COM
сообщений как между приложениями разных узлов, так и приложениями, реализуемыми на одном узле. При этом используются
разные механизмы передачи данных.
Различаются три типа обменов сообщениями: внешние, внутренние и внешне-внутренние сообщения. Для внешних коммуникаций используются сервисы нижних уровней и механизм формирования и передачи сообщений, который в общих чертах схож с
классической семиуровневой моделью. Информационная посылка
в этом случае содержит одно или несколько сообщений, которые обрамляются служебной информацией по мере прохождения слоев, и
передается по сети.
Для внутренних коммуникаций используются сервисы уровня
взаимодействия. Для комбинированных сообщений используются
оба эти механизма.
201
Спецификация OSEK COM не регламентирует сетевой уровень
полностью, а определяет набор минимальных требований, необходимых для реализации уровня взаимодействия. Обработка сообщений на сетевом уровне зависит от используемого коммуникационного протокола и учитывает сегментацию/рекомбинацию, а также
необходимость отсылки подтверждения. Сетевой уровень использует сервисы уровня звена данных и обеспечивает возможность для
реализации механизма контроля процесса передачи данных.
Уровень звена данных обеспечивает верхние уровни сервисом
передачи сообщений по сети индивидуальных кадров данных.
Кроме этого, этот уровень используется подсистемой управления
сетью. Так же, как и для сетевого уровня, специфицируется лишь
минимальный набор требований.
Параметры и свойства сообщений конфигурируются статически
и описываются с помощью специализированного языка OIL (OSEK
Implementation Language – OIL). Содержание и использование данных, содержащихся в сообщении, не относится к OSEK COM. Разрешается, в частности, пересылка сообщений нулевой длины.
Для внутренних сообщений пересылаемые данные становятся
доступными получателю практически сразу, так как пересылка не
требует использования сетевой инфраструктуры.
Для формирования внешних сообщений используется протокол
IPDU (Interaction Layer Protocol Data Units), который обеспечивает
упаковку нескольких сообщений в одну информационную посылку. Порядок битов в посылке (старшими или младшими вперед )
может отличаться для электронных блоков от разных производителей. Соответственно, IL обеспечивает преобразование представлений. Этот слой обеспечивает также интерфейс обработки сообщений для прикладной программы (API).
Администрирование процесса пересылки сообщений осуществляется слоем IL с использованием объектов сообщений (message
objects). Они используются как на передающей стороне в виде передающего объекта (sending message object), так и на принимающей
стороне в виде принимающего объекта (receiving message object).
Процесс администрирования включает в себя операции инициализации, передачи данных и управления передачей.
Отправителями и получателями сообщений являются либо задачи, либо программы обслуживания прерываний OSEK OS. Сообщения посылаются с использованием передающих и принимающих
объектов, которые идентифицируются при генерации системы путем
их описания и задания атрибутов на языке OIL. OSEK COM поддер202
живает информационный обмен M:N с использованием статической
адресации сообщений. Сообщения могут иметь либо фиксированную
длину, определенную на этапе генерации системы, либо переменную,
которая не должна превышать заранее определенный максимум.
Внешние сообщения бывают двух типов: c триггерным режимом передачи и с отложенным. Используемый режим передачи
специфицируется заданием соответствующих атрибутов сообщения. В триггерном режиме передачи обновление содержания I-PDU
приводит к генерации запроса на передачу. В отложенном режиме
обновление содержания не приводит к автоматической генерации
запроса на передачу.
Режимы передачи сообщений. Для передачи I-PDU могут использоваться три режима: режим прямой передачи (Direct Transmission
Mode), режим периодической передачи (Periodic Transmission
Mode) и режим смешанной передачи (Mixed Transmission Mode).
В режиме прямой передачи передача инициируется явно посылкой сообщения с триггерным свойством передачи. В режиме периодической передачи сообщения передаются в циклическом режиме с
задаваемым периодом. Смешанный режим является комбинацией
режимов прямой и циклической передачи.
При этом имеется возможность использования механизма мониторинга времени передачи и приема сообщений по максимальному
времени, называемый Deadline Monitoring. Мониторинг на стороне
отправителя заключается в проверке наличия подтверждения от
нижних уровней о наличии запроса на передачу за время, не превышающее заданное. На приемной стороне для циклически отправляемых сообщений – это проверка условия получения сообщения
за специфицированный интервал времени.
Слой взаимодействия обеспечивает возможность фильтрации поступающих сообщений. На стороне отправителя фильтр может отсеивать сообщения по содержанию. В этом случае I-PDU не обновляется
и передача не осуществляется. Для внутренних сообщений фильтрация не осуществляется. На приемной стороне фильтрация может осуществляться как для внешних, так и для внутренних сообщений.
§5. Подсистема управления сетью OSEK NM
Базовые требования, предъявляемые к сетевым системам управления автомобиля:
каждый узел должен быть доступен для авторизованного доступа;
203
максимальная нечувствительность к возможным временным
сбоям узлов;
обеспечение возможности диагностики состояния узлов сети.
Основная функция подсистемы NM заключается в обеспечении
надежности и безопасности передачи сообщений между узлами сети.
Подсистема обеспечивает повышение надежности реализации алгоритмов управления за счет контроля конфигурации системы. В соответствии с этим приложение перед выполнением тех или иных действий может проверить наличие требуемых для реализации узлов в
сети за счет сервиса, предоставляемого этой подсистемой.
В соответствии со спецификациями OSEK подсистемы NM должны быть установлены на узлы сети на стадии конфигурирования.
Это в свою очередь означает, что реализация подсистем NM должна
обеспечивать их выполнение на широком спектре используемых
в автомобильной промышленности микроконтроллеров. Из этого
требования вытекает необходимость выбора и реализации универсального механизма мониторинга состояния узлов.
Функции и реализация подсистемы. Подсистема OSEK NM
обеспечивает возможность мониторинга состояния узлов сети (node
related management) и сети в целом (global management). Реализация сетевого мониторинга является опциональной. Подсистема
обеспечивает возможность реализации следующих функций:
инициализация ресурсов узлов сети для обеспечения возможности сетевого взаимодействия;
запуск и конфигурирование сети;
управление разными механизмами мониторинга узлов;
детектирование, обработка и выработка сигналов о текущем состоянии сети в целом и отдельных узлов;
чтение и изменение параметров мониторинга;
координация режимов работы узлов сети;
поддержка диагностики.
OSEK NM обеспечивает возможность использования двух альтернативных механизмов мониторинга состояния сети:
прямого мониторинга путем использования последовательно
кольцевой передачи маркера от узла к узлу;
косвенного мониторинга путем мониторинга сообщений приложений.
При прямом мониторинге подсистема NM передает и принимает
два типа сообщений, которые обеспечивают контроль узлов в модели
логического кольца сети. Модель логического кольца подразумевает
наличие, как минимум, двух адресов узлов – соседей по кольцу.
204
По логическому кольцу передается сообщение о жизнеспособности (alive message) и синхросообщение (ring message). Синхросообщение передается по кольцу от одного узла к следующему. Интерпретация этих сигналов производится в соответствии с правилами,
приведенными в табл.4.4.
Таблица 4.4
Интерпретация сообщений при прямом мониторинге
Получение сообщения о жиз- Регистрация наличия узла в сети
неспособности
Получение cинхросообщения Наличие узла предшественника в сети и
начало посылки собственного синхросообщения следующему узлу
Превышение таймаута для по- Отсутствие узла в сети
лучения синхросообщения
Таким образом, после цикла обменов мониторинговыми сигналами имеется возможность описания фактической конфигурации
сети и выявления неисправных узлов.
Наличие описания неисправных узлов позволяет на основе сравнения с требуемым для выполнения конкретной задачи набором
узлов принимать решения о возможности ее реализации. В случае
невозможности реализации задачи система мониторинга вырабатывает сигналы о неисправности.
Применение прямого мониторинга может оказаться невозможным, например, для приложений критичных по времени реализации. Для этих случаев возможно использование механизма косвенного мониторинга, который основывается на анализе факта наличия сообщений, посылаемых узлом. Соответственно, этот способ
мониторинга применим к узлам, которые в режиме нормальной
эксплуатации периодически посылают сообщения о состоянии.
Описанные механизмы реализуют принцип презумпции неисправности, предложенный в работе, который следует из вывода о невозможности самостоятельного автономного тестирования
устройства [2]. В соответствии с этим принципом контроль работоспособности устройства осуществляется внешними компонентами
системы на основании сигналов, которые вырабатывает контролируемое устройство.
Важно подчеркнуть, что мониторинг решает две важные задачи:
обеспечивает надежность системы за счет предотвращения выполнения действий, для реализации которых нет необходимых ресурсов;
205
уменьшает сроки устранения возникших неисправностей за счет
предоставления информации о неисправных узлах.
При этом реализация подсистемы мониторинга не предусматривает ведения журнала ошибок. Соответственно, восстановление работоспособности системы предполагает замену неисправного узла.
§6. Язык OSEK OIL
Язык OIL является средством описания в статическом режиме
параметров конфигурирования и выделения ресурсов микроконтроллера для реализации задач.
Описание OSEK приложения состоит из набора стандартно определяемых объектов языка OIL. Каждый такой объект определяется
специфицированным набором атрибутов и ссылок. Перечень объектов OIL приведен в табл. 4.5.
Таблица 4.5
ОБЪЕКТЫ OIL
APPMODE
Режим работы приложения. Не имеет стандартно
определяемых атрибутов
CPU
Ядро, на котором реализован узел
OS
Тип используемой операционной системы
ISR
Программы обслуживания прерываний
RESOURCE
Требуемые для реализации ресурсы
TASK
Задача, выполняемая под управлением OS
COUNTER
Программно-аппаратный источник событий для
выработки сигнала тревоги
EVENT
Событие, приписанное к задаче
ALARM
Сигнал тревоги, реализуемый на COUNTER. Может активизировать задачу, событие или специальную задачу обработки сигнала тревоги
MESSAGE
Сообщение. Определяет атрибуты механизмов обмена сообщениями, используемых разработчиком в
OSEK СOM для разных типов сущностей: TASK, ISR
и других CPU информационного взаимодействия
NETWORKMESSAGE Сетевое сообщение. Определяет специализированные атрибуты механизмов обмена сообщениями
между поставляемыми узлами
IPDU
Объект для определения свойств сообщений, используемых для внешних коммуникаций
COM
Тип коммуникационной подсистемы. Имеет
специальные атрибуты для определения общих
свойств коммуникаций
NM
Подсистема управления сетью
206
Каждый объект имеет свой собственный набор атрибутов, который должен быть определен в описании приложения. В качестве
примера рассмотрим набор атрибутов объекта ISR, определяющих
свойства обработчика прерываний:
CATEGORY – атрибут определения уровня прерываний и может
принимать значение 1 или 2;
RESOURCE – атрибут-ссылка, используемый для определения
списка ресурсов, необходимых для ISR;
MESSAGE – атрибут-ссылка, используемый для определения
списка сообщений для ISR.
Пример задания атрибутов для объекта ISR на языке OIL:
ISR TimerInterrupt {
CATEGORY = 2;
RESOURCE = someResource;
MESSAGE= anyMessage2; };
Язык OIL используется для описания конкретной реализации
OSEK. Реализация OSEK представляет собой набор атрибутов для
каждого объекта в виде его конкретных значений. При этом могут
использоваться как стандартный, так и опционально задаваемый
наборы, а также наборы, описываемые по умолчанию.
Некоторое представление об использовании языка OIL дает следующий пример.
IMPLEMENTATION SpecialOS {
OS {
ENUM [EXTENDED] STATUS;
UINT32 [1..255] NON_SUSPENDED_TASKS = 16;
...
};
TASK {
UINT32 [1.. 256] PRIORITY; // define range of standard
// attribute PRIORITY
INT32 StackSize= 16;
// stacksize in bytes for a task
...
};
ALARM {
ENUM [ACTIVATETASK {TASK_TYPE TASK;}] ACTION;
// define possible value(s)
// of standard attribute ACTION
BOOLEAN START = FALSE;
// define implementation-specific
// attribute START of type BOOLEAN
...
};
207
MESSAGE {
STRING ITEMTYPE = «»;
//define implementation-specific
// attribute ITEMTYPE of type STRING
...
};
ISR {
MESSAGE_TYPE RCV_MESSAGES[] = NO_DEFAULT;
// define implementation-specific
// attribute RCV_MESSAGES of type
// ‘multiple reference to objects
// of type MESSAGE’
...
};
};
// End IMPLEMENTATION SpecialOS
4.4. Парадигма табличной диспетчеризации
Для ряда подсистем автомобиля, обеспечивающих безопасность
водителя и пассажиров и реализуемых на базе сетевых технологий,
критически важно обеспечить отказоустойчивость.
Подчеркнем, еще раз что для систем реального времени под отказом понимается не только ошибки в обработке данных, но и превышение времен1 обработки данных по сравнению со специфицированными. Например, задержка в срабатывании системы управления подушки безопасности с большой вероятностью приведет к
неприемлимому для владельца автомобиля ущербу.
Для распределенных систем управления гарантированное время
доставки сообщений между узлами является необходимым условием для обеспечения отказоустойчивости системы управления. Кроме этого, требуется обеспечить обработку данных в узле с нужным
темпом, которая определяется mОСРВ узла.
§1. Операционная система OSEKtime
Для выполнения этих требований в стандарте OSEK для подсистем, требующих повышенной надежности, принята парадигма
1 Использование термина «времена» определяется переводом с английского термина «times» и необходимостью описания векторного характера измерения времени
в многоканальных системах управления.
208
использования табличной диспетчеризации (time-triggered) как в
канале передачи, так и для диспетчеризации задач в узлах. В системах такого типа запуск на выполнение задач осуществляется в
соответствии с таблицами диспетчеризации, описывающими моменты запуска компонентов. Данный подход обеспечивает предсказуемость времени реализации тех или иных операций и, кроме того,
обеспечивает возможность мониторинга как задач, так и узлов.
В соответствии с этим в канале передачи данных используется
протокол с временным разделением FlexRay и mОСРВ OSEKtime,
используемая совместно с подсистемой обеспечения отказоустойчивых соединений FTCom.
Архитектура OSEKtime. Архитектура программного обеспечения узла на базе OSEKtime показана на рис. 4.13. Микроопе04&,5JNF04
¨©¡¤§Ÿž¦¡ž
¬ÉÇ»¾ÆÕÇËùÀÇÌÊËÇÂÐÁ»ÔÎ
ÊǾ½ÁƾÆÁÂ
04&,5JNF'5$PN
¬ÉÇ»¾ÆÕÈÉÁÄÇ¿¾ÆÁÂ
"QQMJDBUJPO-BZFS
04&,7%9/.
ª¾É»ÁÊ
»É¾Å¾ÆÆÔÎ
ÇËÊоËÇ»
5JNF
4FSWJDF
¬ÉÇ»¾ÆÕÍÁÄÕËɹÏÁÁ
ÊÇǺҾÆÁÂ
.FTTBHF'JMUFSJOH-BZFS
¬ÉÇ»¾ÆÕÇËùÀÇÌÊËÇÂ
ÐÁ»ÇÊËÁÊÇǺҾÆÁÂ
'BVMU5PMFSBOU-BZFS
¬Èɹ»Ä¾ÆÁ¾
ʾËÕ×
/FUXPSL
.BOBHFNFOU
¬ÉÇ»¾ÆÕ»À¹ÁÅǽ¾ÂÊË»ÁØ
*OUFSBDUJPO-BZFS
$/*ESJWFS
É¹Â»¾ÉÑÁÆÔ
™ÈȹɹËƹØɾ¹ÄÁÀ¹ÏÁØÑÁÆÔ
Рис. 4.13. Структура программного обеспечения узла на базе OSEKtime
209
рационная система обеспечивает управления ресурсами микроконтроллера, генерацию временных отсчетов и диспетчеризацию
задач. Подсистема отказоустойчивых соединений обеспечивает
доставку сообщений между узлами, детектирование ошибок и отказоустойчивую доставку сообщений. Прикладные задачи и отказоустойчивая система доставки сообщений работают под управлением OSEKtime. Компонент обеспечения мониторинга сети OSEK
NM подключается опционально.
Состав mОСРВ задается разработчиком на этапе ее генерации
и не может быть изменен впоследствии. В список задаваемых при
генерации системы параметров входят и требуемые времена обслуживания в виде спецификации Time Service. Это описание предназначено для синхронизации времени выполнения задач с использованием глобального времени в процессе запуска системы и в нормальном режиме эксплуатации.
OSEKtime разграничивает задачи на две группы: компоненты
для обслуживания прерываний и компоненты приложений.
В силу принятых решений по диспетчеризации задач в OSEKtime
в целях улучшения предсказуемости поведения аппаратные модули узла обслуживаются приложениями. Платой за это является
потенциальное уменьшение количества контролируемых каналов
одним узлом при заданном времени реакции.
В распределенной системе управления возможно совместное
использование узлов, реализуемых на базе OSEK OS и OSEKtime.
Более того, возможно использование этих двух микрооперационных систем в одном узле и дополнение функций операционной системы.
§2. Задачи и tt-диспетчеризация OSEKtime
В табл. 4.6 приведено описание компонентов OSEKtime, разбитое на функциональные группы.
В соответствии с этим реализовано два уровня реализации компонентов: уровень обработки сигналов прерываний и уровень задач
с табличной диспетчеризацией (TT Task Level). Эти задачи будем
называть для краткости tt-задачи, а диспетчер, реализующий табличную диспетчеризацию, – tt-диспетчер.
В OSEKtime tt-задача представляет собой задачу (компонент),
поставленную на реализацию, блокирование выполнения которой
запрещено. Под блокированием в данном случае подразумевается
210
ожидание внешнего события, например сигнала прерывания от
модуля АЦП, на время которого запускается другая задача. При
этом запуск модуля АЦП компонент, если требуется, может осуществить самостоятельно. Ожидать внешнего события, а именно,
завершения операции аналого-цифрового преобразования, задача
может в своем внутреннем цикле, время выполнения которого не
должно превышать верхнее значение WRCT (Worst Case Execution
Time) для этой задачи. Граф описания возможных состояний задач
изображен на рис. 4.14.
Таблица 4.6
Описание сервисов OSEKtime
Функциональная группа
Набор функций
Управление задачами
Управление состоянием и переключением
задач
Диспетчеризация
Мониторинг превышения максимальных
времен
Управление прерываниями Обслуживание прерываний
Системное время и старт
Синхронизация системного времени запуска
системы
и инициализация системы
Внутренние сообщения
Обмен данными в узле
Error treatment
Механизмы обработки сообщений об ошибках
Старт задачи привязан к событию активации и для задач с временным разделением время запуска определяется по таблице диспетчера задач. Диспетчеризация с временным разделением предполагает наличие таблицы описания времен запуска задач (компонент), которая формируется на этапе генерации системы. Запуск
задач осуществляется циклически. После запуска задачи, описан-
›Ô˾ÊƾÆÁ¾
QSFFNQU
»Ô˾ÊƾÆƹØ
QSFFNQUFE
ÁÊÈÇÄÆؾŹØ
SVOOJOH
›ÇÊÊ˹ÆǻľÆÁ¾ ™ÃËÁ»¹ÏÁØ
BDUJWBUF
SFTVNF
À¹»¾ÉѾÆÁ¾
UFSNJOBUF
À¹»¾ÉѾÆƹØ
TVTQFOEFE
Рис. 4.14. Граф состояния tt-задач
211
ной в последней строчке этой таблицы, диспетчер начинает с первой строчки этой таблицы.
Времена запуска задач измеряются в tic-ах системного таймера.
При наличии в системе единого системного таймера возможно использование так называемого глобального времени (global time).
При каждом прерывании от системного таймера производится
проверка таблицы диспетчера на предмет выполнения условия запуска задачи. Атрибуты tt-задач не включают приоритетов, и ttдиспетчер запускает очередную задачу, если ее момент запуска наступил. Задача должна самостоятельно завершаться за время, не
превышающее заданное.
Если в этот момент идет выполнение предыдущей tt-задачи, она
вытесняется. Такая дисциплина диспетчеризации носит название
стэковой (stack-based scheduling). При этом предполагается, что
при формировании временной таблицы должны быть обеспечены
условия непереполнения стэка.
Контроль времени выполнения. Важным атрибутом tt-задачи
является предельное время ее завершения. Мониторинг момента
завершения tt-задачи осуществляется tt-диспетчером, который
для реализации этой операции имеет отдельный вход, имеющий
наименование «Deadline Monitoring». Вызов диспетчера в этом режиме приводит к проверке таблицы времен завершения задач. Для
задачи, нарушающей ограничение по максимальному времени выполнения, выполняются операции по обработке ошибок.
Возможно использование двух механизмов проведения этой проверки. Первый подразумевает вызов диспетчера по входу «Deadline
Monitoring» точно в момент времени, когда соответствующая задача
должна быть завершена. Второй механизм подразумевает выполнение этого вызова в следующей точке активации очередной задачи.
В этом случае операции проверки и запуска следующей задачи могут быть совмещены, что уменьшит накладные расходы на диспетчеризацию. Эти механизмы носят названия «Stringent task deadline
monitoring» и «Non-stringent task deadline monitoring» и определяются как атрибуты соответствующих задач при их описании.
Первой задачей, которую запускает tt-диспетчер, является задача, реализуемая компонентом с предопределенным именем
ttidleTask(). Эта задача имеет следующие специальные свойства:
она не регистрируется во временных таблицах tt-диспетчера и,
соответственно, не запускается циклически;
выполнение ее может быть прервано любым сигналом прерывания;
212
для нее не определено предельное время выполнения;
так как эта задача запускается первой, то она всегда выполняется, если никакая другая задача не готова к выполнению;
эта задача не имеет операции возврата «return».
Введение этого механизма обеспечивает возможность совместного использования операционных систем OSEKtime/OSEK, при
котором OSEK функционирует в фоновом режиме.
Подключаемый по умолчанию компонент ttIdleTask() поставляется для OSEKtime. Разработчик может использовать собственный вариант этой задачи при выполнении перечисленных выше требований
к ней. При совместном использовании микрооперационных систем
OSEKtime/OSEK задача ttIdleTask() поставляется вместе с OSEK.
Иллюстрация циклограммы работы tt-диспетчера приведена на
рис. 4.15.
Инициализация задач. Обслуживание задачи в реальном
устройстве кроме реализации конкретного компонента требует реализации ряда подготовительных, сервисных и завершающих операций. В OSEKtime использована концепция реализации режимов
работы приложения (application mode).
В соответствии с этим подходом все режимы работы приложения, например инициализация, штатный режим обслуживания,
завершение, описываются в виде разных таблиц диспетчера. Операционная система в штатном режиме обслуживания задач запускается вызовом системной функции ttStartOS(). Переключение
ªÄ¾½Ì×Ò¹Ø ËÇÐù¹ÃËÁ»¹ÏÁÁ
ªÄ¾½Ì×Ò¹Ø
ËÇÐù¹ÃËÁ»¹ÏÁÁ
›É¾ÅØ
¾ÂÊË»ÁØUU½ÁÊȾËоɹ
5BTL55
ÁÊÈÇÄÆØ¾Å¹Ø »Ô˾ÊƾÆÆ¹Ø ÁÊÈÇÄÆؾŹØ
5BTL55 À¹»¾ÉѾÆÆ¹Ø ÁÊÈÇÄÆؾŹØ
5BTL55
UU*EMF5BTL »Ô˾ÊƾÆƹØ
À¹»¾ÉѾÆƹØ
À¹»¾ÉѾÆƹØ
À¹»¾ÉѾÆƹØ
ÁÊÈÇÄÆؾŹØ
ÁÊÈÇÄ
»Ô˾ÊÆ
Рис. 4.15. Процессограмма tt-диспетчера
213
между разными таблицами описания диспетчеризации выполняется вызовом системного сервиса ttSwitchAppMode(). Фактическое
переключение в режим работы с соответствующей таблицей осуществляется в конце цикла обработки текущей таблицы.
§3. Обслуживание прерываний в OSEKtime
Табличная диспетчеризация, реализованная в OSEKtime, существенным образом меняет стандартные представления об использовании системы прерываний.
Для этого типа диспетчеризации ключевым вопросом является
выполнение временного графика запуска задач, чему может помешать появление прерываний в неподходящий момент времени.
Вместе с тем для работы с временными таблицами требуется наличие системного таймера, прерывания от которого являются ключевым элементом в реализации этого типа диспетчеризации. Кроме
этого, работа микроконтроллерной распределенной системы управления подразумевает использование микроконтроллером узла периферийных модулей, которые взаимодействуют с прикладными
задачами через систему прерываний.
Для обеспечения приоритета задачи приложения операционная
система OSEKtime блокирует возможность появления прерываний
в определенные интервалы времени. Для этого используются возможности систем управления прерываний, имеющиеся в современных микроконтроллерах, и которые позволяют заблокировать
сигнал прерываний. Для того чтобы приложение могло использовать периферийные модули, используется специальная таблица, в
соответствии с которой прерывания от используемых модулей разрешаются. При этом после обработки разрешенного сигнала прерывания прерывание снова блокируется. Рис. 4.16 иллюстрирует
использование табличного подхода при работе с прерываниями.
Для того чтобы при генерации программного кода отличить компоненты, реализующие обработку прерываний от других пользовательских компонентов, они описываются в тексте исходного кода
в виде
ttISR (FuncName)
{….. }
При этом следует не забывать, что OSEK постулирует возможность одновременного использования двух mОСРВ с разными под214
¯ÁÃÄ˹ºÄÁÏÔ½ÁÊȾËоɹ
*&
*&
&
1
ÌÉÇ»¾ÆÕ
ÈɾÉÔ»¹ÆÁØ
&
*&
%
&
1
*&
1
*&L
%
%
*&
&
&
ÌÉÇ»¾ÆÕ
ÈɾÉÔ»¹ÆÁØ
ÊÁ¼Æ¹Ä
ÈɾÉÔ»¹ÆÁØ
ÊÁ¼Æ¹Ä
ÈɾÉÔ»¹ÆÁØ
&
ÊÁ¼Æ¹Ä
ÈɾÉÔ»¹ÆÁØ
¨É¾ÉÔ»¹ÆÁ¾
ɹÀɾѾÆÇ
1
¨É¾ÉÔ»¹ÆÁ¾
Ǻɹº¹ËÔ»¹¾ËÊØ
›É¾ÅØ
%
¨É¾ÉÔ»¹ÆÁ¾
ƾɹÀɾѾÆÇ
Рис. 4.16. Иллюстрирующий пример для tt-обработчика прерываний
ходами к обработке сигналов прерываний. Решение этого круга
проблем представляет интерес как с практической, так и с теоретических точек зрения. При этом следует подчеркнуть, что реальная
практика использования этого стандарта еще только нарабатывается.
§4. Временная синхронизация в сети
Распределенные системы управления универсального назначения, использующие табличную диспетчеризацию, требуют решения проблемы синхронизации начальных отсчетов своих временных таблиц.
Для решения этой проблемы в полном объеме необходимо наличие в сети узла, обеспечивающего систему глобальным временем, а также эффективный способ доставки синхроимпульсов к
узлам сети, который минимизирует временные задержки. Доставку значения глобального времени к узлам обеспечивает уровень
синхронизации FTCom, которая используется в узлах совместно с
OSEKtime.
215
Кроме этого, требуется детальная проработка сценариев и разработка средств реализации механизмов синхронизации временных
таблиц для разных режимов эксплуатации управляющей сети. Эти
режимы включают в себя старт сети, восстановление синхронизации при наличии сбоев в работе сетевого компонента или отдельных узлов, устранение дрейфа временных отсчетов из-за ухода тактовых частот локальных таймеров.
При наличии глобального времени в OSEKtime используются
три различных сценария синхронизации при запуске системы:
cинхронный старт (synchronous start-up) – tt-диспетчеры узлов
запускают обработку временных таблиц лишь при получении значения точного времени;
асинхронный старт – жесткая синхронизация (asynchronous
start-up – hard synchronization) – запускается цикл запуска задач
по локальному времени без ожидания значения глобального времени. Привязка локального времени к глобальному осуществляется
после завершений одного цикла обработки временной таблицы за
счет соответствующей временной задержки запуска следующего
цикла обработки временной таблицы;
асинхронный старт – мягкая синхронизация (asynchronous
start-up – smooth synchronization) – запускается цикл запуска задач по локальному времени без ожидания значения глобального
времени. Привязка локального времени к глобальному осуществляется в течение нескольких циклов обработки временной таблицы за счет поэтапной задержки старта следующего цикла на величину, определяемую конфигурационными параметрами.
Устранение рассинхронизации во время работы узлов в штатных режимах эксплуатации осуществляется системным вызовом
ttSyncTimes(), выполняемым уровнем синхронизации. Получив
значение глобального времени, операционная система использует
разность локального и глобального времени для устранения рассогласования.
§5. OSEK FTCom
Это один из двух возможных вариантов реализации коммуникационной модели стандарта, обеспечивающий отказоустойчивость
для распределенных систем управления реального времени.
Представляет собой самостоятельную подсистему, которая обеспечивает ряд операций при запуске системы, прием, передачу и
216
обработку сообщений, а также диагностику системы путем получения сообщений о состоянии узлов. Подсистема реализует протокол
отказоустойчивого обмена и имеет ряд параметров, которые задаются на этапе генерации.
Кратко рассмотрим базовые принципы, используемые для обеспечения отказоустойчивости.
Отказоустойчивость подразумевает введение и использование
резервирования и в рамках стандарта описываются механизмы
многократного дублирования.
Подсистема строится на передаче сообщений по каналу с временным разделением. Обмен между узлами осуществляется циклически временными раундами (round), каждый из которых содержит
временные слоты (slot), по одному для каждого из узлов сети. В своем временном слоте узел посылает кадр (frame), который обычно
содержит несколько сообщений.
Коммуникационный контроллер передает кадры определенной
длины. Для обеспечения отказоустойчивости кадр может содержать несколько копий (message instance) одного и того же сообщения или сообщение может содержаться в разных кадрах.
На рис. 4.17 приведен пример структуры информационного обмена.
Система содержит два коммуникационных канала ch_A и ch_B.
Названия кадров содержат информацию о временном слоте и раунде. Специфицированная структура обеспечивает передачу сообщения M1 двумя узлами во временных слотах 1 и 2 по двум каналам.
Таким образом, сообщение M1 имеет четыре копии.
¬À¾Ä@
.
DI@"
.
.
¬À¾Ä@
.
.
.
.
ccc
.
¬À¾Ä@/
.
.
GSBNF@TMPU/@SPVOE@@DI@"
GSBNF@TMPU/@SPVOE@@DI@"
GSBNF@TMPU@SPVOE@@DI@"
DI@#
.
.
.
.
.
.
.
.
.
.
.
GSBNF@TMPU/@SPVOE@@DI@#
GSBNF@TMPU@SPVOE@@DI@#
GSBNF@TMPU@SPVOE@@DI@#
›É¾ÅØ
Рис. 4.17. Пример структуры информационного обмена
217
Структура кадров описывается на этапе генерации системы и
подчиняется следующим правилам:
сообщение должно содержаться хотя бы в одном кадре;
один кадр несет 0-max_frame_size сообщений;
кадр содержит, по крайней мере, одно сообщение;
кадр содержит более одной копии сообщения.
При этом возможно использование полностью или частично
пустых кадров для обеспечения возможности резервирования сообщений для следующих версий системы.
Уровень взаимодействия обеспечивает извлечение передаваемой
дублированной информации, используя для этого описание структуры информационного обмена, задаваемого на этапе конфигурации
системы. Этот уровень оценивает состояния конкретного сообщения
и передает одну копию приложению, которому оно предназначено.
При передаче сообщения, уровень взаимодействия получает
данные от приложения и копирует их в соответствующие слоты.
Эти операции выполняются задачами коммуникационного слоя,
выполняемыми под управлением операционной системы.
Если сообщение посылается больше, чем одному узлу, FTCom
обеспечивает отсылку одних и тех же данных, заблокировав их обновление на время пересылки. Например, речь может идти о показаниях датчика, привязанных к конкретному временному отсчету.
Для организации протокола такого типа необходимым условием является временная синхронизация узлов. При этом имеется
возможность оценки качества канала за счет измерения разницы
между ожидаемым временем прихода сообщения и фактическим.
Отказоустойчивость системы передачи сообщений обеспечивается
механизмами подстройки временных параметров протокола обмена сообщениями, который базируется на этих измерениях.
Так как каждый узел должен обеспечивать передачу информации в своем временном слоте, то факт ее отсутствия позволяет контролировать работоспособность узлов.
Для обеспечения временной синхронизации в системах коммуникаций с табличной диспетчеризацией требуется наличие возможности синхронизации коммуникационных модулей всех узлов
сети. Это свойство называют глобальной синхронизацией.
Структура коммуникационных уровней подсистемы показана
на рис. 4.18. Как следует из этого рисунка, имеется ряд отличий
от классической семиуровневой модели OSI. Подсистема состоит
из двух частей. Первая обеспечивает реализацию механизма отказоустойчивости при передаче сообщений, а вторая обеспечивает
218
04&,UJNF04
£ÇÅÅÌÆÁùÏÁÇÆÆÔÂ
"1*
¨ÉÁÄÇ¿¾ÆÁ¾
"QQMJDBUJPO
04&,UJNF'5$PN-BZFS
¬ÉÇ»¾ÆÕÈÉÁÄÇ¿¾ÆÁØ
"QQMJDBUJPOMBZFS
­ÁÄÕËɹÏÁØÊÇǺҾÆÁØ
.FTTBHFGJMUFSJOHMBZFS
¨Ç½ÊÁÊ˾ŹǺ¾ÊȾоÆÁØ
ÇËùÀÇÌÊËÇÂÐÁ»ÇÊËÁ
¬ÊËÇÂÐÁ»Ç¾
ÊÇǺҾÆÁ¾
§º¾ÊȾоÆÁ¾
ÇËùÀÇÌÊËÇÂÐÁ»ÇÊËÁ
'BVMUUPMFSBOUMBZFS
£ÇÅÅÌÆÁùÏÁÇÆƹØ
ÈǽÊÁÊ˾Ź
ªÇǺҾÆÁ¾
ªÄÇ»À¹ÁÅǽ¾ÂÊË»ÁØ
*OUFSBDUJPOMBZFS
£¹½É'5$0.
$/*½É¹Â»¾É
$/*ù½É
£¹½ÉÑÁÆÔ
$/*
ÃÇÅÅÌÆÁùÏÁÇÆÆÔÂ
ÃÇÆËÉÇÄľÉ
Рис. 4.18. Структура OSEK FTCom
коммуникации с узлами сети. Описание уровней подсистемы приведено в табл. 4.7.
Драйвер CNI не является составной частью FTCom. Его функциями при передаче сообщений являются:
выделение кадров передаваемого сообщения;
оценка статуса сообщения;
учет особенностей аппаратных реализаций доступа к шине.
219
Таблица 4.7
Уровень
Функции уровней FTCom
Назначение
Приложений
обеспечивает интерфейс для компонента приложения (API)
Фильтрации сообще- обеспечивает селекцию сообщений
ний
Обеспечения откареализует механизм оценки сообщений;
зоустойчивости
обеспечивает информацию о статусе сообщения
Взаимодействия
формирует требуемый порядок битов (LSB-MSB)
при необходимости передачи сообщений между
узлами с разными типами представления данных;
обеспечивает операции упаковки-распаковки данных;
поддерживает механизм передачи статуса сообщений
Подсистема предназначена для использования в распределенных системах с операционными системами с tt-диспетчеризацией.
Кроме этого, она базируется на временном разделении коммуникационного канала. Соответственно, обеспечение временной синхронизации между соответствующими таблицами описания расписания является ключевым вопросом.
Механизмы синхронизации tt-диспетчера и отказоустойчивой
коммуникационной системы реализуются с использованием следующих предположений:
информационная посылка структурирована по времени и состоит из раундов, слотов и фрэймов, которые содержат одну или несколько копий сообщений;
прикладные задачи выполняются синхронно со слотами для обеспечения передачи и приема сообщений с детерминированной задержкой;
раунд tt-диспетчера включает в себя некоторое количество коммуникационных раундов;
если раунд tt-диспетчера больше, чем коммуникационный раунд, то эта ситуация должна отслеживаться для обеспечения синхронизации приложений, выполняемых на разных узлах. Например, если приложение выполняется на четырех узлах, которые
читают сообщение каждый второй коммуникационный раунд, а
результатом является управление четырьмя исполнительными
устройствами, очевидно, что чтение и обработка сообщения должны происходить в одном и том же коммуникационном раунде.
220
5@
«¹ºÄÁϹUU½ÁÊȾËоɹ
5@
(4
5@/
«¹ºÄÁϹUU½ÁÊȾËоɹ
5@
5@
5@/
(4
ɹÌƽUU½ÁÊȾËоɹ
ªÅ¾Ò¾ÆÁ¾
͹À¹
£ÇÅÅÌÆÁùÏÁÇÆÆÔÂ
ɹÌƽ
œÄǺ¹ÄÕÆǾ
»É¾ÅØ
£ÇÅÅÌÆÁùÏÁÇÆÆÔÂ
ÊÄÇË
Рис. 4.19. Временная синхронизация
Характерная структура временных соотношений между таблицей tt-диспетчера и таблицей описания структуры коммуникационного протокола показана на рис. 4.19.
FTCom обеспечивает реализацию уровня синхронизации для
OSEKtime. Этот уровень обеспечивает запуск tt-диспетчера с задержкой к коммуникационному раунду, которая в терминах стандарта
называется фазой. Для согласования FTCom использует информацию о приложениях и параметрах коммуникационной системы:
длина раунда tt-диспетчера;
длина коммуникационного раунда;
текущее относительное смещение начальных точек раундов
(фаза);
данные о привязке приложений к конкретному коммуникационному раунду.
Параметры корректировки передаются в приложение при запросе глобального времени, для чего используются два системных
вызова:
ttGetGlobalTime() – получение значения текущего глобального
времени;
ttGetSyncTimes() – получение значения текущего глобального времени и времени начала обработки временной таблицы ttдиспетчера.
Контрольные вопросы и задания к главе 4
1. Возможно ли использование платформы QNX6 для реализации технологии компонентного программирования?
221
2. Как сказывается на минимально достижимом времени реакции системы использование механизма обработки прерываний,
реализованного в Neutrino по сравнению c QNX4?
3. Сравните между собой возможные способы персонификации
изделий:
корректировка текста исходной программы путем внесения
идентифицирующей информации об изделии в тест;
использование внутренней EEPROM-памяти для этой информации;
использование внешней памяти небольшого объема.
4. Какими свойствами должен обладать системный компонент,
обеспечивающий операции по идентификации?
5. В чем отличие моделей уровней в OSEK от классической семиуровневой модели OSI?
6. Возможно ли использование в одной системе управления
узлов с операционными системами OSEK OS и OSEKtime?
7. Установите IDE MPLAB и проведете изучение его возможностей по отладке с использованием симулятора.
Литература к главе 4
1. Кртен Р. Введение в QNX Neitrino. Руководство для разработчиков приложений реального времени. СПб.: БХВ-Петербург,
2011. 368 с.
2. Астапкович А. М. Микрооперационные системы реального
времени. СПб.: Политехника, 2002. 246 с.
3. Астапкович А. М. Семинары ASK Lab 1997. СПб.: Политехника, 1998. 134 с.
4. Востриков А. А. Модификатор как часть программноинструментальной среды//Микропроцессорные информационноуправляющие системы реального времени. Семинары ASK Lab
2000. СПб.: Политехника, 2000. С. 59–68.
222
СОДЕРЖАНИЕ
Введение ...................................................................................
Глава 1. Структура систем управления космических аппаратов ........
1.1. История развития цифровых систем управления ......................
§1. ЦВМ «Кварц» и третий советский искусственный спутник .....
§2. Система управления корабля «Восток-1» .............................
§ 3. Автоматический комплекс «Луна-16».................................
1.2. Системы управления марсохода spirit-opportunity ....................
§1. Описание проекта .............................................................
§ 2. Видеосистема марсохода ...................................................
§ 3. Базовые функции системы управления ...............................
§4. Аппаратное обеспечение бортовой системы управления .........
§5. Программное обеспечение системы управления ....................
1.3. Стандарты систем управления космического назначения...........
§ 1. Международная кооперация в осуществлении космических
проектов ..............................................................................
§2. Система стандартов ECSS-E ................................................
§3. Структура управляемой системы ........................................
§4. Командная и телеметрическая информация .........................
Контрольные вопросы и задания к главе 1 .....................................
Литература к главе 1 ..................................................................
Глава 2. Аппаратное обеспечение систем управления ......................
2.1. Структура систем управления ................................................
§1. Понятие архитектуры .......................................................
§2. Микропроцессор Intel 4004 ................................................
§3. Законы Мура и Амдала ......................................................
§4. Сигнальные микропроцессоры ...........................................
2.2. Системы управления с модульной структурой ..........................
§1. COTS и OEM-решения .......................................................
§2. Аппаратные решения стандарта PC-104 ...............................
§3. Стандарт VMEbus .............................................................
§4. Линии развития стандарта VMEbus .....................................
§5. Спецификация CompactPCI ................................................
§6. Система на модуле ............................................................
2.3. Элементная база для распределенных систем управления ..........
§1. Микроконтроллеры ..........................................................
§2. Особенности архитектуры микроконтроллеров .....................
§3. Система команд ................................................................
§4. Система прерываний микроконтроллеров ............................
2.4. Микроконтроллеры семейства pic18f (nano Watt Technology) .....
§1. Общая характеристика семейства .......................................
§3. Периферийные модули ......................................................
§4. Система прерываний .........................................................
§5. Подсистема обеспечения надежности ..................................
2.5. Системы управления с распределенной структурой ...................
§ 1. Системы управления современного автомобиля ....................
§2. Платформенный подход ....................................................
§3. Топология сети .................................................................
§4. Интеллектуальные узлы ....................................................
§5. Шина CAN .......................................................................
Контрольные вопросы и задания к главе 2 .....................................
Литература к главе 2 ..................................................................
Глава 3. Современные технологии разработки программного обеспечения .......................................................................................
3
5
5
5
8
11
17
18
22
24
28
30
31
31
32
34
37
40
41
43
43
44
48
54
58
62
63
64
68
72
74
79
82
82
84
87
87
90
90
93
95
97
100
100
103
104
106
109
114
115
117
223
3.1. Технологические циклы разработки .......................................
§1. Введение .........................................................................
§2. Базовые понятия ..............................................................
§3. V-модель .........................................................................
§4. Системная интеграция ......................................................
§5. Разработка полного цикла .................................................
3.2. Классификация способов разработки программного обеспечения
§1. Иерархическая структура методов разработки ......................
§2. Линейный подход .............................................................
§3. Компонентное программирование .......................................
§4. Разработка с использованием технологии ОСРВ ....................
§5. Микрооперационные системы реального времени .................
§6. Платформа Eclipse ............................................................
§7. Генераторы приложений ...................................................
3.3. Операционные системы реального времени ..............................
§1. Стандарты POSIX .............................................................
§2. Потоки (threads) POSIX .....................................................
§3. Стандарты DO-178B и ARINC-653 .......................................
§4. Стандарт OSEK/VDX.........................................................
§ 5. Измерение времени в микропроцессорных системах .............
Контрольные вопросы и задания к главе 3 .....................................
Литература к главе 3 ..................................................................
Глава 4. Современные программно-инструментальные платформы ...
4.1. Платформа QNX6 ................................................................
§1. Общие сведения................................................................
§2. Состав платформы QNX6 ...................................................
§3. Концепция ОСРВ Neutrino .................................................
§4. Реализация защиты памяти ...............................................
§5. Реализация нитей (потоков) ...............................................
§6. Синхронизация и обмен сообщениями .................................
§7. Система прерываний, системные часы и таймеры ..................
§8. Инструментальной среды QNX Momentics ............................
4.2. Интегрированная среда разработки IDE MPLAB ......................
§1. Общие сведения................................................................
§2. Менеджер проектов...........................................................
§3. Сборщик кода (linker)........................................................
§4. Языковые средства ...........................................................
§5. mОСРВ технологии разработки ...........................................
4.3. Стандарт OSEK/VDX ............................................................
§1. Общая характеристика ......................................................
§2. Структура системы стандартов OSEK ..................................
§3. Операционная система OSEK OS .........................................
§4. Коммуникационная подсистема OSEK COM..........................
§5. Подсистема управления сетью OSEK NM..............................
§6. Язык OSEK OIL ................................................................
4.4. Парадигма табличной диспетчеризации ..................................
§ 1. Операционная система OSEKtime .......................................
§2. Задачи и tt-диспетчеризация OSEKtime ...............................
§3. Обслуживание прерываний в OSEKtime ...............................
§4. Временная синхронизация в сети ........................................
§5. OSEK FTCom ....................................................................
Контрольные вопросы и задания к главе 4 .....................................
Литература к главе 4 ..................................................................
224
117
117
119
122
124
126
128
129
130
131
133
137
140
146
147
147
150
151
152
154
161
162
164
164
165
165
167
169
170
175
178
180
186
186
187
188
189
191
194
194
196
199
200
203
206
208
208
210
214
215
216
221
222
Документ
Категория
Без категории
Просмотров
50
Размер файла
1 689 Кб
Теги
astapkovich
1/--страниц
Пожаловаться на содержимое документа