Особенности современных ОСРВ Ричард Блекберн (Richard

Особенности современных ОСРВ
Ричард Блекберн (Richard Blackburn), OSE Systems
Концепции, лежащие в основе большинства существующих в наши дни операционных систем реального времени (ОСРВ), уходят своими корнями в конец 70-х начало 80х годов прошлого столетия. Эти концепции разрабатывались с учетом требований того
времени, и по мере увеличения сложности, масштабов и скорости систем на фоне все возрастающего давления сроков выведения новых продуктов на рынок и повышения требований к их надежности все чаще начинают проявляться недостатки традиционных ОСРВ.
Современные ОСРВ базируются на новых архитектурных подходах и дополняются средствами разработки прикладных систем, которые позволяют создавать их в сокращённые
сроки и с наилучшими характеристиками. Решение этих вопросов показано на примере
продуктов компании OSE Systems.
Отличительные особенности современных ОСРВ
Рассмотрим основные аспекты, касающиеся отличий современных и традиционных
ОСРВ. Это различные модели межпроцессного взаимодействия, распределение памяти,
обработка ошибок, возможность реализации многопроцессорных систем и систем цифровой обработки сигналов, автоматический контроль для обеспечения высокой готовности и
безопасности и т.д.
Межпроцессное взаимодействие
В традиционных ОСРВ для межпроцессного взаимодействия (IPC — Inter-Process
communication) используется, как правило, модель "разделяемой памяти" (share memory).
Большинству разработчиков хорошо известны трудности, связанные с управлением межпроцессным взаимодействием такого типа, а также опасность сбоя системы, возникающая
в том случае, когда один процесс "приватизирует" доступ к данным, или когда один процесс повреждает данные, жизненно важные для другого процесса. Проблема обеспечения
стабильности работы системы с IPC через разделяемую память вполне разрешима, однако
в общем случае такая задача требует весьма аккуратного управления разработкой и сопровождением программного обеспечения и достаточно длительного периода выявления
ошибок. Перечисляя недостатки межпроцессного взаимодействия через разделяемую память, следует упомянуть также о том, что данный метод плохо подходит для распределенных систем и не может похвастаться высокой степенью совместимости с управлением памятью. Работоспособность системы с IPC через разделяемую память достижима и в этих
случаях, однако есть способы лучше.
Например, в ряде современных ОСРВ модель межпроцессного взаимодействия
реализована через "передачу сообщений" (message passing). Согласно этой модели (рис.1),
акт взаимодействия заключается в том, что один процесс посылает другому процессу сообщение; при этом может потребоваться лишь четыре системных вызова. Данный подход
прост и надежен; прохождение сообщений в процессе работы системы может легко отслеживаться, что придает разработке и отладке ПО свободу и непринужденность. Кроме
того, прямым следствием межпроцессного взаимодействия через передачу сообщений является возможность естественным образом распределять приложение между многочисленными центральными и DSP-процессорами. Еще одним приятным моментом является
то, что приложение может быть разделено на несколько задач, создаваемых разными разработчиками.
1
Рис.1. Два типа межпроцессного взаимодействия: через разделяемую память и через передачу сообщений
Но нет ли у этой медали оборотной стороны? Поставщики традиционных ОСРВ
могут заявить, что IPC через передачу сообщений не отличается высокой скоростью, и
при определенных обстоятельствах это утверждение будет соответствовать действительности. Тем не менее, как показывает практика, несколько пониженная скорость межпроцессного взаимодействия такого типа весьма редко сказывается на общей производительности системы и вряд ли может служить основанием для заслуживающих внимание критических аргументов.
Распределение памяти
В традиционных ОСРВ для динамического распределения памяти используется механизм, подобный вызову функции malloc в языке Си. При выполнении этой команды исследуется весь массив памяти в поисках свободной области достаточно большого размера.
У данного метода есть два недостатка. Первый — это то, что "глубина" таких поисков (а,
следовательно, и затрачиваемое на распределение памяти время) будет меняться в зависимости от того, как долго работает система. Второй недостаток связан с проблемой возникновения фрагментации: вы можете иметь 50 Кбайт свободной памяти, но эти 50 Кбайт
могут быть в виде непригодных для использования 4-килобайтных кусочков. Многие специалисты решают эту проблему при помощи хитроумных программ и процедур собственного изготовления, однако такие методы могут не лучшим образом сказаться на характеристиках реального времени.
Разработчики современных ОСРВ предпочитают другой способ. В случае операционной системы OSE, например, программист должен точно определить объем "пула" используемой памяти. Он также должен задать восемь размеров блоков памяти, которые могут быть выделены ему из этого "пула". В дальнейшем при возникновении потребности в
памяти ОСРВ будет брать из "пула" кусок наиболее подходящего размера из этих восьми.
Когда блок памяти перестает быть нужным, он отходит в связанный список свободных
буферов. Преимущества такого решения состоят в том, что степень фрагментации памяти
равна нулю, время распределения памяти строго детерминировано, а незанятый блок всегда находится либо в связанном списке, либо в начале области свободной памяти.
2
Рис.2. Модель обработки ошибок в традиционной ОСРВ и в операционной системе
OSE
Обработка ошибок
В классических ОСРВ, как правило, используется десятилетиями установленный
порядок обработки ошибок. Для выявления ошибок по совершении системного вызова
проверке подвергается каждое возвращаемое значение. Отсюда немедленно следует, что
всю полноту ответственности за надежность работы системы несет каждый участвующий
в проекте специалист. Дополнительным неудобством является то, что значительная часть
вашего приложения будет состоять из кодов ошибок, из-за чего оно увеличивается в размерах, его труднее документировать и отлаживать.
В большинстве современных ОСРВ обработчики ошибок связаны с системными
вызовами. Если начинает исполняться следующая строка кода, значит все в порядке. Если
же происходит ошибка, в дело вступает "центральный обработчик ошибок". Например, в
операционной системе OSE обработка ошибок ведется на трех уровнях: уровне процесса,
уровне блока и уровне системы, что даёт высокую степень гибкости в выборе разрешения
связанных с ошибками проблем. Такой механизм обработки ошибок не только намного
надёжнее, он позволяет создавать более компактный и простой программный код.
Распределенные многопроцессорные системы
Не вызывает сомнений, что большинство традиционных ОСРВ разрабатывались с
прицелом на единственный центральный процессор, установленный на единственной плате. В наши дни все чаще требуется поддержка многопроцессорных систем, в том числе с
поддержкой процессоров цифровой обработки сигналов (DSP-процессоры). В современной операционной системе OSE обработчик связей (link handler) позволяет естественным
образом распределять приложение по многочисленным центральным и/или DSPпроцессорам. Он действует на манер почтальона, беря сообщение от одного процесса, работающего на одном процессоре, и вручая его другому процессу, исполняющемуся на
другом центральном или DSP-процессоре.
Высокая готовность и безопасность
Сейчас ОСРВ все чаще применяются в критичных к безопасности приложениях и в
системах с высоким коэффициентом готовности, и большинство поставщиков операционных систем реального времени ищут способы решения возникающих в этой связи проблем. В случае операционной системы OSE решением являются два особых системных
вызова: HUNT и ATTACH. Вызов HUNT позволяет ядру вести поиск процесса по имени.
Вызов ATTACH сообщает процессу, что ядро проявляет к этому процессу "интерес". Это
означает, что если с процессом что-нибудь будет "не так", ядро будет обязательно об этом
проинформировано. Используя эти системные вызовы, разработчик может реализовать
"горячую" замену и дублирование (резервирование) аппаратных средств. При отказе или
3
удалении какого-либо устройства происходит уведомление об этом ядра, после чего ядро
может провести поиск (hunt) второго подобного устройства и начать работать (attach) с
этим устройством в том случае, если последнее окажется работоспособным.
С места в карьер
Традиционные ОСРВ используются во многих проектах по всему миру. Они выполнены талантливыми специалистами и успешно выполняют свои задачи. Тем не менее,
на описание, широкое обсуждение и попытки исправления недостатков, о которых говорилось выше, потрачено много сил и времени.
Поэтому очень важно, что во многих современных ОСРВ эти проблемы начинают
решаться изначально при разработке самой ОС. Помимо этого, в целях сокращения времени разработки и отладки прикладных систем и ускорения вывода их на рынок поставщики современных ОСРВ предлагают широкий спектр инструментальных средств системного уровня.
Рассмотрим более подробно требования к ОСРВ со стороны современных многопроцессорных систем, в том числе с поддержкой DSP-процессоров, а также инструментарий, позволяющий быстро и с наилучшими характеристиками создавать соответствующие
встроенные системы.
Системный инструментарий современных ОСРВ
Симуляторы ОСРВ
Редко бывает так, что на начальном этапе проектирования встраиваемого приложения уже существуют необходимые аппаратные средства. Стремление быть на рынке первым приводит к тому, что зачастую при запуске проекта не только оборудование, но даже
микросхемы центральных и DSP-процессоров еще находятся на стадии разработки. Чтобы
занятые в проекте специалисты могли как можно раньше приступить к разработке программных кодов, алгоритмов, протокольных стеков, некоторые поставщики ОСРВ предлагают "симуляторы ОСРВ".
Так, по принципу своей работы инструментальные средства Soft Kernel и Soft
Environment, созданные компанией OSE, напоминают пакет, служащий буфером между
операционной системой и тем или иным аппаратным модулем (BSP — board support
package), только в данном случае в роли такого модуля выступает интерфейс 32разрядных Windows-приложений (Win32 Api). Иными словами, инструмент Soft
Environment способен, с одной стороны, использовать функциональные возможности
хост-машины и, с другой стороны, взаимодействовать с внешним миром. Запустив одновременно несколько инструментов Soft Kernel на одной хост-машине, можно создать модель сетевой или многопроцессорной среды и вести разработку соответствующего проекта. В одном крупном телекоммуникационном проекте было занято более 650 специалистов, из которых около 450 работали в среде Soft Kernel Environment. Подобные статистические данные показывают достоинства инструмента Soft Kernel, отчетливо проявляющиеся в условиях сегодняшней рыночной гонки.
Загрузчик программ
4
В некоторых ОСРВ разработчику предлагается возможность динамической загрузки кода в целевую машину, что позволяет сократить число циклов перекомпиляцииперезагрузки и сэкономить много часов затрачиваемого на разработку времени. Идея состоит в том, что вы можете создать фрагмент программы, откомпилировать его, а затем
послать в работающую целевую машину. Если фрагмент работает не вполне корректно,
вы модифицируете его, затем повторно компилируете, вновь загружаете в целевую машину и т.д. Проявляя известную аккуратность, разработку кода могут вести несколько специалистов с использованием одной и той же подключенной к сети целевой машины. Загрузчик программ полезен не только при разработке современных встраиваемых систем;
он может сыграть важнейшую роль при обслуживании системы с высоким коэффициентом готовности, отключение которой крайне нежелательно.
Браузер системы
Пожалуй, одной из наиболее серьезных проблем, с которой имеют дело разработчики программного обеспечения, является тот факт, что создаваемые ими программы работают где-то глубоко внутри небольшого черного кусочка из кремния и пластика. Специалисты старой закалки могут припомнить, что в былые времена для получения оперативной информации о работе программы приходилось использовать внешние светодиоды,
зажигающиеся на разных стадиях исполнения кода.
В наши дни дела обстоят куда лучше. Многие поставщики ОСРВ предлагают различные работающие на хост-машине средства просмотра. Эти средства в большинстве
случаев смогут показать вам все запущенные процессы, а также приоритет, состояние и
другие важнейшие характеристики каждого процесса в отдельности. Для операционной
системы OSE такого рода инструмент называется Illuminator.
Профилировщик центрального процессора
В процессе разработки и отладки предназначенного для встраиваемой системы
программного обеспечения необходимо иметь точные данные относительно загрузки центрального процессора, поскольку наличие подобной информации способствует оптимизации производительности программного кода. В комплектах инструментальных средств
современных ОСРВ имеются такие профилировщики. Средство CPU Profiler (профилировщик центрального процессора) для операционной системы OSE позволяет выбрать одну или несколько определенных задач и получить ясную картину того, насколько эти задачи загружают центральный процессор, а также того, как влияет эта загрузка на работу
системы в целом. Разумеется, качество подобной информации будет зависеть от скорости
связи между хостом и целевой машиной.
Профилировщик памяти
Компьютерные инженеры, говоря о характеристиках памяти, в разных ситуациях
имеют в виду разные вещи. Для глубоко встроенного автомобильного микроконтроллера
100 Кбайт — это очень большой объем памяти, для мобильного телефона может оказаться
недостаточным и 2 Мбайт, а прикладное ПО регистрации данных может с трудом уместиться 1 Гбайте. И все же, каково бы ни было приложение, оптимальное использование
памяти нередко является решающим моментом, как из коммерческих соображений, так и
с точки зрения рабочих характеристик продукта.
Разработанный для операционной системы OSE инструмент Memory Profiler (профилировщик памяти) предлагает исчерпывающую динамическую информацию об использовании памяти каждой конкретной задачей, о прохождении сигналов, а также статисти-
5
ческую информацию и иные данные, которые могут помочь оптимизировать использование памяти.
Трассировка событий
Некоторые поставщики ОСРВ предлагают средства "трассировки событий", способные динамически отображать работающие задачи и межпроцессные взаимодействия.
Регистрация может производиться через определенные интервалы времени (например, через 50 мкс), в случае наступления определенных событий, по прерываниям и т.п. Создаваемая такими инструментами графическая картина происходящего может служить подспорьем в понимании работы сложного приложения.
Средство трассировки для операционной системы OSE называется Evact Handler
(event and action handler — обработчик событий и действий). Данный инструмент позволяет не только осуществлять динамический мониторинг описанного выше типа, но и вводить информацию в работающую систему.
Источник: "What Makes A Modern RTOS" by Richard Blackburn, OSE Systems Ltd.
(www.ose.com), Micro Technology Europe March 2002
6