Особенности систем реального времени.

Основной особенностью является необходимость использования специализированных программных, аппаратных и алгоритмических решений:

· Промышленных компьютеров, промышленных контроллеров, программируемых логических контроллеров, микроконтроллеров и прочих вычислительных устройств с архитектурой, оптимизированной для использования в сфере автоматизации;

· Операционных систем (ОС) реального времени, таких как QNX, OS-9, VxWorks и пр.;

· SCADA-пакетов и инструментальных сред типа LabVIEW;

· «языков реального времени», к которым относят языки, обладающие встроенными возможностями многозадачного программирования, например Modula-2 и Ada;

· оборудования УСО, обладающего предсказуемыми временными характеристиками (мультиплексоров, ЦАП и АЦП и пр.);

· «индустриальных СУБД»;

· «промышленных» шин, интерфейсов и протоколов для построения распределенных автоматизированных систем (RS-485, RS-422, RS-232, Profibus, CANBus, VMEbus, IndustrialEthernet, IEEE-488 и т.п.);

· специальных алгоритмов[1].

 

1.4. Распределение задач по времени (планирование выполения).

Большинство ОС реального времени распределяют задачи по времени выполнения, используя схему, называемую планирование с приоритетным прерыванием работы (priority-based pre-emptive scheduling).Каждой задаче прикладного ПО должен быть присвоен приоритет, при этом, чем выше значение приоритета, тем выше

Рис.3 Приоритет выполнения задач

необходимость в немедленном выполнении задачи. Немедленное выполнение достигается за счет приоритетной природы распределения задач. Это означает, что планировщик может остановить любую задачу в любой момент ее выполнения, если он определит, что другая задача, обладающая более высоким приоритетом, требует немедленного запуска. Другими словами, если одновременно готовы к выполнению задачи с высоким и низким приоритетом, планировщик вначале разрешит выполнение задачи с высоким приоритетом. Задача с низким приоритетом начнет работу только после того, как задача с высоким приоритетом закончит свою текущую работу.
А что если задача с низким приоритетом уже начала работу, и затем появилась задача с высоким приоритетом, готовая к выполнению? Подобная ситуация может произойти при внешнем инициировании, к примеру, при переключении ключа. Планировщик с приоритетным прерыванием работы будет действовать следующим образом: он позволит задаче с низким приоритетом завершить выполнение текущей ассемблерной команды (но он не будет ждать выполнения целой строки кода, написанной на языке высокого уровня, так же, как и не будет ждать до следующего сигнала таймера.) Затем он остановит работу задачи с низким приоритетом и разрешит выполнение задачи с высоким приоритетом. После того, как задача с высоким приоритетом закончит текущую работу, будет продолжено выполнение задачи с низким приоритетом (см. рис. 2).
Конечно, пока выполняется задача с высоким приоритетом, может появиться задача с еще более высоким приоритетом, готовая к работе. В таком случае выполнение текущей задачи будет приостановлено (временно), чтобы начать выполнение задачи с более высоким приоритетом. После того, как эта задача выполнит свою текущую работу, приостановленной задаче будет разрешено продолжить свою работу. И, следовательно, в таком случае, обе задачи с высоким приоритетом закончат свою работу, перед тем как задаче с низким приоритетом разрешат продолжить выполнение. Подобный сценарий может быть назван гнездовым прерыванием работы.
Каждый раз, когда при внешней инициализации (например, при переключении ключа) или при программной инициализации (например, при появлении сообщения) приводится в состояние готовности планировщик с приоритетным прерыванием работы, он должен пройти следующие 5 шагов:
• определить, должна ли выполняемая в настоящее время задача продолжать работу. Если нет, то перейти к следующему пункту;
• определить, какая из задач должна выполняться следующей;
• сохранить условия работы остановленной задачи (чтобы можно было продолжить ее выполнение позже);
• выставить необходимые условия выполнения задачи, которая будет запущена следующей;
• разрешить выполнение этой задачи.

 

Операционные системы реального времени

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

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

• Поддержка и организация выполнения всех задач;
• Управление прерываниями;
• Реализация взаимодействия процессов в системе;
• Запуск задач в назначенные моменты времени.

Из особенностей СРВ следует, что ОСРВ должна отличаться от универсальных ОС.

Табл.1 Основные отличия операционных систем реального времени от универсальных ОС

Универсальные ОС ОС реального времени Назначение • эффективное управление ресурсами, • предоставление удобного интерфейса; • создание СРВ, • управление СРВ • обеспечение функционирования СРВ Состав Набор готовых приложений Инструмент для создания аппаратно-программного комплекса СР Пользователи Пользователи приложений Проектировщики, разработчики

 

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

Наиболее ранним и распространенным стандартом ОСРВ является стандарт 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 [OSEK], который первоначально развивался для систем автомобильной индустрии.

POSIX

Стандарт POSIX был создан как стандартный интерфейс сервисов операционных систем. Этот стандарт дает возможность создавать переносимые приложения. Впоследствии этот стандарт был расширен особенностями режима реального времени [POSIX].

Спецификации POSIX задают стандартный механизм взаимодействия приложения и ОС. Необходимо отметить, что стандарт POSIX тесно связан с ОС Unix; тем не менее, разработчики многих ОСРВ стараются выдержать соответствие этому стандарту. Соответствие стандарту POSIX для ОС и аппаратной платформы должно быть сертифицировано с помощью прогона на них тестовых наборов [POSIXTestSuite]. Однако, если ОС не является Unix-подобной, выдержать это требование становится непростой задачей. Тестовые наборы существуют только для POSIX 1003.1a. Поскольку структура POSIX является совокупностью необязательных возможностей, поставщики ОС могут реализовать только часть стандартного интерфейса, и при этом говорить о POSIX-комплиантности своей системы.

Несмотря на то, что стандарт POSIX вырос из Unix’а, он затрагивает основополагающие абстракции операционных систем, а расширения реального времени применимы ко всем ОСРВ.

К настоящему времени стандарт POSIX рассматривается как семейство родственных стандартов: IEEE Std 1003.n (где n – это номер).

Стандарт 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) касается функций поддержки многопоточной обработки внутри процесса – управление потоками, планирование с учетом приоритетов, мьютексы (специальные синхронизирующие объекты в межпроцессном взаимодействии, подающие сигнал, когда они не захвачены каким-либо потоком), приоритетное наследование в мьютексах, переменные состояния (condition variables).

Стандарт 1003.1d включает поддержку дополнительных расширений реального времени – семантика порождения новых процессов (spawn), спорадическое серверное планирование, мониторинг процессов и потоков времени выполнения, таймауты функций блокировки, управление устройствами и прерываниями.

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

Стандарт 1003.2h касается сервисов, отвечающих за работоспособность системы.

Табл. 2. Семейство стандартов POSIX

Стандарт	Краткое описание
POSIX.0	Введение в стандарт открытых систем. Данный документ не является стандартом в чистом виде, а представляет собой рекомендации и краткий обзор технологий
POSIX.1	Система API (язык Си)
POSIX.2	Оболочки и утилиты (одобренные IEEE)
POSIX.3	Тестирование и верификацция
POSIX.4	Задачи реального времени и потоки
POSIX.5	Использование языка ADA применительно к стандарту POSIX.1
POSIX.6	Системная безопасность
POSIX.7	Администрирование системы
POSIX.8	Сети. «Прозрачный» доступ к файлам. Связь системы с протоколо-зависимыми приложениями. Вызов удаленных процедур
POSIX.9	Использование языка FORTRAN применимо к стандарту POSIX.1
POSIX.10	Профиль прикладной среды организации вычислений на супер-ЭВМ (APE)
POSIX.11	Обработка транзакции AEP
POSIX.12	Графический интерфейс пользователя (GUI)

 

DO-178B

Стандарт DO-178B, создан Радиотехнической комиссией по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для разработки ПО бортовых авиационных систем [DO178B]. Первая его версия была принята в 1982 г., вторая (DO-178A) - в 1985-м, текущая DO-178B - в 1992 г. Готовится принятие новой версии, DO-178C. Стандартом предусмотрено пять уровней серьезности отказа, и для каждого из них определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьезности.

Данный стандарт определяет следующие уровни сертификации:

• А (катастрофический),
• В (опасный),
• С (существенный),
• D (несущественный)
• Е (не влияющий).

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

ARINC-653

Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработан компанией ARINC в 1997 г. Этот стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным ПО. Требования к интерфейсу между прикладным ПО и сервисами операционной системы определяются таким образом, чтобы разрешить прикладному ПО контролировать диспетчеризацию, связь и состояние внутренних обрабатываемых элементов. В 2003 г. принята новая редакция этого стандарта. ARINC-653 в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин.

OSEK

Стандарт 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 ошибочно воспринимается как стандарт ОСРВ. Хотя ОС и есть большая порция данного стандарта, мощность его состоит в интеграции всех его компонент.

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

ОСРВ

⇐ Предыдущая123456789Следующая ⇒

Поделиться: