
- •Введение
- •Глава 1. Основные принципы организации операционных систем реального времени
- •1.1. Общие положения и определения
- •1.2. Отличие механизма современных осрв
- •1.3. Параметры осрв
- •1.4. Программное обеспечение многозадачности ос
- •1.5. Архитектура осрв. Классы осрв
- •1.6. Синхронизация задач
- •1.7. Базовые понятия программного обеспечения реального времени
- •1.8. Асинхронный обмен данными
- •1.9. Надежность систем реального времени
- •1.10. Планирование задач
- •1.11. Планирование периодических процессов
- •1.12. Взаимоблокировки
- •Контрольные вопросы
- •Глава 2. Типовые операционные системы реального времени
- •2.1. Обзор систем реального времени
- •2.2. Операционная система Windows nt
- •2.2.1. Ужесточение требований к ос 90-х годов
- •2.2.2. Операционные системы реального времени и Windows nt
- •2.2.3. Процессы и потоки nt
- •2.2.4. Пути расширения реального времени для nt
- •2.2.5. Обработка прерываний и исключений
- •2.2.6. Особенности системы ввода/вывода системы nt
- •2.2.7. Windows nt как операционная система реального времени
- •2.2.8. Расширения Windows nt
- •2.3. Операционная система qnx
- •2.3.1. Общие положения
- •2.3.2. Системная архитектура qnx
- •2.3.3. Qnx как сеть
- •2.3.5. Оконная система Photon microGui
- •2.3.6. Phocus 4 для создания встраиваемых scada
- •2.4. Операционные системы реального времени для встраеваемых систем
- •2.5. Ос рв для встраиваемых модулей от компании Microsoft
- •2.6. Функциональные потребности scada-системы
- •Контрольные вопросы
- •Глава 3. Общий анализ контроллеров
- •3.1. Аппаратное обеспечение
- •3.2. Программирование plc
- •3.3. Выбор контроллерных средств
- •3.4. Классификация современных контроллеров
- •3.5. Взаимодействие компонентов
- •3.6. Проектирование распределенных систем управления
- •3.7. Открытая модульная архитектура контроллеров
- •3.8. Архитектура производственной базы данных реального времени
- •3.9. Эволюция стандарта pci для жестких встраиваемых приложений
- •3.11. Одно- и многоуровневые системы диспетчерского контроля и управления
- •3.12. Технологии и протоколы передачи данных в промышленности: Industrial Ethernet
- •3.13. Обеспечение надежности асу тп с использованием резервированного кольца Turbo Ring
- •3.14. Анализ архитектур контроллеров с параллельной шиной
- •3.15. Повышенные требования к устойчивости функционирования
- •Контрольные вопросы
- •Глава 4. Примеры реализации типовых контроллеров
- •4.1. Промышленные контроллеры для автоматизации технологических процессов
- •4.2. Модули adam-8000 от компании Advantech9 и система программирования adam-winplc7
- •4.3. LabView Real-Time LabView реального времени
- •4.4. Встраиваемые системы и ос для них
- •4.5. Промышленный контроллер р-130isa
- •4.6. Совместное использование hmi и pac
- •4.7. Система Реального Времени cf-mntr
- •4.8. Экономичные контроллеры Pico
- •4.9. RapidIo: технология для приложений реального времени
- •4.10. Trace mode 6 и t-factory 6: обзор исполнительных модулей
- •4.11. Контроллер Crestron cp2e
- •4.12. Асу тп на базе контроллеров micro-pc
- •4.14. Itv ndc-f18 – универсальные контроллеры ndc-f18
- •4.15. Сетевой контроллер компании Lenel для систем контроля доступа
- •4.16. Сетевой контроллер реального времени
- •Контрольные вопросы
- •Глава 5. Мультимедийные системы реального времени
- •5.1. Требования реального времени в системах мультимедиа
- •5.2. Требования к архитектуре мультимедиа-систем
- •5.3. Объединение графического и мультимедийного ядра в систему Freescale
- •5.5. Scsa: архитектура для систем мультимедиа реального времени
- •Контрольные вопросы
- •Заключение
- •Рекомендуемый библиографический список
- •Оглавление
- •Глава 1. Основные принципы организации операционных систем реального времени 6
- •Глава 2. Типовые операционные системы реального времени 55
- •Глава 3. Общий анализ контроллеров 179
- •Глава 4. Примеры реализации типовых контроллеров 236
- •Глава 5. Мультимедийные системы реального времени 292
- •Системы реального времени Программно-технический комплекс
- •346428, Г. Новочеркасск, ул. Просвещения, 132
2.2. Операционная система Windows nt
2.2.1. Ужесточение требований к ос 90-х годов
Осенью 1988 года Microsoft пригласила на работу Дэвида Н. Катлера (David N. Cutler), чтобы возглавить новый проект создания ОС Microsoft 90-х годов. В результате анализа проблемы были сформулированы основные требования, предъявляемые рынком к новой ОС:
Переносимость позволило бы быстро переходить от одной архитектуры к другой.
Мультипроцессорная обработка и масштабируемость ОС позволило бы запускать одно и то же приложение как на однопроцессорных, так и на многопроцессорных машинах. В предельном случае несколько приложений выполняют с максимальной скоростью, а приложения, требующие большого объема вычислений, повышают производительность, распределяя работу между несколькими процессорами.
Распределенные вычисления в сети позволили малым компьютерам связываться друг с другом, совместно используя аппаратные или вычислительные ресурсы (в форме файл-серверов, серверов печати и серверов вычислений).
Совместимость с POSIX. Во второй половине 80-х годов стали определять POSIX (переносимый интерфейс ОС, основанный на UNIX” (portable operating system interface basic on UNIX)) в качестве международного стандарта программного обеспечения для интерфейсов ОС UNIX-типа. Стандарт POSIX (стандарт IEEE 1003.1-1988) поощряет фирмы, реализующие UNIX-подобные интерфейсы, делать их совместимыми, чтобы программисты могли легко переносить свои приложения с одной системы на другую.
Для удовлетворения сформулированных требований, предъявляемых рынком к новой ОС, фирма VenturCom разработала подсистему реального времени RTX (Real-Time Extensions) для Windows NT при поддержке Microsoft. Microsoft передала лицензию на исходные тексты такого компонента Windows NT, как Уровень Абстракции Аппаратуры (HAL, Hardware Abstraction Level), который в основном и определяет характеристики ОС по обработке прерываний. RTX добавляет дополнительные вызовы к интерфейсу прикладного программирования (RTAPI, Real-Time API), а также загружает модифицированный HAL, который изолирует аппаратные прерывания от ядра Windows NT. RTX предоставляет для системы таймер реального времени и уменьшает время отклика. RTX обеспечивает для процессов доступ к физическим адресам памяти и портов ввода/вывода, а также специальные методы работы со страничной памятью, исключающие свойственные Windows NT задержки. Соответствующим образом отрабатываются попытки перезагрузки или тяжелые остановы.
2.2.2. Операционные системы реального времени и Windows nt
Процессы в Windows NT принадлежат двум различным классам приоритетов: динамическому и реального времени. Большинство процессов принадлежат динамическому классу, который допускает изменение своих приоритетов ОС в зависимости от таких факторов, как являются ли они фоновыми задачами или они недавно ожидают. Это хорошо для GPOS (General propose OS) , так как позволяет всем потокам быть запущенными и предоставляет пользователям более быструю реакцию от активного приложения. Однако правила, определяющие эти изменения приоритетов, не подходят для RTOS (real-time OS). Поэтому Microsoft включила ряд приоритетов выше динамического класса, назвав их (Real-Time Class) класс приоритетов реального времени. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, а приоритет процессов динамического класса может меняться диспетчером. В Windows NT имеется только 7 различных уровней для нити в данном процессе. А у большинства ОСРВ имеется по крайней мере 256 различных уровней (чем больше имеется уровней, тем более предсказуемо поведение системы). В Windows NT многие нити будут выполняться с одинаковыми приоритетами, то есть предсказуемость поведения системы будет посредственной. В Windows NT процессы выполняются в своем собственном пространстве памяти. Добиться этого позволяют механизмы виртуальной памяти и подкачки. Это для СРВ порождает непредсказуемость, особенно если система отправит страницу из памяти на диск.
Потоки, запущенные с этими приоритетами, выполняются до процессов, запущенных с приоритетами из динамического класса. ОС не изменяет их приоритет и определяет большой контроль за разработчиком. Microsoft не рекомендует, чтобы потоки тратили много времени в этом классе, так как они имеют приоритет выше, чем некоторые системные задачи, такие, как сброс кэша диска и контроль ввода. Блокировка инверсии приоритетов происходит в потоках, ожидающих мьютекса. Большинство RTOS решают эту проблему путем инверсии приоритетов, но Windows NT использует схему, где потоки, которые не запускаются некоторое время, принимают случайный приоритет, повышая возможность быть запущенным. Это приводит к непредсказуемости и поэтому неприемлемо для СРВ.
Базовая идея построения Windows NT основана на принципах модульности и объектно-ориентированного программирования. Эта идея распространена и на ядро ОС и определяет ее функциональную независимость от аппаратуры для чего используют уровень абстрагирования от аппаратуры (hardware abstraction layer, HAL). Структура Windows NT включает две части: одна работает в пользовательском режиме (защищенные подсистемы Windows NT), а другая – в режиме ядра (исполнительная система NT) (рис. 2.3).
|
Рис. 2.3. Блок схема Windows NT |
Серверы Windows NT называются защищенными подсистемами (protected subsystems), так как каждый из них – это отдельный процесс, память которого защищена от других процессов системой виртуальной памяти исполнительной системы NT. Так как совместное использование памяти подсистемами не реализуется автоматически, то коммуникации между ними осуществляются путем передачи сообщений. Термин "сервер" подразумевает, что каждая защищенная подсистема обеспечивает API, который могут использовать программы. Когда приложение (или другой сервер) вызывает некоторую процедуру API, серверу, реализующему данную процедуру, посылается сообщение при помощи средства локального вызова процедур (local procedure call, LPC) – оптимизированного механизма исполнительной системы NT для локальной передачи сообщений. Сервер же посылает ответное сообщение, вызывающее программу.
В Windows NT имеется два типа защищенных подсистем: подсистемы среды (environment subsystems) и неотъемлемые подсистемы (integral subsystems). Подсистема среды – это сервер пользовательского режима, реализующий API некоторой ОС. Когда приложение вызывает функцию API, этот вызов доставляется посредством LPC подсистеме среды. Та исполняет вызов и возвращает результаты прикладному процессу, посылая другой LPC.
Самая важная подсистема среды в Windows NT – это подсистема Win32, которая предоставляет прикладным программам API 32-разрядной Windows и реализует графический интерфейс пользователя Windows NT и управляет всем вводом пользователя и выводом приложений. В Windows NT имеются подсистемы среды POSIX, OS/2, 16-разрядной Windows и MS-DOS. Данные подсистемы предоставляют свои API, но используют для получения пользовательского ввода и отображения результатов подсистему Win32.
Другие защищенные подсистемы – неотъемлемые подсистемы – это серверы, выполняющие важные функции ОС. Подсистема защиты исполняется в пользовательском режиме и регистрирует правила контроля доступа, определенные для локального компьютера, ведет базу данных учетных записей пользователей, содержащую идентификаторы пользователей, пароли, группы, к которым отнесен пользователь, и особые привилегии, которыми он обладает. Она также принимает регистрационную информацию пользователя и инициирует аутентификацию подключения пользователя к системе.
Некоторые компоненты сетевого обеспечения Windows NT также реализованы как защищенные подсистемы: сервис рабочей станции и сервис сервера. Каждый из этих сервисов (services), как часто называют сетевые подсистемы, является процессом пользовательского режима, реализующим API для доступа и управления, соответственно, сетевым редиректором4 и сервером LAN Manager. На удаленной машине такие запросы принимаются сервером. И редиректор, и сервер LAN Manager реализованы как драйверы файловых систем, т. е. являются частью системы ввода/вывода NT.
Исполнительная система NT (NT executive) – это часть Windows NT, исполняющаяся в режиме ядра; за исключением пользовательского интерфейса, она сама по себе является законченной ОС. Исполнительная система состоит из ряда компонентов, причем каждый из них реализует два набора функций: системные сервисы, к которым могут обращаться как подсистемы среды, так и компоненты исполнительной системы, а также внутренние процедуры, доступные только компонентам исполнительной системы. Исполнительная система NT способна поддерживать любое число серверных процессов. Серверы предоставляют исполнительной системе NT пользовательские и программные интерфейсы, а также обеспечивают среды для выполнения приложений разных типов.
Хотя исполнительная система и предоставляет системные сервисы, похожие на API, она отличается от подсистем среды. Исполнительная система не исполняется постоянно в собственном процессе, а работает в контексте некоторого существующего процесса, завладевая выполняющимся потоком, когда происходит важное системное событие. Компоненты исполнительной системы поддерживают независимость друг от друга, для чего каждый из них создает необходимые системные структуры данных и работает с ним. Интерфейсы между компонентами контролируются, можно удалить компонент и заменить другим, работающим иначе. Если новый компонент корректно реализует все системные сервисы и внутренние интерфейсы, то ОС работает как прежде. Сопровождение ОС также упрощается, поскольку компоненты исполнительной системы NT взаимодействуют предсказуемым образом.
Основные компоненты исполнительной системы и их области ответственности:
Диспетчер объектов создает, поддерживает и уничтожает объекты исполнительной системы NT – абстрактные типы данных, представляющие системные ресурсы.
Справочный монитор защиты гарантирует выполнение политики защиты на локальном компьютере, оберегает ресурсы ОС, обеспечивая защиту объектов и аудит во время выполнения.
Диспетчер процессов создает и завершает процессы и потоки, а также приостанавливает и возобновляет исполнение потоков, хранит и выдает информацию о процессах и потоках NT.
Средство локального вызова процедур (LPC) передает сообщения между клиентскими и серверными процессами, расположенными на одном и том же компьютере. LPC – это гибкая, оптимизированная версия удаленного вызова процедур (remote procedure call, RPC), средства коммуникации между клиентскими и серверными процессами по сети, являющегося промышленным стандартом.
Диспетчер виртуальной памяти реализует виртуальную память (virtual memory, VM) – схему управления памятью в виде подкачки страниц (paging), которая предоставляет каждому процессу большое собственное адресное пространство и защищает это пространство от других процессов. Если память используется интенсивно, то диспетчер виртуальной памяти переносит содержимое выбранного блока памяти на диск и загружает обратно, когда он снова понадобится.
Ядро реагирует на прерывания и исключения, направляет потоки на выполнение, выполняет межпроцессорную синхронизацию и предоставляет набор элементарных объектов и интерфейсов, используемый остальными частями исполнительной системы NT для реализации объектов более высокого уровня.
Система ввода/вывода состоит из группы компонентов, отвечающих за выполнение ввода/вывода на разнообразные устройства. В систему ввода/вывода входят следующие подкомпоненты:
Диспетчер ввода/вывода реализует средства ввода/вывода, не зависящие от типа устройства, и устанавливает модель для ввода/вывода исполнительной системы NT .
Файловые системы образуют драйверы NT, принимающие запросы файлового ввода/вывода и транслирующие их в запросы, привязанные к конкретному устройству.
Сетевой редиректор (network redirector) и сетевой сервер (network server) это драйверы файловой системы, передающие удаленные запросы ввода/вывода на машины в сети и принимающие от них такие запросы.
Драйверы устройств исполнительной системы NT. Низкоуровневые драйверы, напрямую работающие с оборудованием для записи вывода или считывания ввода с физических устройств или с сети.
Диспетчер кэша повышает производительность файлового ввода/вывода, сохраняя информацию, считанную с диска последней, в системной памяти, использует средство подкачки страниц диспетчера виртуальной памяти для автоматической записи информации на диск в фоновом режиме.
Слой абстрагирования от оборудования (HAL) это кодовая прослойка между исполнительной системой NT и аппаратной платформой, на которой работает ОС. Она скрывает аппаратно-зависимые детали, такие как интерфейсы ввода/вывода, контроллеры прерываний и механизмы межпроцессорных связей. Чтобы обращаться к аппаратуре непосредственно, исполнительная система NT сохраняет максимальную переносимость, обращаясь к функциям HAL, когда ей нужна платформенно-зависимая информация.
Windows NT – это переносимая ОС с ограничением объема кода, который зависит от конкретной архитектуры оборудования. Код, зависящий от платформы, т. е. от способа реализации производителем, располагается в HAL и поставляется с компьютером. Драйверы устройств содержат код, зависящий от устройства, но избегают кода, зависящего от процессора или платформы, вызывая процедуры ядра NT и HAL.