Автоматизированное управление мобильным роботом

7.4. Прерывания

При описании управления прерываниями обычно различают две процедуры, а именно:

• программа обработки прерывания (ISR - interrupt servicing routine) - программа низкого уровня в ядре с ограниченными системными вызовами,
• поток обработки прерывания (IST - interrupt servicing thread) - поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.

Обычно ISR реализуются производителем аппаратуры, а драйверы устройств выполняют управление прерываниями с помощью IST. Потоки обработки прерываний действуют как любые другие потоки и используют ту же самую систему приоритетов. Это означает, что проектировщик системы может придать IST более низкий приоритет, чем приоритет потока приложения.

7.5. Часы и таймеры

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

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

Большинство ОСРВ оперируют относительным временем. Что-то происходит "до" и "после" некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа "ждать одну секунду", то нужен тактовый генератор и/или таймер.

Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не используется.

Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС.

7.6. Стандарты ОСРВ

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

Наиболее ранним и распространенным стандартом ОСРВ является стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Первоначальный вариант стандарта POSIX появился в 1990 г. и был предназначен для UNIX-систем, первые версии которых появились в 70-х годах прошлого века. Спецификации POSIX определяют стандартный механизм взаимодействия прикладной программы и операционной системы и в настоящее время включают набор более чем из 30 стандартов. Для ОСРВ наиболее важны семь из них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в коммерческих ОС получили только три первых.

Несмотря на явно устаревшие положения стандарта POSIX и большую востребованность обновлений стандартизации для ОСРВ, заметного продвижения в этом направлении не наблюдается.

Некоторые наиболее успешные компании в области систем реального времени объявляют о своем решении принять в качестве стандарта спецификации одной из своих продвинутых ОСРВ. Так поступила компания TRON (the RTOS Nucleus), которая в 1987г. выпустила в свет первые ITRON спецификации - ITRON1. Далее в 1989г. она разработала и выпустила спецификации µITRON для 8- и 16- битовых микроконтроллеров, а также спецификации ITRON2 для 32-битовых процессоров. ОСРВ ITRON описывается ниже в соответствующем разделе. Этот стандарт является очень распространенным в Японии.

Военная и аэрокосмическая отрасли предъявляют жесткие требования к вычислительным средствам, влияющим на степень безопасности целевой системы. В настоящее время имеются следующие стандарты для ОСРВ в авиации - стандарт DO-178B и стандарт ARINC-653. Поскольку эти стандарты разработаны в США, стоит отметить еще европейский стандарт ED-12B, который является аналогом DO-178B.

Распространенным также является стандарт OSEK/VDX, который первоначально развивался для систем автомобильной индустрии.

7.7. OSEK/VDX

Стандарт OSEK/VDX является комбинацией стандартов, которые изначально разрабатывались в двух отдельных консорциумах, впоследствии слившихся. OSEK берет свое название от немецкого акронима консорциума, в состав которого входили ведущие немецкие производители автомобилей - BMW, Bosch, Daimler Benz (теперь Daimler Chrysler), Opel, Siemens и Volkswagen, а также университет в Карлсруэ (Германия). Проект VDX (Vehicle Distributed eXecutive) развивался совместными усилиями французских компаний PSA и Renault. Команды OSEK и VDX слились в 1994г.

Первоначально проект OSEK/VDX предназначался для разработки стандарта открытой архитектуры ОС и стандарта API для систем, применяющихся в автомобильной промышленности. Однако разработанный стандарт получился более абстрактным и не ограничивается использованием только в автомобильной индустрии.

Стандарт OSEK/VDX состоит из трех частей - стандарт для операционной системы (OS), коммуникационный стандарт (COM) и стандарт для сетевого менеджера (NM). В дополнение к этим стандартам определяется некий реализационный язык (OIL). Первым компонентом стандарта OSEK является стандарт для ОС, поэтому часто стандарт OSEK ошибочно воспринимается как стандарт ОСРВ. Хотя ОС и есть большая порция данного стандарта, мощность его состоит в интеграции всех его компонент.

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

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

Задача в ОС OSEK может быть

• базовой или расширенной,
• вытесняемой или невытесняемой.

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

Рис. 7.1.

Концепция двух типов задач потребовала введения нового понятия - класс соответствия (conformance class) для описания своеобразной реализации ОС OSEK и системных сервисов. Определяются четыре класса соответствия - два для базового соответствия (BCC1 и BCC2 - Basic conformance Classes 1 и 2) и два для расширенного (ECC1 и ECC2 - Extended Conformance Classes 1 и 2). Реализации, которые соответствуют базовым классам, требуют использования только базовых задач, в то время как для расширенных классов нужны как расширенные, так и базовые задачи. Числа 1 и 2 в именах классов указывают количество запросов на задачу для базовых задач и количество задач на приоритет для всех задач. Таким образом, в BCC1 и ECC1 имеется только одна задача на приоритет, и базовые задачи могут быть запрошены только один раз. В BCC2 и ECC2 допускается множественность задач на приоритет и множественное запрашивание базовых задач.

Каждая задача должна находиться в одном из четырех состояний

• Выполняющаяся - только одна задача может быть в этом состоянии,
• Готовая к выполнению - планировщик может выбрать ее на выполнение на основании приоритетов и правил вытеснения,
• Ожидающая - задача ждет появления события,
• Приостановленная - задача в пассивном состоянии и ждет активации.

Рис. 7.2. Модель состояний задачи в ОС OSEK

Каждая задача имеет приоритет. Стандарт ОС OSEK не ограничивает максимальное количество приоритетов - это определяет реализация.

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

События в ОС OSEK используются для синхронизации различных задач. События являются собственностью задач. Любая задача, в том числе и базовая, может установить событие, и только собственник события может ожидать или снять его.

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

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

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

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

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

7.8. nxtOSEK C/C++ API

ОС РВ nxtOSEK имеет программный интерфейс для С и С++, который используется в пакете ECRobot . Изначально программный интерфейс для С разрабатывался исключительно для автоматической генерации кода пакетом Simulink® (в рамках реализации модельно-ориентированного подхода пакета ECRobot), и, как следствие, его не очень удобно использовать при написании программы на чистом С. Другое дело интерфейс для С++, его структура и имена более приспособлены для написания программ вручную. Ниже приведен пример программы HelloWorld на С++, после знакомства с API для C будет очевидно, что эта программа реализована проще, чем ее аналог на C.

/* sample.cpp для TOPPERS/ATK(OSEK) */ 

//nxtOSEK C++ API
#include "Lcd.h"   //подключаем класс работы с дисплеем
using namespace ecrobot;
extern "C"
{
//стандартные заголовочные файлы
#include "kernel.h"
#include "kernel_id.h"
#include "ecrobot_interface.h"

// nxtOSEK обработчик прерываний
void user_1ms_isr_type2(void){}
//точка входа
TASK(TaskMain)
{
  Lcd lcd;  //создаем объект lсd

  lcd.clear();  //очищаем дисплей
  lcd.putf("s", "Hello World");  //вывод Hello World
  lcd.disp();  //перерисовываем картинку на дисплее

  while(1);
}
}

Сама система nxtOSEK базируется на ОС TOPPERS ATK1, которая очень похожа на версию ОС OSEK OS/OIL, используемую в проекте TOPPERS. Подробное описание API OSEK можно найти на сайте OSEK/VDX (см. OSEK OS Version 2.2.1, OSEK OIL Version 2.5). Однако в ОС РВ nxtOSEK не реализована некоторая функциональность TOPPERS ATK1 из-за особенностей архитектуры системы. Например, не следует использовать объявления процедур обработки прерываний (ISR) и API обработки прерываний.

К сожалению, подробная документация TOPPERS ATK1 доступна только на японском языке, тем не менее, желающие смогут найти ее в папке nxtOSEK\toppers_osek\doc.