Кафедра «Автоматизированные информационные

Кафедра «Автоматизированные информационные

И управляющие системы»

 

 

Д.т.н., профессор Щепакин К.М.

 

 

КОНСПЕКТ ЛЕКЦИЙ

По дисциплине «Системы реального времени»

Направление подготовки: 230100 Информатика и вычислительная техника

Специальность подготовки: 230102 «Автоматизированные системы обработки информации и управления»

Форма обучения очная

 

Тула 2010

 

Лекция №1.

Системы реального времени (СРВ). Принципы построения и основные требования. ОС РВ.                                         

План лекции:

Введение

1. Функциональные требования к ОСВР

2. "Жесткие" и "мягкие" системы реального времени

3. Нити и приоритеты

4. Предсказуемость системных вызовов Win32 API

5. Управление прерываниями в NT

6. Управление памятью в NT

7. Может ли Windows NT использоваться в качестве ОС РВ?

 

Введение

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

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

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

 

1.1 Принципы построения и основные требования. Особенности.

Операционные системы общего назначения не предназначены для решения задач реального времени. Они ориентированы в основном на рациональное распределение ресурсов ЭВМ между пользователями, а также между выполняемыми задачами.

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

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

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

Нити и приоритеты

В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 - 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

Казалось бы, второе требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT. Большинство современных ОС РВ позволяет иметь по крайней мере 256 различных уровней. Чем больше имеется уровней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных уровней для нити в данном процессе. В результате многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной. Более того, общее число уровней для всех процессов класса только 16 и положение не спасает даже замена нитей процессами, не говоря уже о том, что переключение контекста для процессов снижает производительность.

В ОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, поэтому требование 4 не удовлетворяется.

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

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

 

Управление памятью в NT

Другим важным моментом при проектировании СРВ является политика управления памятью в ОС РВ. В Windows NT процессы выполняются в своем собственном пространстве памяти. Добиться этого позволяют механизмы виртуальной памяти и подкачки. Для бизнес-приложений это хорошо, но для СРВ, которая должна реагировать на внешние события с заранее определенным лимитом времени, это порождает непредсказуемость, особенно если система отправит страницу из памяти на диск. Windows NT позволяет захватить страницу в памяти посредством вызова функции VirtualLock. Тем не менее NT может разблокировать страницу и выгрузить ее на диск, если весь процесс неактивен

 

Лекция №2.

Использование NT

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

Иногда вводят усовершенствования в механизм обработки прерываний. Единственный способ сделать это - перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим только тогда, когда процессор имеет отдельный стек прерываний. Программа NMI должна быть написана аккуратно: в ней нельзя использовать вызовы ОС и она должна быть как можно короче, чтобы не потерять другие прерывания. Такое решение дает минимальную задержку прерывания, но требует дополнительной аппаратуры. Как и в других решениях, здесь необходим дополнительный механизм связи между NT и частью реального времени. Разница в том, что при этом требуется большая аккуратность в использовании NMI.

 

Лекция №3.

Модификация ядра

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

Этот подход лежит в основе предложений фирм Radisys, Imagination и LP Elektronik. Имеются две принципиально разные его реализации:

· разместить ядро реального времени внутри программы обслуживания прерываний Windows NT или в драйвере устройства;

· разместить ядро реального времени вне адресного пространства Windows NT.

Структура расширений NT в версии VenturCom

Реализация первой идеи была предложена компанией LP Elektronik. Суть ее в том, что на шину ISA ставится дополнительная плата (LP-Realtime Accelerator), снабженная таймером и имеющая возможность управлять большинством линий прерываний ISA. Кроме того, LP Elektronik предлагает технологию написания программ обработки прерываний (ISR) от этой платы. Эта технология позволяет, в частности, "раздуть" программу обработки прерываний до размеров полноценного ядра операционной системы реального времени.

Строго говоря, LP Elektronik не предлагает собственных расширений реального времени для Windows NT, однако на базе ее технологии в NT было внедрено ядро операционной системы реального времени VxWorks. Способ взаимодействия между процессами VxWorks и Windows был найден остроумный и легко реализуемый: между NT и VxWorks построена "псевдо-сеть" ТСР/IP. Для этого пришлось разработать всего лишь два драйвера TCP/IP - один для Windows, и один для VxWorks.

Фирма Radisys осуществила второй подход, итогом реализации которого стал продукт INtime, основанный на ядре реального времени операционной системы iRMX. Понятно, что и здесь не обошлось без модификации уровня HAL и разработки специфического драйвера. Этот драйвер, как и в остальных реализациях расширений реального времени, предназначен для взаимодействия между процессами NT и процессами реального времени. Radisys разработала также оригинальный механизм внедрения одной операционной системы в другую. Этот механизм управляет одновременным исполнением и целостностью ядер Windows NT и реального времени, осуществляет защиту памяти и разделяет адресные пространства процессов. Процессы и прерывания реального времени при этом всегда имеют приоритет по сравнению с процессами и прерываниями Windows NT. Структура расширений Windows NT c дополнительными ядрами реального времени приведена на рис. 1.

 

Рис. 1. Структура расширений Windows NT c дополнительными ядрами

Структура расширений NT c дополнительными ядрами реального времени

Отметим в итоге, что, хотя способы реализации расширений реального времени и различаются, суть у них одна - одновременная работа на одном процессоре двух операционных систем: Windows NT и реального времени. Плюс возможность взаимодействия между процессами реального времени и процессами Windows NT.

 

 

Применение ОС РВ

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

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

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

Расширения реального времени для NT. Итак, стоит ли беспокоиться производителям традиционных операционных систем реального времени в связи с появлением на рынке расширений реального времени для Windows NT?

Чтобы ответить на этот вопрос, недостаточно одного анализа тенденций развития операционных систем реального времени и программных технологий. Необходим и анализ тенденций новых аппаратных технологий на рынке промышленной автоматизации. И не случайно производители расширений Windows NT реального времени строят модели развития рынка промышленной автоматизации, из которых следует, что все промышленные контроллеры двадцать первого века будут содержать процессоры Intel [2]. Конечно же, это весьма маловероятно (в первую очередь, из-за того, что связка Wintel не спозиционирована в целом на рынок систем реального времени), и в этом смысле более объективным представляется анализ специалистов, для которых ОС РВ - только один из компонентов построения аппаратно-программных комплексов [3]. Однако нельзя забывать и о том, что мощность современных встраиваемых Intel-контроллеров, скажем на платформе VME или CompactPCI, постоянно растет, а цена снижается, что уже позволяет применять Windows NT.

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

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

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

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

3. в приложениях жесткого реального времени может использоваться только один комплект расширений - дополнительное ядро реального времени.

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

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

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

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

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

 

Лекция №5.

Лекция №7.

Лекция №9.

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

План лекции.

1. Задержка прерывания

2. Планирование задержки

3. Накопление прерываний

 

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

В QNX возможны следующие виды задержек.

 

1. Задержка прерывания

Задержка прерывания это время между приходом аппаратного прерывания и выполнением первой инструкции программного обработчика прерываний. QNX оставляет прерывания полностью задействованными практически постоянно, поэтому задержка прерываний обычно незначительна. Но некоторые части кода требуют временного отключения прерываний. Максимальное время такого отключения является самым худшим случаем задержки — в QNX это очень мало.

Эта диаграмма иллюстрирует ситуацию, в которой аппаратное прерывание обрабатывается установленным обработчиком. Обработчик либо просто вернет, либо вернет и активирует proxy.

Задержка прерывания (Тil) является минимальной задержкой которая происходит при полностью задействованных прерываниях. Максимальная задержка равна этому времени плюс максимальное время на которое QNX, или процесс выполняемый QNX отключает прерывания CPU.

 

2. Планирование задержки

В некоторых случаях обработчик низкоуровневых аппаратных прерываний должен планировать работу процессов с более высоким уровнем. По такому сценарию обработчик вернется и покажет, что надо активировать proxy. Это является второй формой задержки - задержка планирования.

Задержка планирования это время между прекращением обработки прерывания и выполнением первой инструкции процесса драйвера. Это обычно то время, которое необходимо для сохранения контекста текущего процесса и восстановления контекста требуемого процесса драйвера. Хотя эта задержка и больше чем задержка прерывания в системе QNX она относительно мала.

Обработчик прерывания прекращается и активирует proxy. Дано время для 20Mhz 386 процессора в защищенном режиме.

Важно запомнить, что большинство прерываний прекращаются без активации proxy. В большинстве случаев обработчик прерываний может позаботиться обо всех аппаратных проблемах. Активация proxy с целью запуска процесса - драйвера более высокого уровня случается только когда происходит значительное событие. Например, обработчик прерываний для последовательного устройства передает один байт данных устройству каждый раз, когда приходит прерывание на передачу, и запустит процесс высокого уровня (Dev) только когда буфер вывода освободится.

 

3. Накопление прерываний

Поскольку микрокомпьютерная архитектура позволяет задавать приоритеты аппаратным прерываниям, прерывание с высоким приоритетом может вытеснить прерывание с низким.

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

Пример накопления прерываний. Выполняется процесс А. Прерывание IRQx запускает обработчик Intx, но он вытесняется IRQy и его обработчиком Inty. Inty активирует proxy запуская тем самым процесс В, и Intx активирует proxy запуская процесс C.

 

Лекция №10.

Лекция №12

Аппаратное и программное обеспечение промышленных систем реального времени (ПСРВ)

 

План лекции:

Введение

1. Организация ПСРВ

2. Аппаратная архитектура

3. Стандарты шин

4. Технологии VME и PCI

5. Мезонинные технологии

6. Полевые системы

7. Программное обеспечение ПСРВ

8. Управление производством

 

Введение

 

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

Автоматическое управление начиналось с простых релейных схем, но теперь уровень сложности задач предполагает опору на цифровую обработку информации с использованием практически всех современных компьютерных технологий. Динамика развития индустрии промышленных систем отражена в отчете [1], данные которого основаны на опросах потребителей о закупаемых продуктах. Если в 1993 году было упомянуто 45 продуктов, то в 1996 году эта цифра выросла до 74 с основными закупками в трех крупных областях:

 управление процессами и инструментами (33%);

 интерфейс оператор - компьютер (37%);

 двигатели, приводы и управление движением (30%).

В таблице 1 приведены данные о приложениях, которые наиболее интенсивно используются в промышленных системах. Первые три места занимают распределенные системы управления, приложения на основе ПК и электроника для авиационных моторов, суммарно составляя 30% всех затрат в этой области. Другой аспект раскрывается в таблице 2, показывающей процентное распределение покупок по отраслям промышленности. Можно отметить следующие тенденции: увеличивается присутствие ПК в промышленном управлении, а по отраслям растут темпы автоматизации машиностроения; в химическом производстве динамика сохраняется; в нефтепереработке заметно небольшое замедление.

 

Таблица 1. Наиболее популярные продукты для промышленных систем

 

 

Таблица 2. Затраты на автоматизацию по отраслям промышленности

 

Аппаратная архитектура

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

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

Ситуация радикально изменилась после того, как рынок выявил лидеров, предлагавших достаточно хорошие решения, способных учитывать пожелания других заинтересованных сторон и готовых спонсировать профессиональную деятельность по стандартизации таких некоммерческих организаций, как IEEE, ISO, IEC (МЭК) и ANSI.

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

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

 

Стандарты шин

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

На рис. 1 приведены данные результатов исследования корпорацией VDC (Venture Development Corp.) мирового рынка коммерческих компьютерных плат в приложениях реального времени и встроенных приложениях [2]. Общий объем продаж за 1996 год составил 2,426 млрд. долл. Из этой суммы на архитектуру VME пришлось 1,262 млрд.; на ПК архитектуры (включая ISA, EISA, Multibus I и II, PC/104) - 720,8 млн.; на платы PCI - 237,6 млн.; на встроенные материнские платы - 205,8 млн. долл.

 

Рис. 1. распределение продаж на рынке компьютерных плат в 1996 году

 

Технологии VME и PCI

Технология шины VMEbus зародилась в 1979 году как спецификация компании Motorola и в 1987-88 гг. была признана международным стандартом (IEEE 1014, IEC821). Эта магистрально-модульная архитектура выдержала конкуренцию с Multibus, FUTUREbus+ и, как следует из данных на рис. 1, несмотря на почтенный возраст, остается лидером для промышленной автоматизации. По-видимому, успех стандарта VME стал следствием множества факторов.

Технология VME позволяет создавать вычислительные системы в очень широком диапазоне производительности, от настольных компьютеров до многопроцессорных супер-ЭВМ, от простых и дешевых промышленных контроллеров до мощнейших многопроцессорных систем управления десятками тысяч аналоговых и цифровых каналов ввода/вывода. Не претендуя на достижение рекордных показателей, VMEbus обеспечивает наилучшее соотношение цена/производительность для системы в целом и предоставляет хорошие возможности для наращивания ресурсов.

Важным фактором стало то, что продвижением и развитием стандарта VME занимается организованная в 1984 году международная ассоциация VITA - VFEA International Trade Association. Ее основные спонсоры - крупнейшие американские компании Motorola и Sun Microsystems. Членами VITA являются около 100 европейских, американских, азиатских производителей совместимой продукции VMEbus: DEC, HP, Force Computer, Microware, IBM и др.

После официального принятия стандарта заботой комитета стало поддержание жизнеспособности VME в соответствии с быстро меняющимися технологическими условиями. Ввод в строй нескольких расширений и новой версии стандарта для 64-разрядной передачи данных VME64 показал, что потенциал шины VME далеко не исчерпан. Новейшие реализации VMEbus обеспечивают пропускную способность 320 Мбайт/с.

Архитектура VME выросла вокруг семейства Motorola 68xxx, но сейчас имеются VME-реализации для RISC-процессоров, рабочих станций Sun, DEC, HP, SGI, Intel и клона PowerPC. По данным [3], на сегодня существует 370 различных процессорных плат VME, которые выпускает 61 компания. Из общего числа 39% плат центральных процессоров поддерживают 64-разрядную передачу данных, 61% - 16- и 32-разрядную.

Конструктивно в основу VMEbus положен самый популярный механический стандарт - Евромеханика. Конечная система компонуется из функциональных модулей VME, устанавливаемых в крейты, число которых не ограничено. Крейт представляет собой каркас с объединительной магистралью VME, источником питания и вентиляцией. В каждый крейт можно поместить до 21 модуля VME. Модули соединяются через объединительную плату с нормированным волновым сопротивлением и терминаторами на каждой сигнальной линии. В качестве соединителей используются надежные 96-штырьковые разъемы DIN602-3, причем 8- и 16-разрядные модули имеют один разъем, 32/64-разрядные - два.

Сегодня технология VME, кроме основного стандарта VMEbus/VME64, включает несколько расширений.

Технология оперативной замены Live Insertion представляет собой минимальное аппаратное дополнение к стандартным модулям VMEbus, позволяющее беспрепятственно вставлять/вынимать модули из работающей системы. Для реализации горячей замены предложен специальный механизм изоляции модуля от шины.

Широкое распространение получил стандарт измерительных систем VXIbus, который поддерживают более 200 зарубежных фирм, выпускающих свыше 500 типов модулей.

В 1995 году был принят стандарт мезонинных технологий ANSI/VITA 4 на модули IP (Industry Pack).

Для телекоммуникаций предложен стандарт SCSA подшины для обработки цифровой аудио- и видеоинформации в телефонии. VMEbus используется как основная управляющая шина системы, а SCSA P2 - для интерфейса с телефонными цепями.

Работа над спецификацией VME64 уже завершена, хотя отделение VITA по стандартам продолжает уточнять расширения к стандарту VME64, но, по всей вероятности, массовое производство VME-изделий, включающих эти расширения, начнется не раньше 1998-99 г. Сейчас же VME-системы ощущают сильное давление дешевых систем на базе ПК. Однако можно рассчитывать, что после того, как новые расширения VME64 будут освоены на рынке высокопроизводительной аппаратуры, высокая рентабельность VME-систем восстановится. Это подтверждается и тем, что за последний год самые высокие темпы развития в VME-сообществе имели три компании, специализирующиеся на быстрых вычислениях: Mercury, Sky Computers и CSPI.

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

За основу была взята 32/64-разрядная высокопроизводительная шина PCI, локальный интерфейс подсистемы В/В для надплатных расширений активной материнской платы, ставшая стандартом де-факто для современных ПК. Эта шина имеет массу достоинств: она не зависит от типа микропроцессора, может работать с самыми быстрыми из них, имеет большую пропускную способность и аппарат автоконфигурирования устройств В/В. Сейчас PCI активно применяется в VME-компьютерах для подключения периферии.

После доработки, в 1995 году, был выпущен стандарт CompactPCI, основанный на общепринятой технологии создания надежных промышленных модульных систем - пассивной объединительной магистрали [4]. Большое практическое значение имеет тот факт, что любое ПО, работающее на настольных ПК, может быть без изменений перенесено в систему CompactPCI, а программисты, работающие на ПК, но не имеющие дела с аппаратурой, могут быстро скомпоновать систему CompactPCI, установить ОС и сконфигурировать систему в соответствии с реальными потребностями.

CompactPCI стал достойным конкурентом технологии VME. Однако CompactPCI - относительно новый стандарт, и некоторые необходимые функции в нем либо отсутствуют (горячая замена), либо не доведены до кондиций. Кроме того, номенклатура продуктов CompactPCI пока небольшая, особенно в сравнении с рынком VME/ISA-оборудования. Поэтому сейчас следует ориентироваться на связку двух стандартов, используя CompactPCI как недорогую объединительную панель с высокой скоростью передачи данных.

 

Мезонинные технологии

 

Мезонинные технологии применяются достаточно давно: в середине 80-х не было способа запаивать на основной плате кристаллы памяти емкостью более 64 Кбайт, и для увеличения ее объема использовались мезонинные модули. Сейчас, когда степень интеграции микросхем гораздо выше, на одной плате размещается простой компьютер со всеми соответствующими электронными атрибутами, и еще остается место. Мезонинные технологии приобрели новый смысл - сегодня это средство модульного наращивания функциональных возможностей. Взяв за основу типовую плату, разработчик может добавить к ней специальные пользовательские функции, реализованные в готовом мезонинном модуле.

Таким образом, мезонинные платы представляют еще один, более низкий по сравнению, например, с модулями VMEbus уровень модульности. Типичный размер мезонинных плат 50х80 мм. Они являются функционально законченными изделиями и устанавливаются на плату-носитель (в стандарте VMEbus, ISAbus или каком-либо другом). Стандартные установочные габариты платы при этом не меняются - мезонины устанавливаются поверх нее. Носитель может быть пассивным или содержать собственный процессор. Так самый, пожалуй, популярный в мире одноплатный компьютер/контроллер MVME162 кроме обычных аксессуаров (CPU MC68040, Ethernet, SCSI, DRAM, RTC, 2xRS232, Flash-диск, EPROM, VME64) имеет порты для установки 4 мезонинных плат. Это позволяет дополнить плату компьютера, например, 192 каналами цифрового ввода/вывода, спецпроцессорами TMS32040, графикой, любой сетью.

Существует широкая номенклатура (http://www.groupipc.com) мезонинных плат: многоканальные ЦАП, АЦП, цифровой ввод/вывод, EEPROM/FLASH, SRAM, графические контроллеры, различные типы сетей, интерфейс PCMCIA и т. д. Хотя до сих пор довольно активно применяются частные мезонинные интерфейсы, особенно широко распространено несколько стандартов: PCI Mezzanine Card (PMC), IndustryPack (IP) и ModPack.

Как показывает опыт, модульность на уровне мезонинов обеспечивает поразительную гибкость при интегрировании системы, резко повышает ремонтопригодность и снижает стоимость ЗИПа.

 

Полевые системы

Рассмотренные архитектурные решения относятся к локальному (центральный процессор и локальная шина) и региональному (VMEbus) уровню организации систем промышленной автоматизации. В условиях реального производства необходимо еще наладить взаимодействие центрального управляющего блока с пространственно распределенным оборудованием системы автоматизации - датчиками, исполнительными механизмами, передаточными устройствами, приводами и программируемыми контроллерами.

Такую связь можно было бы реализовать, например, с помощью сети Ethernet, но к промышленным сетям предъявляются особые требования по надежности и помехоустойчивости. Для связи с удаленными цифровыми устройствами промышленного назначения принято использовать бит-последовательные промышленные или полевые шины (bit serial Fieldbus). К этой группе относятся несколько европейских (PROFIBUS (DIN 19245), FIP (UTE-C46-6xx), Bitbus (IEEE 1118), CAN (ISO/DIS 11898), Interbus-S (DIN 9258)) и американских (Foundation, HART) конкурирующих стандартов. Ведется разработка общеевропейского стандарта EN 50170, объединяющего PROFIBUS и FIP.

На рис. 2 показано распределение европейского рынка полевых систем в 1996 году. Сравнение с 1994 годом показывает, что произошли резкие перемены, самая важная из которых - увеличение доли PROFIBUS c 30 до 42%, причем это достигнуто за счет частных архитектур.

 

 

Рис. 2. Распределение рынка полевых стандартов в Европе (по количеству пользователей)

 

Каковы основные возможности лидера - PROFIBUS? Это открытый стандарт, определяющий обмен информацией с компонентами автоматизации любых разновидностей - ПЛК, ПК, панелями оператора, датчиками и силовыми приводами. Существует три основных варианта PROFIBUS: FMS, DP и ISP.

PROFIBUS-FMS представляет собой решение для задач взаимодействия на цеховом и полевом (field) уровне иерархии промышленных связей: с его помощью организуется обмен между интеллектуальными field-устройствами и контроллерами, а также между контроллерами. Как правило, на этом уровне обмен информацией осуществляется по запросу прикладного процесса и не является циклическим. Поэтому время реакции здесь не очень существенно, гораздо важнее функциональные возможности.

Модель PROFIBUS позволяет определить коммуникационные связи, объединяющие распределенные прикладные процессы в один общий. Та часть прикладного процесса field-устройства, которая отвечает за взаимодействие, называется виртуальным field-устройством (VFD). Все объекты реального устройства, с которыми можно взаимодействовать (переменные, программы, диапазоны данных), называются объектами коммуникации. Отображение функций VFD на реальное устройство обеспечивается в коммуникационной модели PROFIBUS интерфейсом прикладного уровня. Для этого объекты коммуникации PROFIBUS-станции вводятся в ее локальный словарь объектов - OD. Конфигурация OD может определяться и загружаться в устройство либо его производителем, либо разработчиком -- или может формироваться динамически. OD содержит структуру и типы всех объектов, а также их внутренние адреса в устройстве и представление на шине (индекс/имя). Доступ к объектам при функционировании происходит через сервисные функции протокола PROFIBUS-FMS, которые позволяют, например, опросить/установить значения переменных и массивов, запустить/остановить программу.

Что касается двух других вариантов стандарта, то PROFIBUS-DP - это оптимизированная по производительности версия PROFIBUS, предназначенная специально для взаимодействий, критичных по времени. PROFIBUS-ISP - проект взаимодействующих частей, базируется на технологии PROFIBUS и дополняет ее возможностями управления процессами, включая внутреннюю защиту.

 

Управление производством

Верхний уровень в комплексе FactorySuite занимает пакет InTrack - инструментарий для разработки систем управления производством. Продолжая линию, заложенную в пакете InTouch, он поддерживает объектно-ориентированный стиль разработки и имеет архитектуру клиент/сервер. Назначение InTrack - создание интерактивных приложений, способных контролировать и управлять всеми стадиями производственных процессов - от загрузки сырья до выпуска готовой продукции.

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

 

Лекция №13

 Использование средства NT в качестве Web -сервера для IIS ( Internet Information Server )

 

План лекции:

Введение

1. Microsoft и intranet

2. Общие черты intranet-систем

3. Система управления доступом

4. Прикладное программирование в intranet

 

Введение

 

В 1995 году компания Sun Microsystems ввела в оборот термин "intranet", обозначив им корпоративную информационную систему, построенную на основе Web-технологии. Главным в этом шаге было не построение новой информационной системы предприятия с детализацией существующих информационных потоков, присущих современным компаниям, а встраивание элементов новой технологии, разработанной в рамках так называемого "Зеленого проекта". Ресурсов на этот проект было потрачено много, но конечная цель - разработка универсального интерфейса для бытовых приборов достигнута не была. Находясь в состоянии глубокого уныния, и от избытка свободного времени, разработчики проекта реализовали на языке OAK, который был одним из стержней новой системы, Web-браузер HotJava. Это положило начало мощной рекламной компании по продвижению на рынок разработки мобильных приложений для World Wide Web нового языка, получившего название Java. Надо отдать должное компании Sun в усилиях и успехах по продвижению нового языка.

Сначала Java называли средством "оживления" Web. Однако скоро выяснилось, что заставить Дюка - маленького стилизованного человечка из демонстрационных программ браузера HotJava - махать ручкой можно гораздо проще. Современные браузеры позволяют реализовать просмотр многокадровых GIF, "оживлять" страницы при помощи программ на JavaScript. Другим способом встраивания интерактивной динамической графики может быть использование plug-ins, что, конечно, не проще чем Java, но гораздо эффективнее.

Следующим шагом в продвижении Java стали мобильные вычисления. Действительно, очень удобно иметь программу, которая работает на любой платформе и при этом свободно передается по сети. Следует заметить, что идея мобильного кода в Internet существовала довольно давно, не было только подходящей среды для ее реализации. Всерьез на эту роль претендовала только среда X Window, но у нее не было универсального интерфейса, такого как браузер WWW. У мобильных кодов имеется один существенный недостаток - никто не может дать гарантии, что по сети не будут передаваться программы с серьезными ошибками, программные "закладки" и "вирусы".

Дабы избавиться от неприятностей, вызванных ошибками в программных кодах, из Java удалили всю адресную арифметику и ввели особый режим работы с памятью. При этом главной задачей была борьба с наиболее распространенными ошибками: переполнением строковых констант фиксированной длины, переполнением стека при вызове подпрограмм, захватом и освобождением памяти во время работы программы. Естественно, что все эти решения отразились на эффективности кода. При этом не следует слишком полагаться на обещания создать эффективные компиляторы с Java, не говоря уже об интерпретаторах. Для языка Lisp задача так и не была решена, а с точки зрения механизма управления памятью эти системы во многом похожи.

Очевидно, что на стороне сервера устанавливать Java-программы нецелесообразно. Если сервер перегружен, то Java только ухудшит его способность реагировать на запросы пользователей. Другое дело администрирование самого сервера. Здесь реактивность не нужна. Отсюда и реализация программ администрирования серверов IIS (Internet Information Server) или Netscape через Java-программы. Но если в среде NT это оправдано, то, скажем, для Unix это выглядит явным излишеством. Следует обратить внимание на то, что реализация приложений на Java для многопользовательских систем, где идет борьба за эффективность распределения вычислительных ресурсов, также не целесообразна. Речь идет не о системах, которые позволяют разделять свои ресурсы в сети и поддерживать несколько account-ов, а о системах, на которых одновременно работают несколько пользователей. С этой точки зрения, язык Java ориентирован на разработку программ для клиентской части информационных сервисов, которая исполняется на ПК. При этом язык подходит для использования именно в многопотоковых системах. Самое лучшее в этом контексте, если в системе вообще ничего не выполняется, кроме Java. Вот вам и логический вывод в пользу сетевого компьютера от Sun.

Если вернуться к безопасности, но не безопасности кода, а безопасности в смысле защиты от несанкционированного доступа, то здесь при использовании мобильного кода сразу встает огромное количество вопросов. Не останавливаясь на них подробно (для этого существуют бюллетени CERT), следует заметить, что в спецификацию Java-машины были введены ограничения на использование кода в сети. Касается это прежде всего разработки компонентов распределенных информационных систем. Нельзя получать/передавать данные на хосты, отличные от того, с которого получен апплет. Как результат, стало необходимым использовать серверы-посредники (proxy), чтобы все эти компоненты увязать друг с другом.

Потеря качества при ограничении сетевого взаимодействия может быть компенсирована только одним - применением Java в корпоративных информационных сетях. При этом учитывается, что жесткие ограничения апплетов не действуют для приложений Java. Кроме того, в корпоративной сети можно нарушать многие ограничения безопасности - авторы программ и алгоритмы хорошо контролируются, а в корпоративной сети не может появиться программа со стороны. Если, конечно, кто-то из сотрудников их туда не запустит. Но это можно проконтролировать через систему межсетевых фильтров и proxy-серверов.

Таким образом, применение Java в качестве основного инструмента разработки информационных корпоративных сетей является естественным развитием этой технологии. И именно это, в терминологии компании Sun, и называется intranet.

 

 

Microsoft и intranet

Несколько иной взгляд на intranet-систему имеется у Microsoft. Используя так же, как и Sun, в качестве отправной точки корпоративную информационную систему, Microsoft опирается только на те средства, которыми в данный момент располагает. Фактически, это набор компонентов BackOffice и ОС WindowsNT.

Если компания Sun строит intranet, опираясь на инструмент разработки, то Microsoft предлагает решения, основанные на уже существующих компонентах. В этом случае в качестве связки вовсе не обязательно использовать Java. На самом деле подход Microsoft во многом оправдан не только в плане продвижения собственной продукции компании, но и с практической точки зрения. По версии Microsoft intranet-система - это прежде всего система управления информационными потоками корпорации. Все существующие программные продукты Microsoft, такие, например, как Exchange, Word, Access, SQL Server и т. п., есть результат анализа типовых информационных потребностей компаний и, следовательно, готовые кирпичики для создания корпоративной информационной системы. В этом смысле IIS - это еще один компонент информационного обслуживания сотрудников корпорации. При этом IIS - не только Web-сервер, но и Gopher-сервер, и FTP-сервер в том числе.

В таком свете поддержка Microsoft Java выглядит шагом, направленным на получение некоторого преимущества перед конкурентами. Но здесь кроется и одна из главных проблем. Фактически, в Microsoft проглядели Internet вообще и WWW в частности, и только с конца 1995 года компания стала нагонять ушедших далеко вперед конкурентов. Широко разрекламированная точка зрения, что Microsoft вторглась в новую для себя нишу глобальных коммуникаций, глубоко ошибочна и навязывается не от хорошей жизни. Наоборот, глобальные коммуникации вторглись в сферу интересов компании, и ей не оставалось ничего другого, как заняться разработкой программного обеспечения для Internet. Весьма наглядным примером может служить электронная почта. Сначала появилась InternetMail, а уже потом интерфейс к SMTP в Exchange, что, конечно же, свидетельствует отнюдь не о прозорливости аналитиков компании. То же можно сказать и о инкапсуляции NBF в TCP/IP. Если бы все делалось честно, то завернутые в оболочку IP-пакеты должны были бы свободно проходить через любые шлюзы. Но достаточно установить Unix-систему в качестве шлюза, как организовать распределенный домен (речь в данном случае идет не о DNS), работающий с почтой, упакованной в недрах продукции Microsoft, становится довольно трудно. Да и вообще сети, построенные на широковещательных протоколах, не очень подходят для глобального информационного обмена.

Если обратиться к системе NT, как к основе среды функционирования корпоративной информационной системы, то пока именно в сетевом компоненте, связанном с TCP/IP, находят большое количество ошибок. Кроме того, замечено, что непрерывное круглосуточное функционирование системы приводит к ее постепенной деградации, выраженной в замедлении работы. Связано это скорее всего с фрагментацией оперативной памяти. Сообщения о нехватке виртуальной памяти для функционирования приложений становятся постоянной головной болью системного администратора. Если конфигурация функционирует в качестве сервера небольшой рабочей группы, который время от времени выключается, то "торможение" не проявляется. Понятно, что разработчики NT когда-нибудь, возможно, устранят этот недостаток, но ясно, что с самого начала данная ОС не была ориентирована на работу в качестве сервера глобального информационного сервиса, каким является Internet или корпоративные сети. К этому стоит еще добавить и требования к ресурсам, которые предъявляются Windows NT к аппаратуре. Там, где многие Unix-системы разворачиваются и функционируют вполне свободно, NT работает с большим трудом. Это, в частности, заставляет скептически относиться к использованию NT в качестве Web-сервера для узлов с большим числом обращений. Но для небольшого корпоративного сервера, учитывая простоту настройки IIS, данная система вполне сгодится.

 

 

Общие черты intranet-систем

Из перечисленных решений, а это далеко не полный список возможных вариантов, можно вычленить некоторые общие свойства, которые характерны для любой intranet-системы:

 опора на Web-технологию;

 наличие СУБД и баз данных под ее управлением;

 наличие системы контроля и разграничения доступа;

 большой объем прикладного программирования.

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

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

 

 

Рис. 1. Схема информационного обмена в рамках Web-технологии

 

Обмен информацией по технологи WWW является типичным информационным обменом по схеме "клиент-сервер". В качестве клиента обычно выступает программа-браузер. Это такие известные продукты, как Netscape Navigator компании Netscape или Internet Explore от Microsoft. С этими программами большинство пользователей сети хорошо знакомы. Однако не только браузеры могут быть клиентами в рамках информационного обмена WWW - многочисленные "паучки" тоже принимают участие в этом процессе. Они просматривают сеть на предмет появления новых информационных ресурсов, которые следует внести в индексы информационных служб Internet. Клиентами выступают также и редакторы документов Website, которые способны осуществлять опубликование материалов в сети посредством механизма обмена данными WWW.

Сервером же в этой модели выступает программа-сервер протокола обмена гипертекстовой информацией HTTP, которая отвечает на запросы клиентов. В общем случае в качестве сервера может выступать и сервер другого протокола, скажем Gopher или FTP. Такое расширенное толкование возникло по той простой причине, что с самого начала браузеры разрабатывались как мультипротокольные программы (знаменитая Mosaic - предтеча Netscape), обеспечивающие интерфейс доступа ко многим информационным ресурсам сети.

Поясним теперь процесс взаимодействия клиента и сервера при обращении клиента к ресурсам, которыми управляет сервер:

1. Инициатором начала обмена данными в этой схеме, как правило, является клиент.

2. Клиент посылает серверу запрос на получение от него определенного информационного ресурса. Запрос передается в формате HTTP, а адрес ресурса указывается в формате URL.

3. Сервер, получив запрос, определяет, является ли он запросом к информационному ресурсу, которым данный сервер управляет.

4. Если ресурс относится к зоне ответственности данного сервера, то сервер проверяет права доступа к данному информационному ресурсу, и если нет нарушения прав, то возвращает содержание ресурса клиенту (рис. 2).

 

 

Рис. 2.Обращение к локальному ресурсу сервера.

 

5. Если запрос клиента нарушает права доступа к ресурсу, то сервер отклоняет запрос и возвращает соответствующее предупреждение клиенту.

6. В случае, если ресурс не относится к зоне ответственности данного сервера, сервер определяет не содержится ли в его файлах настройки информации о перемещении ресурса в сети (Redirection). Если ресурс был размещен на сервере, но в данный момент перемещен в другое место, то сервер сообщает об этом клиенту (рис. 3)

 

Рис. 3. Выполнение процедуры перенаправления запроса (Redirection).

 

7. Если сервер поддерживает виртуальное дерево другого Website, то запрос будет перенаправлен на нужный ресурс в таком же ключе, как это происходит для процедуры Redirection.

8. Если сервер используется в качестве сервера-посредника (proxy-сервера), то он выступает, с одной стороны, в качестве сервера для клиента, пославшего запрос, а с другой стороны - в качестве клиента, который посылает запрос к другому серверу (рис. 4).

 

 

Рис. 4. Использование Web-сервера в качестве сервера-посредника.

9. После возвращения информации клиенту сервер разрывает соединение с ним.

Так в общих чертах выглядит взаимодействие клиента и сервера в рамках технологии обмена данными в среде WWW. Сервер WWW - это "умная" программа, которая действительно может использоваться для широкого круга задач. Наиболее типичными для современных серверов являются функции ведения иерархической базы данных документов, контроля за доступом к информации со стороны программ-клиентов, предварительной обработки данных перед ответом на запрос, взаимодействия с внешними программами через CGI, реализации взаимодействия с клиентами и другими серверами в режиме посредника, реализации встроенных, или взаимодействие с внешними поисковыми машинами.

Кроме того, такие серверы, как NetSite (Netscape Communication) и Apache, реализуют шифрованные протоколы HTTP для обмена информацией с клиентами, что позволяет использовать их в качестве основы для построения защищенных intranet-систем.

Рассмотрим теперь более подробно то, что собственно и составляет совокупность информационных ресурсов сервера - его базу данных или Website (рис. 5).

 

Рис. 5. Структура базы данных и программного обеспечения Website

 

 

Итак, основной задачей для любого сервера является ведение его базы данных - части файловой системы, служащей для размещения файлов HTML-документов. В данном случае термин "База данных" применяется просто для обозначения всей совокупности данных, к которым можно получить доступ через Web-сервер. Большинство современных файловых систем - это иерархические деревья, следовательно, и база данных HTTP-сервера также является таким деревом. Для любой базы данных необходимо ввести понятие единицы хранения - минимальный объект, к которому можно обратиться извне или получить в качестве ответа на запрос. Стандартным объектом хранения в базе данных HTTP сервера является HTML-документ. Кроме такого стандартного объекта многие серверы поддерживают различные комбинированные объекты хранения, создаваемые в ряде случаев из нескольких файлов или генерируемые программами "на лету".

Если обратиться к терминологии, принятой в WWW, то можно выделить следующие основные объекты, с которыми оперирует сервер и программа-клиент:

Страница базы данных World Wide Web - это законченный информационный объект, который отображается пользователю при обращении к информационному ресурсу WWW по универсальному идентификатору этого ресурса (URI, URL).

База данных World Wide Web или Website - набор страниц базы данных WWW. При более подробном рассмотрении Website - это вся совокупность данных и программного обеспечения, обеспечивающая отображение страниц информационной базы данных Web.

Если страница Website представляет собой обычный файл в стандарте HTML, то тогда говорят об элементарном или стандартном элементе хранения. В таком случае URL указывает непосредственно на этот файл и сервер просто отправляет его в ответ на запрос пользователя.

Многие страницы содержат внутри себя контейнеры-формы, которые служат для передачи информации от программы клиента программе-серверу. В рамках данного рассмотрения эти страницы выделены в особую группу страниц WWW.

Страницей-формой будем называть в данном контексте файл в формате HTML, который содержит в себе HTML-форму.

После обращения к странице-форме, как правило, следует вызов либо API-модуля, встроенного в сервер, либо CGI-программы. В свою очередь такое действие вызывает генерацию этим модулем или программой виртуальной страницы.

Виртуальной страницей Website будем называть страницу, которая в виде файла в файловой системе сервера не существует. Данная страница появляется только в момент обращения клиента к серверу. Один из способов генерации виртуальной страницы - это генерация при помощи API-модуля или CGI-программы. При этом весь текст страницы может порождаться программой, либо могут использоваться файлы-заготовки. Генерируются не только текстовые файлы, но и графика. Одним из самых популярных способов генерации документов является обращение к стекам гипертекстовых ссылок и СУБД. Второй способ генерации виртуальной страницы - это генерация такой страницы сервером в тело документа и файлы описания иерархии документов сервера включаются команды преобразования документов. Сервер может, в общем случае, производить условную генерацию документов на основе информации, полученной от программы-клиента.

VRML-страница - это такой же объект, как и обычные страницы Website, только написанная на другом языке. К VRML-страницам можно применять все те же механизмы генерации, что и к страницам HTML.

Java-applet - это мобильный код, сгенерированный компилятором апплетов. Множество апплетов составляет в базе данных Website отдельный каталог файловой системы сервера. В страницы HTML встраиваются специальные контейнеры апплетов, позволяющие программе-клиенту распознавать наличие апплетов и подгружать их в качестве части страницы.

Минимальный набор инструментов, который необходим для поддержания страниц базы данных - это редакторы файлов формата HTML, GIF, в том числе и версии GIF89A, и JPEG, редакторы файлов формата MPEG, VRML, редактор аудиофайлов, компилятор байткода Java.

Как уже отмечалось, в intranet-системах Website представляет собой совокупность всех информационных ресурсов корпорации. При таком толковании от монолитного Website логично перейти к распределенному, где информационные ресурсы корпорации будут распределены между различными компьютерами системы. В этом случае полная схема (рис.1) не всегда будет реализована. Так, например, не обязательно устанавливать сервер протокола HTTP - для многих СУБД имеются апплеты, которые способны формировать запросы к базе данных напрямую без обращения к серверу HTTP. При этом, конечно, СУБД должна обеспечивать поддержку такого обращения по сети.

Рассуждая о Web как о сердце intranet-системы, нельзя не обратить внимание на последствия, к которым приводит такая ориентация. А последствия достаточно серьезные.

Во-первых, если рассматривать данную технологию в рамках сетевого обмена и модели такого обмена OSI, то это уровень приложений данной модели. Под ним имеются еще 6 уровней протоколов. При этом Web - уровень приложений стека протоколов TCP/IP, а протокол HTTP опирается на транспортный протокол TCP. Если intranet - это система корпоративная, и корпорация распределена по большой территории, то использование TCP/IP оправдано и позволяет применять Internet в качестве сети, поверх которой можно организовать виртуальную локальную сеть корпорации. Естественно, что в этом случае сеть должна быть защищенной. При таком решении происходит тиражирование технологии ведения информационной системы во все ее сегменты, а обмен информацией между сегментами осуществляется в рамках той же технологии, что и работа внутри сегмента. Если доводить данный подход до его логического завершения, то в рамках обмена TCP/IP можно организовать и локальную информационную систему на одном отдельно стоящем компьютере, вообще не включенном в сеть. Просто на нем необходимо установить все технологические компоненты, что вполне реально - практически для любой компьютерной платформы имеются и Web-клиенты, и Web-серверы.

Другое дело, если в качестве основы для корпоративной сети используется иная, отличная от TCP/IP технология. В этом случае создание intranet-системы приведет к тому, что в локальной сети будут вертеться два типа сетевых протоколов как минимум. Но здесь следует обратить внимание на то, что если сотрудники корпорации работают с ресурсами Internet, то TCP/IP уже все равно есть, и в этом смысле intranet в сетевой "зоопарк" ничего нового не внесет. Выбор в качестве основного интерфейса работы с информационными ресурсами Web-браузера предопределяет появление в сети TCP/IP. Ведь хоть эти программы и являются мультипротокольными, все протоколы, которые они поддерживают - это протоколы уровня приложений TCP/IP. Собственно, именно это и определяет использование TCP/IP в качестве основы сетевого транспорта в intranet.

Если остановиться на Web-браузерах более подробно, то при разработке Website для intranet снимается ряд проблем, которые существуют при создании Web-страниц для Internet. Разработчик корпоративного Website не связан теми жесткими ограничениями на правила использования инструментов Web при создании Web-страниц. Используемое внутри корпорации программное обеспечение хорошо известно, и при разработке Website следует ориентироваться именно на него. При этом нет необходимости в анализе журналов посещений для определения рамок возможного применения, например, JаvaScript. Однако это все касается только внутреннего компонента intranet - части, которая направлена на обслуживание сотрудников корпорации. Для представления информации во внешний мир все проблемы остаются прежними.

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

В этом смысле intranet-системы ничем не отличаются от других корпоративных информационных систем. Во всяком случае, объем прикладного программирования в них точно не уменьшился. При этом для обеспечения доступа к базе данных из Web-браузера можно использовать два основных способа: подключение сервера баз данных через Web-сервер, и доступ к серверу баз данных из Web-браузера напрямую (рис. 6).

 

 

Рис. 6. Взаимодействие компонентов программного обеспечения при доступе

к базе данных через Web-сервер.

 

 

В первом варианте используются либо CGI-скрипты, либо специальные API-модули Web-сервера. Применение CGI-скриптов - гораздо более простой способ сопряжения сервера с внешним программным обеспечением, чем любой другой, который предоставляет Web-технология. При этом можно использовать самые разнообразные способы передачи запросов серверу баз данных, начиная от интерфейсов командной строки до написания программ, отредактированных с соответствующими библиотеками шага выполнения СУБД. В качестве интерфейса разработчик Website применяет HTML-формы, которые позволяют формулировать запросы к базе данных. Скрипты получают информацию от сервера либо через переменные окружения, которые порождает сервер, либо через стандартный ввод. Все зависит от метода доступа, который используется при обмене данными между браузером и сервером. Далее скрипт работает как обыкновенное приложение баз данных и возвращает ответ на запрос через стандартный вывод. Таким образом, разработчику не надо ничего знать о том, как устроен сервер. Более того, ему вовсе не обязательно использовать языки типа Cи - скрипт можно написать и на командном языке, например Perl. Такой подход существенно облегчает разработку прикладного программного обеспечения для Web вообще и для сопряжения баз данных с Web-сервером в частности.

Однако за простоту приходится платить низкой эффективностью процедуры обработки запросов, а точнее скоростью обработки этих запросов. Для систем, в которых обращение к базе является обычным делом и таких обращений много, разработка доступа из браузера к базе данных через CGI-скрипт неприемлема. Ответом на этот вызов стал переход к специализированным модулям доступа к базам данных, которые встраиваются как часть программного обеспечения сервера. Для этого перешли от монолитных серверов к модульным, и разработчики серверов предложили интерфейс сопряжения модулей с сервером, который получил название API-интерфейса. В отличие от CGI API-модули должны быть откомпилированы и собраны в единое целое с сервером. Фактически API-модуль - это часть сервера, написанная прикладным программистом. Естественно, что при таком подходе в жертву эффективности была принесена мобильность кода и его независимость от конкретной реализации сервера. Для WWW последнее замечание довольно важное. Так, например, использование модулей перекодировки символ "на лету" на отечественных Website тормозит переход на более совершенные версии Web-серверов - модули написаны для ранних версий и с новыми не всегда желают работать. В результате тот же модуль для Apache работает с версиями 1.1.x, но уже вышла версия 1.2, которая обладает большим числом новых возможностей, от которых не хочется отказываться. Следует, правда, заметить, что в данном случае для intranet-системы это не столь существенно. Ориентация на корпорацию заставляет освободиться от проблем перекодировки - внутри корпорации используется, как правило, один и тот же тип программного обеспечения, и, следовательно, нет необходимости использовать разные кодовые страницы для представления одной и той же информации.

Очевидно, что для программирования модулей требуется программист гораздо более высокой квалификации, чем для программирования CGI-скриптов. Поэтому стали появляться способы построения некоторого промежуточного варианта, который, с одной стороны, удовлетворял бы требованиям мобильности, независимости и простоты программирования, а с другой стороны - был бы достаточно эффективным. Одним из таких решений является спецификация FastCGI. Идея этой спецификации в том, что прикладная программа использует способ передачи параметров и данных, который применяется в CGI, но при этом не удаляется из памяти, а остается демоном, который получает запросы от сервера и обрабатывает их. При работе через FastCGI с базами данных получается схема, в которой фактически используется три демона HTTPD (Web-сервер), FastCGI-скрипт и сервер базы данных. HTTPD принимает запрос Web-браузера и передает его FastCGI-скрипту, который в свою очередь обращается к серверу баз данных. Обычно в качестве последнего выступает не собственно ядро базы данных, а некоторый демон, который это ядро (backend process) запускает.

Другой способ непосредственного обращения к СУБД из Web-браузера - использование plug-in либо Java-applet. В этом случае СУБД не обязана поддерживать протокол HTTP. Запрос попадает на сетевой демон СУБД в том же виде, как и с любого другого клиента, который не использует Web-технологии. Преобразование запроса в надлежащую форму возлагается в этом случае либо на plug-in-программу, либо на апплет. Программировать здесь придется ничуть не меньше. Разница только в том, что часть работы по преобразованию запросов и формированию отчетов возлагается на программное обеспечение, которое выполняется на компьютере пользователя. При этом в случае с plug-in придется соблюдать соответствующие спецификации по обмену данными между браузером и прикладной программой, что сильно зависит от типа браузера, а во втором случае осваивать программирование апплетов на Java. Если учесть, что Java будет исполняться браузером в режиме интерпретации мобильного кода, то требования к аппаратуре, установленной у пользователя, в части производительности и объема оперативной памяти возрастают, и, как показывает практика, существенно.

Кроме работы с обычными базами данных в рамках intranet-систем появляется необходимость развертывания информационно-поисковых систем (ИПС), которые облегчают навигацию пользователя в гипертекстовой сети Website. Типичным примерами такого рода систем и программного обеспечения для их поддержки являются Altavista и Harvest. Общая схема такой системы может состоять из следующих компонентов (рис. 7): интерфейс пользователя, поисковая машина, система индексирования и робот сканирования сети.

 

Рис. 7. Схема построения информационно-поисковой службы

 

В качестве источника информационных ресурсов указан Internet, но с тем же успехом здесь можно написать и intranet, подразумевая внутренние информационные ресурсы корпорации. На самом деле должны быть указаны оба источника. Фактически речь идет о создании общего информационного каталога информационных источников вне зависимости от того, где этот источник расположен, во внутренней информационной системе или во внешнем мире. Для сотрудника корпорации этот ресурс должен быть одинаково легко доступен. К тому же, при использовании кэширующих серверов, пользователь может и не заметить разницу во времени доступа к ресурсу, потому что тот будет расположен во временной памяти на диске Web-сервера. Единственное отличие от ресурса, хранящегося в базе данных корпорации, будет состоять в том, что заботу о ведении этого ресурса будет выполнять та информационная служба, которая данный ресурс в сети разместила. Таким образом, ИПС, построенная на основе Web-технологии, представляет собой единый виртуальный тематический каталог корпорации.

Если кратко пройтись по функциям каждого из компонентов этого программного обеспечения, то получим примерно следующее:

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

Поисковая машина осуществляет поиск информации в базе данных индекса ИПС и формирует список ссылок на информационные ресурсы. При этом ссылки могут указывать как на документы корпоративного Website, так и на документы во внешней сети.

Индекс создается системой ведения индекса. При этом используются различные конверторы из форматов документов сети и системы нормализации лексики наподобие системы Яndex.

Робот сканирования сети периодически просматривает сеть на предмет внесения новых документов, соответствующих тематике корпорации, и внесения изменений в существующие документы. Если рассматривать intranet только как сугубо внутреннюю систему корпорации, то необходимости в сканировании и поиске информации нет - источник новых поступлений известен. Но если рассматривать систему в качестве виртуального каталога, то необходимость в такого вида работе очевидна.

 

 

Система управления доступом

В рассуждениях о виртуальных каталогах, единой технологии представления информации, прозрачной среде работы как с корпоративными, так и мировыми информационными ресурсами на первое место ставят вопрос о разграничении прав доступа к различным ресурсам intranet. При этом следует снова принять во внимание, что речь идет о технологиях TCP/IP, и, следовательно, защищаться придется именно в этой среде. Защита как правило базируется на фильтрации трафика и его шифровании. Кроме того, применяются такие решения, которые должны повысить устойчивость технического оборудования сегментов intranet-системы (рис. 8).

 

 

Рис. 8. Типовая структура сегмента Intranet-системы.

 

 

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

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

Использование proxy не только повышает безопасность системы, но также служит и инструментом анализа информационных потребностей сотрудников корпорации, что облегчает ведение корпоративного Website.

Если в корпоративной сети используются не только протоколы TCP/IP, но и другие сетевые технологии, то их сопряжение требует дополнительного контроля со стороны администрации сети - обычно именно в этом месте появляются "дырочки".

В контексте разграничения прав доступа уместно отметить, что intranet-система - это не только Web. В любой корпоративной системе существуют и другие информационные технологии, которые определяются информационными потоками внутри корпорации, например электронная почта и документооборот. В большинстве корпоративных систем эти потоки автоматизированы и управляются без использования Internet-технологий. Фактически существует две электронных почты: Internet и внутрикорпоративная. Пока эта проблема решается за счет модулей сопряжения, но очень заманчиво перейти на одну технологию. То же самое можно сказать и о системах, предназначенных для информирования сотрудников - доски объявлений. В Internet имеется Usenet и эта технология в принципе подходит для широковещания внутри корпорации. Правда это можно организовать и по почте или средствами обычного Web.

 

 

Лекция 14

Введение

ОС РВ является наиболее развитой из операционных систем СМ ЭВМ, программно совместимых с вычислительными машинами PDP-11 фирмы DEC. ОС РВ имеет американское происхождение; там она называется RSX-11.

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

При богатстве возможностей ОС РВ отличается очень скромными по нынешним понятиям требованиями к ресурсам вычислительной машины. Для проведения генерации системы нужно примерно 15 Мб на дисках, а для повседневной работы после удаления файлов, необходимых для генерации, системе со всеми ее утилитами - не больше 2 Мб. Потребности в оперативной памяти еще скромнее: ОС РВ, включающая в себя все функциональные возможности, способна нормально работать в многозадачном многопользовательском режиме на ЭВМ со 128 Кб памяти, а объем, достаточный для МОС РВ в минимальной конфигурации без учета задач пользователя, составляет 16 Кб. Таким образом, затраты дисковой памяти сравнимы с полной системой MS DOS, а потребности в ОЗУ намного меньше, и это при том, что ОС РВ в отличие от MS DOS является полноценной многозадачной многопользовательской системой.

Еще одним положительным качеством ОС РВ является ее очень высокая стабильность в работе. Непривилегированный пользователь по определению не может вызвать сбой в работе системы или в работе других пользователей, а ошибок в самой системе практически нет. За несколько лет автор не наблюдал ни одного случая сбоя системы из-за действий рядового пользователя и видел всего несколько сбоев из-за неполадок аппаратуры, и это при том, что машина эксплуатировалась весьма интенсивно (до 16-18 ч в день) и часто решала весьма нестандартные задачи. До такой надежности далеко не только Windows (NT надежна только по сравнению с 95-й), но и Linux.

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

Конечно, ОС РВ не лишена недостатков. Один из них и, вероятно, наиболее существенный - отсутствие "полноценной" виртуальной памяти, но это - следствие архитектурных ограничений, накладываемых процессорами СМ ЭВМ. Второй недостаток - слабо развитая файловая система (нет иерархических каталогов, ограничены длина имен файлов и используемый в них набор символов). Эту проблему, впрочем, можно было бы решить без каких-либо существенных затруднений, если бы сами СМ ЭВМ не стали достоянием истории. Наконец, третий - это непереносимость системы на другие платформы; он является "платой" за очень высокую эффективность системы, написанной целиком на ассемблере.

Диспетчер памяти

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

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

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

 

 

Имя.тип;версия

Имя каждого файла состоит из нескольких символов (от одного до девяти), входящих в код RADIX-50. К этим символам относятся большие латинские буквы, цифры и знак доллара (в RADIX-50 входят еще точка и пробел, но они в именах файлов использоваться не могут).

Тип содержит до трех символов в коде RADIX-50.

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

Наиболее распространены следующие типы файлов:

· .TSK - файл образа задачи (загрузочный модуль задачи);

· .OBJ - объектный модуль;

· .MAC - исходный текст программы на макроассемблере;

· .OLB - библиотека объектных модулей;

· .MLB - библиотека макроопределений;

· .CMD - косвенный командный файл.

Полная спецификация файла включает в себя спецификацию устройства, каталога и файла, например

DM2:[1,54]PIP.TSK;1

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

· описание команд MCR и языка косвенных командных файлов;

· описание текстового редактора EDT;

· руководство системного программиста по разработке драйверов внешних устройств;

· описание утилиты управления магнитной лентой MAG.

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

 

Лекция 15

Управление прерываниями.

План лекции:

1. Вектора прерываний

2. Программирование контроллера прерываний 8259.

3. Запрет/разрешение отдельных аппаратных прерываний

 

Вектора прерываний

 

Прерывания - это готовые процедуры, которые компьютер вызы­вает для выполнения определенной задачи. Существуют аппаратные и программные прерывания. Аппаратные прерывания инициируются аппа­ратурой, либо с системной платы, либо с карты расширения. Они мо­гут быть вызваны сигналом микросхемы таймера, сигналом от принте­ра, нажатием клавиши на клавиатуре и множеством других причин. Аппаратные прерывания не координируются с работой программного обеспечения. Когда вызывается прерывание, процессор оставляет свою работу, выполняет прерывание, а затем возвращается на преж­нее место. Для того, чтобы иметь возможность вернуться точно в нужное место программы, адрес этого места (CS:IP) запоминается в стеке вместе с регистром флагов. Затем в CS-.IP загружается адрес программы обработки прерывания и ей передается управление. Прог­раммы обработки прерываний иногда называют драйверами прерываний. Они всегда заканчиваются инструкцией IRET (возврат из прерыва­ния), которая завершает процесс, начатый прерыванием, возвращая старые значения CS:IP и регистра флагов, давая тем самым програм­ме возможность продолжить выполнение из того же состояния.

С другой стороны, программные прерывания на самом деле ниче­го не прерывают. Это обычные процедуры, которые вызываются нашими программами для выполнения рутинной работы. Однако эти подпрог­раммы содержатся не внутри нашей программы, а в операционной сис­теме, и механизм прерываний дает возможность обратиться к ним. Программные прерывания могут вызываться друг из друга. Например, все прерывания обработки ввода с клавиатуры DOS используют прерывания обработки ввода с клавиатуры BIOS для получения символа из буфера клавиатуры. Необходимо отметить, что аппаратное прерывание может получить управление при выполнении программного прерывания. При этом не возникает конфликтов, т.к. каждая подпрограмма обра­ботки прерывания сохраняет значения всех используемых ею регист­ров и затем восстанавливает их при выходе, тем самым не оставляя следов того, что она занимала процессор.

Адреса программ прерываний называют векторами. Каждый вектор имеет длину 4 байта. В первом слове хранится значение IP (указа­тель команд), а во втором - CS (сегмент команд). Младшие 1024 байта памяти содержат вектора прерываний, т.о., есть место для 256 векторов. Вместе взятые они называются таблицей векторов. Вектор для прерывания 0 начинается с ячейки 0000:0000, для преры­вания 1 - с ячейки 0000:0004 и т. д. Если посмотреть на 4 байта, начиная с адреса 0000:0020, в которых содержится вектор прерыва­ния 8Н (прерывание вектора суток), то можно обнаружить там A5FEOOFO. Имеется в виду, что младший байт слова расположен сна­чала и что порядок - IP:CS, это 4-байтовое значение переводится в FOOO:FEA5. Это стартовый адрес программы ПЗУ, выполняющий преры­вание 8Н.

 

2. Программирование контроллера прерываний 8259.

 

Для управления аппаратными прерываниями используется микрос­хема программируемого контроллера прерываний 8259. Поскольку в каждый момент времени может поступать не один запрос, микросхема имеет схему приоритетов. Имеется 16 уровней приоритетов у IBM AT (от IRQO до IRQ15 две микросхемы). Максимальный приоритет соот­ветствует уровню О.

Аппаратные прерывания в порядке приоритета

IRQ О таймер

1 клавиатура

2 канал ввода/вывода

 

8 часы реального времени

9 программно переводятся в IRQ2

10         -12 резерв

13 математический сопроцессор

14 контроллер фиксированного диска

      15   резерв

3 COM2

4 СОМ1

5 LPT2

6 контроллер дискет

7 LPT1

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

Микросхема 8259 имеет три однобайтовых регистра, которые уп­равляют восемью линиями аппаратных прерываний. Регистр запроса на прерывание (IRR) устанавливает соответствующий бит, когда линия прерывания сигнализирует о запросе. Затем микросхема автоматичес­ки проверяет, не обрабатывается ли другое прерывание. При этом она запрашивает информацию регистра обслуживания (ISR). Дополни­тельная цепь отвечает за систему приоритетов. Наконец, перед вы­зовом прерывания проверяется регистр маски прерываний (IMR), что­бы узнать, разрешено ли в данный момент прерывание данного уров­ня. Как правило обращаются к регистру маски прерываний через порт 21Н и к командному регистру прерываний через порт 20Н.

 

 

Лекция 16

Лекция 17

Лекция 18

X . БИБЛИОГРАФИЧЕСКИЙ СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ

 

Основная

1. http://www.qnx.com/

2. www.microware.com

3. http://lynuxworkc.com

4. Зыль С.Н. Операционная система реального времени QNX. От теории к практике. СПб.: БХВ – Петербург. 2004. – 192 с.

5. Кознов Д. В. Основы визуального моделирования. – М: Интернет-Университет Информационных технологий; БИНОМ. Лаборатория знаний, 2008-246 с.

6. Алексеев Дмитрий, Ведревич Евгений и др. – М. Издательский Дом «КомБук», 2004. – 432 с.

7. Гургенидзе А.Т., Кореш В.И. Мульисервисные сети и услуги широкополосного доступа. СПб.: Наука и техника. 2003. – 400 с.

8. Фатуев В. А., Щепакин К. М. Многофункциональные информационно-вычислительные сети. Тула, ТулГУ, 2008. -182 с.

Дополнительная

1. Мартин Дж. Программирование для вычислительных систем реального времени.- М.:Наука, 1975. – 360 с.

 

Поддержка РВ в USIX

Для обеспечения режима реального времени в USIХ предус­мотрен целый ряд возможностей, гарантирующих оптимальное время реакции:

• приоритетная и круговая диспетчеризация;

• динамическое и статическое назначение приоритетов пользова­тельским задачам;

• захват ресурсов памяти для обеспечения быстрого переключе­ния задач путем фиксации страниц в оперативной памяти;

• возможность подключения к источникам прерываний для про­граммирования нестандартных устройств;

• возможность отображения в адресное пространство процесса пользователя любых объектов, включая файлы на дисках, физи­ческую память, порты ввода-вывода;

• синхронизация взаимодействия процессов пользователя с по­мощью традиционных механизмов UNIХ (семафоры, очереди сообщений, разделяемая память, именованные и неименован­ные программные каналы ввода-вывода) и дополнительных возможностей (сообщения USIХ, серверы, механизм событий).

В структуре ядра USIХ реализованы новые алгоритмы, ориен­тированные на поддержку реального времени. Среди них следует отметить полную прерываемость ядра системы и механизм обра­ботки прерываний.

Традиционные UNIХ-системы не разрешают переключения процессов во время выполнения системной фазы ядра. Ядро яв­ляется как бы одной большой критической секцией, которая должна быть выполнена до конца. Только после выполнения критической секции, что может потребовать значительного вре­мени, возможно переключение на более приоритетный процесс.

В отличие от этого ядро USIХ является полностью прерывае­мым. Выполнение процесса может быть прервано независимо от его фазы (пользовательской или системной), и управление может быть передано процессу с более высоким приоритетом. При этом причинами прерываний могут быть следующие события:

• истечение кванта времени владения процессором у текущего процесса;

• наступление запланированных событий по времени;

• прерывание от устройств ввода-вывода;

• изменение приоритета процессов;

• освобождение ресурсов ядра (двоичных семафоров);

• посылка сообщения более приоритетному ожидающему про­цессу.

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

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

Система же USIX предоставляет возможность приоритетного планирования программной обработки прерываний и разбиения обработки на этапы. Аппаратное прерывание может прерывать даже самый высокоприоритетный процесс, поскольку целый ряд устройств не допускает задержки обслуживания прерываний.

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

Надежность. Система USIX использует все доступные аппа­ратные средства для локализации неисправностей аппаратуры. В рамках многопроцессорной системы отказ одного процессорного элемента (РЕ) не влечет за собой «развала» системы, так как пла­нирование работы процессоров децентрализовано. В случае зави­сания или отказа РЕ встроенная система тайм-аутов позволяет вернуть все захваченные ресурсы ядра и, таким образом, обеспе­чивает плавную реорганизацию системы вместо полного отказа.

Ядро USIX поставляется пользователю в двоичном коде в ви­де отладочной версии и рабочей версии.

Отладочная версия USIX содержит 32 встроенных отладочных режима, позволяющих пользователю получить различные «сре­зы» выполнения задачи и, таким образом, быстро локализовать ошибки в своих программах. Среди таких «срезов» можно отме­тить отслеживание следующих действий:

• выполнение системных вызовов;

• обработку сигналов;

• работу системы ввода-вывода;

• порождение (fork), выполнение (ехес) и завершение (ехit) про­цессов;

• работу подсистемы взаимодействия процессов (разделяемая па­мять (shm), семафоры (sem), сообщения (msg).

Кроме того, отладочная версия содержит ряд встроенных проверок целостности внутренних данных ядра, что позволяет легко обнаруживать ошибки, допущенные пользователем при расширении системы (создание собственных серверов, драйве­ров ввода-вывода).

Рабочая версия USIX не содержит перечисленных отладочных возможностей и поэтому обеспечивает более высокую (на 20— 30%) производительность.

Соответствие стандартам. USIX является операционной сис­темой семейства UNIX и относительно программного интерфей­са соответствует международным стандартам Р0SIХ 1003.1, Р081Х 1003.2 и SVID (System V Interface Definition. Issue 3). Сис­тема USIX совместима на уровне исходных и двоичных кодов с системой UNIX System V и на уровне исходных кодов — с систе­мой ВSD4.3. В приложении 6 приведен краткий перечень основ­ных стандартов, связанных с ОС семейства UNIХ.

Файловая система

Файловая система USIX состоит из двух частей: структуры данных на диске и файлового сервера.

Ядро USIX не зависит от конкретного типа файловой системы и формата хранения данных на диске. Таким образом, возможно создание файловых серверов для любых файловых структур: S5, UFS (UNIХ FILE SYSTEM), FFS (Fast File System) и др. В системе USIХ реализован собственный сервер файловой структуры 'sб'.

Файловая система USIX обладает рядом характерных особен­ностей: наличием альтернативных структур данных (суперблок тома, заголовок индексного файла); возможностью контроля корректности данных с использованием контрольных сумм; воз­можностью создания непрерывных файлов; древовидной струк­турой расположения файлов и др. В качестве единицы передава­емой информации для устройств с прямым доступом использует­ся кластер, размер которого устанавливается равным одному (или нескольким) дисковому блоку. Определение размера кластера осуществляется при инициализации устройства.

Структура данных на дисках. Файловая система USIX поддер­живает структуру данных на дисках, основу которой составляет индексный файл. Индексный файл располагается в произволь­ной области диска. Первый блок индексного файла содержит ин­формацию о самом диске, карту планирования индексного фай­ла, заголовок индексного файла и собственно данные индексно­го файла.

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

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

Файловый сервер. Он отвечает за ведение каталоговой струк­туры и распределение пространства на диске.

Ввод-вывод данных из файлов выполняет ядро USIX. Взаи­модействие файлового сервера с ядром осуществляется через об­мен сообщениями. В случае ошибочной ситуации файловый сер­вер в возвращаемом сообщении передает ядру код.

При открытии файла ядро получает от файлового сервера ге­ометрию файла (список блоков данных файла) и создает соответ­ствующий объект памяти. После получения запроса на чтение ядро создает временный сегмент, в который отображает часть ре­гиона, и пытается переписать данные этого сегмента пользовате­лю. Так как первоначально данные в регионе отсутствуют, проис­ходит отказ страницы, и система виртуальной памяти выдает за­прос дисковому драйверу на чтение этой страницы. Если к этому времени страница файла уже находилась в памяти, обращение к диску отсутствует. Такой же алгоритм используется и при записи данных в файл. При этом модификация и расширение файла, как правило, происходят первоначально в памяти. Запись данных ре­гиона на диск осуществляется по запросу 'fsynс' или по периоди­чески выполняемой операции 'sync'.

Для удовлетворения различных требований файловый сервер предоставляет следующие возможности синхронизации работы с файлами:

• отсутствие явной синхронизации (режим, обычно используе­мый в UNIХ);

• синхронизация операций с индексным файлом. Любые опера­ции с индексным файлом немедленно приводят к изменениям на диске;

• синхронизация операций с каталогами и индексным файлом — на этом уровне файловая система защищена от сбоев питания или случайного отключения машины;

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

Режим синхронизации выбирается пользователем на этапе монтирования тома и может изменяться динамически.

Для удовлетворения требований реального времени в USIX обеспечивается возможность создания непрерывных файлов. Доступ к ним наиболее эффективно осуществляется путем отобра­жения файла в виртуальное адресное пространство пользователя. В этом случае ядро USIХ обеспечивает поддержку соответствия между данными на диске и областью адресного пространства пользователя. Кроме того, пользователь может получить геомет­рию файла на диске и выполнять обмен данными, непосредст­венно обращаясь к драйверу дискового устройства.

Если в вычислительной системе имеется несколько контрол­леров дисков, обеспечивающих параллельную работу каналов ввода-вывода, USIХ позволяет их монтировать с помощью не­скольких файловых серверов одного или разных типов. Данная возможность в сочетании с возможностью одновременной рабо­ты серверов существенно увеличивает производительность фай­ловой подсистемы в многопроцессорных системах.

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

Кэширование имен. Для ускорения доступа к файлам ядро USIХ поддерживает динамический кэш имен файлов и других объектов. Величина кэша имен задается пользователем при за­грузке системы и может настраиваться для различных режимов работы. Обновление кэша осуществляется в результате удаления «старых» имен после удаления последнего объекта, связанного с этим именем.

 

Кафедра «Автоматизированные информационные

И управляющие системы»

 

 

Д.т.н., профессор Щепакин К.М.

 

 

КОНСПЕКТ ЛЕКЦИЙ

12345678910Следующая ⇒

Поделиться: