Программно-технический комплекс Учебное пособие Новочеркасск юргту (нпи) 2010. Удк 519. 23 (075. 8) Ббк 22. 17я73

Вид материалаУчебное пособие

Содержание


Контрольные вопросы
ГЛАВА 2. ТИПОВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ 2.1. Обзор систем реального времени
QNX, Linux
Linux, требует внесения некоторых изменений в ПО обеих систем. Часть изменений, связанных с интеграцией высокоприоритетного ядра
OS-9 имеет самый широкий набор файловых менеджеров по сравнению с другими ОСРВ. Базовые файловые менеджеры OS
X.25 и LAP-B
MAUI содержит расширенный набор протоколов API
Sgi iris/
OEM; более 800 OEM
VxWorks и системные библиотеки, GNU C
Подобный материал:
1   ...   8   9   10   11   12   13   14   15   ...   52

Контрольные вопросы




  1. Необходимые требования к ОС для обеспечения предсказуемости.
  2. ОСРВ с монолитной архитектурой.
  3. ОСРВ на основе микроядра.
  4. Объектно-ориентированная ОСРВ?
  5. Дайте определение алгоритма планирования?
  6. В каких случаях необходима синхронизация?
  7. Что такое связанные задачи?
  8. Что такое ресурс?
  9. Что такое критические секции?
  10. С какими проблемами можно столкнуться в борьбе за ресурсы?
  11. Что такое асинхронное взаимодействие? Преимущества и недостатки.
  12. Что такое прерывание? Как оно работает?
  13. Методы обработки прерываний в ОСРВ?
  14. Как осуществляется аппаратная защита памяти?
  15. Что такое исключение?
  16. Что такое утечка памяти?
  17. Как обрабатываются исключения в ядре ОС?
  18. Чем характеризуется надежность ОСРВ?





ГЛАВА 2. ТИПОВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

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


На рынке сейчас имеются следующие типы ОС РВ:

Исполнительные системы реального времени. Признаки систем этого типа – разные платформы для систем разработки и исполнения. Приложение реального времени разрабатывается на хост-компьютере, затем компонуется с ядром и загружается в целевую систему для исполнения. Приложение реального времени – это одна задача, и параллелизм здесь достигается с помощью нитей. Системы такого типа обладают рядом достоинств, среди которых главные – скорость и реактивность. Высокая реактивность в основном обусловлена наличием только нитей и малым временем переключения их контекстов (в отличие от процессов). Главные достоинства уравновешивает ряд недостатков: зависание всей системы при зависании нити, проблемы с динамической подгрузкой новых приложений. Наиболее яркий представитель систем этого класса – ОС VxWorks. Область их применения – компактные СРВ с хорошим временем реакции.

Ядра реального времени. В класс входят системы с монолитным ядром, где и содержится реализация механизмов реального времени. Эти системы модульны, хорошо структурированы, имеют развитый набор специфических механизмов реального времени, компактны и предсказуемы. Самые популярные системы: OS-9, QNX. Особенность продуктов этого класса – высокая степень масштабируемости. На их базе строят как компактные СРВ, так и большие системы серверного класса, а их ядра имеют два типа систем разработки – кроссовую и резидентную.

Клоны UNIX реального времени. Исторически СРВ создавались в эпоху расцвета ОС UNIX, поэтому многие из них содержат те или иные заимствования из этой ОС (пользовательский интерфейс, концепция процессов и т.д.). Часть разработчиков ОС РВ попыталась просто переписать ядро UNIX, сохранив при этом интерфейс пользовательских процессов с системой, насколько это было возможно. Получили и реальное время, и сразу весь набор пользовательских приложений – компиляторы, пакеты, различные инструментальные системы. Однако семейство Unix реального времени не лишено недостатков: СРВ получаются достаточно большими и менее реактивными, чем системы первых двух классов. Наибольшим спросом пользуется ОС РВ Lynx OS.

Расширения реального времени для NT. Появление новых программных технологий, таких, как OPC (OLE-For Рrocess Control), говорит о тенденциях разделения функций СРВ по уровням. Системы первых двух классов с появлением на рынке Windows NT не испытают никакого давления, поскольку область их применения – компактные, встроенные приложения жесткого реального времени на контроллерах различной архитектуры (среди которых и Intel). Представляется маловероятным сколько-нибудь широкая замена этих систем на Windows NT. На это есть несколько причин:

а) небольшое количество архитектур, поддержанных Windows NT;

б) невозможность построения компактной системы (контроллер должен содержать электронный диск во Flash-памяти объемом не менее 10 Мбайт и оперативную память не менее 16 Мбайт);

в) в приложениях жесткого реального времени используют только один комплект расширений – дополнительное ядро реального времени;

г) бедный набор механизмов межзадачной коммуникации.

Иначе обстоят дела с большими СРВ. Традиционно эту нишу занимали клоны UNIX реального времени и масштабируемые системы первых двух классов. Эти системы обычно используются, когда нет жестких требований к реальному времени или когда система содержит только отдельные критические участки. Часто UNIX реального времени применяется в тех приложениях, где система требует развитых сетевых возможностей или возможностей архивирования данных. В этом смысле истории появления клонов UNIX реального времени и расширений реального времени для Windows NT удивительно похожи. Основная идея создания UNIX РВ заключалась в том, чтобы перенести на уровень управляющих систем наиболее мощную на тот момент программную технологию – с развитым программным интерфейсом (POSIX), изобилием разнообразных приложений и большим количеством квалифицированных специалистов.

Расширения реального времени Windows NT имеют те же слабые стороны, что и UNIX РВ: невозможность построения компактных систем и множество недостатков при работе в реальном времени.

В настоящее время имеется более 60 ОСРВ. Версии ОС UNIX, являясь широко распространенными в научной и технической сферах, были в конце 70-х – начале 80-х годов адаптированы к задачам РВ. Причем первоначально UNIX системы не требовали лицензии. Но затем ситуация изменилась. Это стало стимулом для таких крупных фирм, как IBM, DEC, HP, отреагировать на данное событие путем создания OSF, которая предназначалась для создания ОСРВ с тем, чтобы не зависеть от одного или единственного поставщика ОСРВ (UNIX). Эта организация разработала ряд программных средств по ОСРВ, основной из которых была система OSF/1. Вместе с тем широкое распространение персональных компьютеров обусловило широкую популярность ОС MS DOS и Windows. MS DOS имела ограниченное использование для задач ОСРВ, а Windows (особенноWindows NT) имеет достаточно развитые механизмы ОСРВ: управление потоками, семафоры и, что особенно важно, механизмы, поддерживающие безопасную и отказоустойчивую работу СРВ. Специально в качестве ОСРВ были созданы:
    1. OS9 (написана на С для микропроцессорных наборов фирмы Motorola);
    2. WAX/VMS (написана для процессоров WAX фирмы DEC);
    3. QNX (разработана канадской фирмой QNX Soft Where System).

Простейшие ОСРВ (OSIK или RTX) предоставляют только базовые средства по диспетчеризации задач и обработке прерываний. Подобные базовые системы не поддерживают стандартных интерфейсов разработки ПО, зафиксированных в POSIX, и не предоставляют механизмов защиты памяти. Достоинствами базовых ОСРВ являются компактность, открытость исходного кода и обеспечение гарантированного времени реакции системы. Недостатками таких ОСРВ являются: низкая масштабируемость; сложность интеграции компонентов системы в единое целое; сложность повторного использования приложений, разработанных для других проектов; ограниченность средств отладки.

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

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




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

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




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

Иногда приходится иметь дело с эффектом инверсии приоритетов в области обработчика прерывания Linux и задач ОСРВ.

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

OS-9 относится к классу UNIX подобных, гибко конфигурируемой высокопроизводительной ОСРВ и предлагает к использованию многие элементы среды UNIX. Модульность системы означает, что она может быть масштабирована для удовлетворения нужд как встроенных систем, так и больших сетевых приложений. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули создают системы с разной конфигурацией – от миниатюрных автономных ПЗУ ориентированных ядер до полномасштабных многопользовательских систем разработки. Разработка программ ведется в полнофункциональных конфигурациях. После отладки кода программы реального времени отсоединяются модули разработки и ввода/вывода, и код готов к исполнению под управлением ядра в целевой системе.

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

OS-9 имеет самый широкий набор файловых менеджеров по сравнению с другими ОСРВ. Базовые файловые менеджеры OS-9 предназначены для организации обмена информацией между процессами и обеспечивают приложениям OS-9 доступ к различным последовательным устройствам типа принтеров и терминалов, а также к устройствам внешней памяти. Сетевые файловые менеджеры обеспечивают доступ к самым разным сетевым устройствам по протоколу TCP/IP. Файловые менеджеры также поддерживают различные высокоуровневые сетевые протоколы и протоколы передачи файлов.

Модульная структура OS-9 позволяет разработчику выбирать именно те функциональные блоки, которые требуются данному приложению. Любая из опций легко может быть добавлена в систему для обеспечения соответствия изменившимся требованиям к системе. Для поддержки таких сложных приложений, как телекоммуникации, мультимедиа и системы выдачи видеоданных по запросу, фирма Microware разработала ряд дополнительных файловых менеджеров.

Файловый менеджер управления стеком протоколов поддерживает несколько типов коммуникационных протоколов типа X.25 и LAP-B. Он обеспечивает независимую от сети архитектуру для динамической сборки и разработки (stacking and unstacking) модулей протокола и драйверов устройств. В автономной встроенной системе такие приложения и стеки протокола могут быть как резидентными в устройстве, так и загружаться в устройство через сеть.

Пользовательский интерфейс мультимедиа-приложения MAUI содержит расширенный набор протоколов API для соответствия требованиям высокопроизводительных мультимедиа-протоколов либо протоколов пользователя. С данным интерфейсом общаются такие являющиеся промышленным стандартом пакеты, как Apple QuickDraw и QuickTime, Macromedia Director, Oracle Media Objects и Sybase Gain.

ISDN-менеджер рассчитан на глобальные телекоммуникационные приложения: видеоконференции, высокоскоростная факс-связь и мосты между локальными и глобальными сетями. ISDN-менеджер позволяет системе OS-9 осуществлять доступ к Базовому каналу ISDN-сети (Basic Rate Channel). Файловый менеджер для приложений мультимедиа MPFM, соответствующий спецификациям MPEG, рассчитан на использование в различных приложениях мультимедиа, включающих интерактивное телевидение, образование, обучение и выдачу видеоинформации по запросу.

Основные характеристики OS-9:
  • многозадачная (65535 процессов, 65535 уровней приоритета);
  • многопользовательская (256 пользователей);
  • переносимость приложений (ANSI C/C++, POSIX 1003.1, TCP/IP (NFS, RPC), X Windows X11.R6 (OSF Motif)), JAVA;
  • 100% размещение в ПЗУ системы и приложений пользователя;
  • объектно-ориентированный модульный дизайн;
  • полностью вытесняемое детерминированное ядро с минимальным временем реакции на прерывание;
  • многоуровневая, основанная на приоритетах обработка прерываний;
  • развитые сетевые средства (Arcnet, Ethernet, OMNInet, X.25, ISDN T1/E1, ATM NFM, TCP/IP, IPX Profibus, CAN, MIL STD 1553…);
  • графические оконные интерфейсы – GUI;
  • резидентные и кросс-средства разработки, прогрессивная технология высокооптимизирующего ANSI C/C++ компилятора;
  • поддержка host-систем (IBM PC (MS Windows 3.xx, 95, NT), IBM RS6000/AIX, Sun4/SunOS/Solaris, HP9000 S/700, SGI IRIS/IRIX);
  • широкая поддержка сторонних разработчиков программного обеспечения;
  • широкая поддержка разработчиков аппаратных средств промышленной автоматизации;
  • программные продукты для <<вертикальных>> рынков (мобильная беспроводная коммуникация, устройства с минимальным потреблением энергии, мультимедиа);
  • специальные программные средства и лицензионная политика для OEM;
  • более 800 OEM-партнеров.

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

VxWorks поддерживает целевые архитектуры (targets): Motorola 680x0 и CPU32, Intel 386/486/Pentium/.., Intel 960, SPARC, MIPS R3000/4000, ARM, Motorola 88110, HP PA-RISC, Hitachi SH7600, PowerPC, DEC Alpha, Siemens C16x. Инструментальные платформы, поддерживаемые для Tornado (hosts): Sun SPARCstation (SunOS и Solaris), HP 9000/400,700 (HP-UX), IBM RS6000 (AIX), Silicon Graphics (IRIX), DEC Alpha (OSF/1), PC (Windows 95 и NT). Поддерживаемые интерфейсы host-target: Ethernet, RS-232, внутрисхемный эмулятор ICE (In-Circuit Emulator), кросс-шина (backplane), ROM-эмулятор, BDM-интерфейс (Background Debug Mode).

Инструментальная среда Tornado имеет открытую архитектуру, что позволяет другим фирмам-производителям инструментальных средств разработки ПО реального времени интегрировать свои программные продукты с Tornado. Пользователь может подключать к Tornado свои специализированные средства разработки, а также расширять возможности инструментальных средств фирмы Wind River Systems.

В стандартную конфигурацию Tornado входят ядро VxWorks и системные библиотеки, GNU C/C++ Toolkit, дистанционный отладчик уровня исходного языка CrossWind, оболочка WindSh, конфигуратор BSP WindConfig и др.

IA-SPOX. Это многозадачное ядро реального времени, разработанное компанией Spectron Microsystems, было первой успешной попыткой соединения Windows и жесткое реальное время. IA-SPOX спроектировано в виде набора виртуальных драйверов (VxD), которые работают совместно с ядром Windows 95 на нулевом уровне привилегий процессора (Ring 0). Пользовательские программы, работающие на третьем уровне (Ring 3), могут вызывать функции и процессы реального времени, а также обмениваться данными с ними. IA-SPOX показала свою эффективность в программной реализации синтеза звука, высокоскоростной модемной связи и решения других задач, требующих быстрой и детерминированной реакции системы.

Falcon является развитием известной ОС iRMX. Для этого Intel передала права на эту ОСРВ компании RadiSys для последующей интеграции данного продукта с платформой Windows NT. Выбран стандартный путь лицензирования у Microsoft исходных текстов уровня HAL, с изменением под требования жесткого реального времени.

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

Hyperkernel. Подсистема реального времени для Windows NT фирмы Imagination Systems. Hyperkernel позволяет сочетать высокоскоростные задачи управления, требующие детерминированного времени отклика, и менее критичные приложения типа ПО операторского интерфейса. Microsoft и в этом случае предоставила исходные тексты HAL-уровня и разрешила распространение модифицированных версий.

CF-MNTR объединяет в себе свойства многозадачной СРВ с развитыми коммуникационными возможностями и системы типа SCADA. Коммуникационные возможности системы не накладывают ограничений на оборудование связи и технологические контроллеры. Все аппаратно зависимые свойства оборудования учитываются в простом сетевом драйвере(драйверах) нижнего уровня, создаваемом разработчиками АСУ ТП. Использование СРВ CF-MNTR при разработке и реализации комплексных АСУ ТП позволяет разработчикам применять в качестве аппаратного обеспечения любые средства (контроллеры, линии связи).

Оптимальность реализации многозадачного ядра системы позволяет реализацию детального управления процессами в реальном времени в прикладных программах, работающих под управлением CF-MNTR. Кроме того, система предоставляет разработчикам широкие возможности создания интерфейса взаимодействия с оператором и другие, необходимые средства создания SCADA систем (регистрация и обработка различных событий, управление приоритетами). Отладочные средства, имеющиеся в системе, позволяют оптимизировать процесс реализации комплексной АСУ ТП на всех этапах ее создания (проектирование, макетирование, реализация, наладка). СРВ CF-MNTR имеет высокую безотказность в работе. Возможность использования простых контроллеров и линий связи является одной из принципиальных характеристик системы.

Общая характеристика (для одного узла):

- общее число двоичных датчиков в системе – до 5000 ;

- общее число исполнительных устройств – до 3200;

- число независимых процессов, работающих одновременно до 70;

- максимальное регламентируемое время реакции системы – не более 0,5сек (реальное время до 0,2сек);