
- •Введение
- •Глава 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.6. Особенности системы ввода/вывода системы nt
Ввод/вывод считается сложной областью ОС, в которой сложно применить общий подход и где изобилуют частные методы. Система ввода/вывода исполнительной системы NT – это часть кода ОС, получающая запросы от процессов пользовательского режима и режима ядра и передающая их, в преобразованном виде, устройствам ввода/вывода. Система ввода/вывода имеет три особенности:
– объектная модель – управление пакетами;
– унифицированная модель драйвера;
– асинхронная обработка.
Система ввода/вывода управляется пакетами. Каждый запрос ввода/вывода представляется в виде пакета запроса ввода–вывода. Диспетчер не управляет вводом-выводом, он создает пакет запроса ввода/вывода, передает пакет соответствующему драйверу и удаляет его. Диспетчер предоставляет общие для драйверов устройств процедуры. Драйверы обращаются к этим процедурам во время ввода/вывода. Благодаря объединению общих задач в диспетчере драйверы устройств становятся компактными.
В Windows NT как и в ОС UNIX программы осуществляют ввод-вывод в виртуальные файлы, манипулируя ими посредством файлового объекта. Все источники или приемники ввода/вывода представлены файловыми объектами. Потоки пользовательского режима вызывают базовые сервисы файлового объекта NT для чтения из файла, записи в файл. Диспетчер ввода/вывода преобразует эти запросы к виртуальным файлам в запросы к настоящим файлам, физическим устройствам.
Унифицированная модель. Каждый драйвер – это автономный компонент, который может добавляться к ОС и удаляться из нее. Диспетчер определяет модель драйверов ввода/вывода:
драйверы переносимы и написаны на языках высокого уровня;
операции ввода/вывода управляются пакетами запросов ввода/вывода;
драйверы должны синхронизировать свой доступ к глобальным данным;
драйверы должны корректно восстанавливаться после сбоя питания и запускать процедуру сбора.
Унифицированная модель драйверов позволяет Диспетчеру ввода/вывода не видеть их структуру. Драйверы также могут вызывать друг друга через Диспетчер. Запрос может проходить через много драйверов – Послойная структура.
Асинхронная обработка. Синхронный ввод-вывод – это запрос сервиса, устройство читает данные и передает их программе (ReadFile(), WriteFile()). Прежде чем передать управление вызывающей программе, заканчивается выполнение операций ввода/вывода.
Чтобы использовать асинхронный ввод-вывод, поток должен указать это (overlapped) при открытии описателя. Один из параметров функции CreateFile определяет атрибуты файлов, среди которых есть флаг FILE_FLAG_OVERLAPPED. После начала асинхронного ввода/вывода поток должен позаботиться о том, чтобы не использовать данные этой операции, пока драйвер устройства не завершит ее. Чтобы процессор не простаивал во время операций ввода/вывода, Диспетчер ввода/вывода предоставляет средства асинхронного ввода/вывода. Асинхронные сервисы позволяют приложению выдавать запрос ввода/вывода и продолжать выполнение, пока устройство передает данные. Треть базовых сервисов NT асинхронно.
Чтение и запись в файл. Поток, вызывающий эти сервисы должен синхронизировать свое выполнение с их завершением.
Запрос ввода/вывода к однослойному драйверу. Обработка синхронного запроса проходит три этапа:
диспетчер ввода/вывода посылает запрос в форме IPR (пакет запроса) драйверу устройства, который запускает операцию ввода/вывода;
устройство завершает выполнение операции и генерирует прерывание, которое обслуживается драйвером;
диспетчер ввода/вывода завершает обработку запроса.
Обработка асинхронного запроса отличается тем, что между п.1. и п.2 добавляется новый пункт – диспетчер ввода – вывода возвращает управление вызывающей программе. Программа работает до тех пор, пока не выполнится шаг 2 и 3. Но должна синхронизировать свою работу с завершением шага 3.
Посыл запроса. В Windows Nt запрос к принтеру – через подсистему среды, которая вызывает сервис NtWriteFile диспетчера ввода/вывода. Пункт назначения – параллельный порт – указан первым параметром. Подсистема открывает описатель порта и задает синхронный ввод/вывод. Диспетчер ввода/вывода создает IPR, в котором сохраняет указатель на файловый объект и код функции. Далее диспетчер ввода/вывода отыскивает драйвер, вызывает его и передает IPR.
Асинхронный запрос обрабатывается несколько иначе. Новый запрос должен ждать, если принтер занят другими запросами. Драйвер помещает IPR в очередь устройства и возвращает код состояния "ввод/вывод выполняется" вызывающей программе. Приложение выполняет свою работу, пока принтер занят. Так как ввод/вывод выполняется асинхронно, поток приложения не должен изменять содержимое буфера печати, пока принтер не завершит обработку запроса.
Обслуживание прерываний. После завершения передачи данных устройство ввода/вывода генерирует прерывание, и в дело вступает драйвер устройств, ядро NT и диспетчер ввода/вывода.
Когда происходит прерывание от устройства, процессор передает управление ядру, ядро обращается к своей таблице распределения прерываний, чтобы найти процедуру обслуживания прерываний (ISR) для данного устройства. ISR обрабатывает прерывание от устройства в два этапа. Прерывания от устройства имеют высокий уровень IRQL, но ISR остается на этом уровне только на время, необходимое, чтобы запретить новые прерывания от устройства. Затем поток понижает IRQL процессора и завершает обработку прерывания. Когда процессор понижается до уровня DPC , происходит вызов DPC из очереди, закончив работу DPC вызывает диспетчер ввода/вывода для завершения обработки запроса и удаления IPR.
Преимуществом использования DPC является то, что все блокированные прерывания, чей приоритет лежит между IRQL устройства и диспетчерским/DPC, снова разрешаются, прежде чем произойдет более низкое приоритетное прерывание.
Завершение обработки запроса. Завершение ввода/вывода после возврата из DPC и зависит от типа запроса. Все сервисы ввода/вывода записывают результат операции в блок состояния ввода/вывода. Подсистема ввода/вывода копирует данные из системной памяти в виртуальное адресное пространство вызывающего процесса. Это достигается путем посылки потоку APC режима ядра. При возникновении прерывания APC ядро передает управление процедуре APC диспетчера ввода/вывода, которая копирует данные, удаляет IPR запроса и устанавливает описатель файла в состояние "свободен".
Запросы ввода/вывода к многослойным драйверам. К модели добавляются несколько уровней обработки. Диспетчер ввода/вывода получает запрос и создает пакет запроса ввода/вывода. Передает пакет драйверу файловой системы. Драйвер файловой системы может послать драйверу устройства либо то же самое IRP, либо сгенерировать несколько новых и направить их драйверу.
Для поддержки использования пакета несколькими драйверами, расположенными друг над другом, IRP содержит набор областей стека IRP. Каждый драйвер реализует свою часть запроса, используя одну область в стеке. Эти области заполняются по мере передачи IPR от одного драйвера другому. Вместо повторного использования одного IPR, файловая система может создать группу ассоциированных IPR, которые будут работать над одним запросом параллельно.
Особенности использования асинхронного ввода/вывода. При вызове сервисов ввода/вывода NT разработчик определяет, вызывать ли их синхронно или асинхронно. Для операций, которые выполняются быстро за определенный интервал времени предпочтителен синхронный ввод-вывод. Асинхронный ввод-вывод дает наибольшее преимущество тогда, когда выполнение операций велико и очень непостоянно.
Асинхронный ввод-вывод требует большого внимания при разработке, но может дать повышение производительности. Поток, использующий асинхронным ввод-вывод, не задерживается на время пересылки данных. Однако он должен синхронизировать использование передаваемых данных с момента завершения передачи устройством.
Выполняя асинхронный ввод-вывод, код пользовательского режима может использовать для такой синхронизации один из нескольких объектов исполнительной системы. Файловые объекты поддерживают синхронизацию, так что самым простым способом является ожидание у описателя файла в некоторой точке после выдачи запроса ввода/вывода. Когда передача данных закончена, диспетчер ввода/вывода устанавливает описатель файла в состояние "свободен", и выполнение ожидающего потока возобновляется.
Послойная модель драйвера. Структура драйвера. Дисковод гибких дисков, жесткий диск, подключенный к шине SCSI, графический дисплей, файловая система FAT и сетевая плата – это радикально отличающиеся друг от друга "устройства", но для диспетчера ввода – вывода между ним практически нет разницы. Каждый драйвер NT содержит следующий стандартный набор компонентов (или его часть):
Процедура инициализации. Диспетчер ввода/вывода исполняет ее при загрузке драйвера в ОС. Эта процедура создает системные объекты, используемые диспетчером для распознавания драйвера и доступа к нему.
Набор процедур распределения. Процедуры распределения – это главные функции, предоставляемые драйверами устройств: чтения, записи и другие, поддерживаемые устройством, файловой системой или сетью. Когда диспетчер ввода – вывода получает запрос на выполнение некоторой операции, он генерирует IRP и обращается к драйверу через одну из процедур распределения драйвера.
Процедура запуска ввода – вывода. Драйвер использует эту процедуру для начала передачи данных на устройство или от него.
ISR. Диспетчер прерывании ядра передает управление этой процедуре при получении прерывания от устройства. В модели ввода/вывода NT процедуры обслуживания прерываний выполняются на высоком IRQL и выполняют как можно меньший объем работы, чтобы избежать излишнего блокирования низкоуровневых прерываний. Для выполнения оставшейся части обработки прерывания ISR генерирует DРС, который выполняется при меньшем IRQL.
Процедура DРС для обслуживания прерывания. После выполнения ISR эта процедура выполняет большую часть работы по обслуживанию прерывания. Она исполняется на более низком IRQL, чем ISR, чтобы избежать ненужного блокирования других прерываний. Процедура DРС инициирует завершение ввода – вывода и запускает следующий запрос из очереди на обработку устройством.
Процедура завершения. Драйвер верхнего уровня может определить процедуру завершения, вызов которой будет уведомлять его о завершении обработки IRP драйвером нижнего уровня. Например, диспетчер ввода/вывода вызывает процедуру завершения файловой системы после того, как драйвер устройства закончит выполнение чтения или записи файла. Процедура завершения информирует файловую систему об успешном окончании, сбое или отмене операции и позволяет последней выполнить необходимую очистку.
Процедура отмены ввода/вывода. Если имеется возможность отмены операции ввода/вывода, то драйвер может определить одну или несколько процедур отмены. Используемая процедура может изменяться в зависимости от того, насколько далеко продвинулось выполнение операции ввода/вывода. Информация о процедуре отмены, активной в данный момент времени, хранится в IRP.
Процедура выгрузки. Эта процедура освобождает системные ресурсы, которыми пользовался драйвер, чтобы диспетчер ввода/вывода мог удалить его из памяти. Драйвер может загружаться и выгружаться в процессе работы системы.
Процедуры протоколирования ошибок. Когда возникает неожиданная ошибка, процедура протоколирования ошибок отмечает этот факт и уведомляет о нем диспетчера ввода/вывода, который записывает соответствующую информацию в файл журнала ошибок.
Объект – драйвер и объект – устройство. Когда поток открывает описатель файлового объекта, диспетчер ввода/вывода по имени этого объекта определяет к какому драйверу он должен обратиться для обработки запроса. Для этого используют следующие объекты:
Объект-драйвер, представляющий в системе некоторый драйвер и хранящий для диспетчера ввода/вывода адреса всех процедур распределения драйвера (точек входа).
Объект-устройство, представляющее физическое, логическое или виртуальное устройство, имеющееся в системе.
Объект-драйвер создается диспетчером при загрузке драйвера в систему. После чего диспетчер вызывает процедуру инициализации драйвера, которая заполняет объект точками входа драйвера. Процедура инициализации создает по одному объекту-устройству для каждого устройства, управляемого данным драйвером. Она связывает объекты-устройства с объектом-драйвером. Объект-устройство содержит обратный указатель на объект-драйвер. Часто с объектом – драйвером связано несколько объектов-устройств.
Использование объектов для хранения информации о драйверах избавляет диспетчера ввода/вывода от необходимости знать детали отдельных драйверов.
Особенности NT требуют дополнительной информации при создании драйверов – мультипроцессорная обработка и восстановление после сбоев питания. В многопроцессорной среде прерывание может возникнуть на любом из процессоров, что может вызвать выполнение драйвера на нескольких процессорах. Также восстановить работу после сбоя питания необходимо и в операциях ввода/вывода.
Мультипроцессорная обработка. Основное требование, предъявляемое к коду для многопроцессорной среды, – предотвращать совместное использование ресурса двумя потоками одновременно. Драйвер выполняется одновременно на двух процессорах и синхронизирует доступ к своим данным при помощи спин-блокировки.
Большая часть кода драйвера выполняется на том же IRQL, который был установлен в момент запуска операции ввода/вывода вызывающей программой. Для нормальных потоков пользовательского режима это будет самый низкий IRQL. С другой стороны, прерывания устройств имеют более высокий приоритет. Т.о., устройство может сгенерировать прерывание и вызвать выполнение ISR во время исполнения кода его собственного драйвера. Если драйвер устройства изменял данные, которые изменяет и ISR , то во время выполнения ISR эти данные могут быть разрушены.
Это возможно не только на многопроцессорной системе, но для однопроцессорной можно запретить все прерывания. Запрещение прерываний на одном процессоре не ведет к запрещению прерываний на других. Чтобы избежать таких сложных ситуаций, драйвер NT должен синхронизировать свой доступ к любым данным, которые совместно используются им и ISR. Перед изменением этих данных, драйвер – устройство блокирует доступ к ним всем остальным потокам. Используемая им блокировка должна находиться в памяти, глобальной для всех процессов.