Применение операционных систем реального времени в современных системах регулирования и управления
Содержание
Содержание………………………………………………………………………..2
1. Понятие операционной системы реального времени………………………..3
1.1. Определение………......................................................................................3
1.2. Системы жесткого и мягкого реального времени……………………….3
1.3. Обязательные требования к ОСРВ……………………………………….4
1.4. Временные требования к операционной системе……………………….6
2. Windows NT как операционная система реального времени………………..7
2.1. Поддержка многозадачности……………………………………………...7
2.2. Приоритеты нитей…………………………………………………………7
2.3. Инверсия приоритетов…………………………………………………….8
2.4. Характеристики API-интерфейса Win32…………………………………9
2.5. Управление прерываниями………………………………………………10
2.6. Управление памятью……………………………………………………..11
2.7. Другие вопросы для рассмотрения……………………………………...12
2.8. Заключение………………………………………………………………..12
3. Операционная система QNX…………………………………………………13
4. Примеры современных систем регулирования и управления……………..21
4.1. Автоматизированная система контроля теплопрочностных испытаний продукции………………………………………………………………………..21
4.1.1. Введение и постановка задачи……………………………………21
4.1.2. Структура АСК…………………………………………………….22
4.1.3. Функции, выполняемые АСК……………………………………..23
4.1.4. Заключение…………………………………………………………26
4.2. Система стабилизации тока выпрямительных агрегатов электрохими-ческих производств цеха №2 ЗАО "Каустик"………………………………….26
4.3. Автоматика сушильных камер для качественной сушки пиломатериалов………………………………………………………………….30
4.3.1. Система автоматики сушильной камеры "Модуль-С1"……………..30
Литература……………………………………………………………………….33
1. Понятие операционной системы реального времени
1.1 Определение
Система реального времени реагирует в предсказуемое время на непредсказуемое появление внешних событий.
Это определение предъявляет к системе следующие базовые требования:
1. Своевременная реакция.
После того как произошло событие, реакция должна последовать не позднее, чем через требуемое время. Превышение этого времени рассматривается как серьезная ошибка. С другой стороны, не считается ошибкой медленная реакция текстового редактора. В данном случае это проблема производительности, которою можно решить, используя более быстрый процессор. Однако проблему своевременной реакции системы использование более быстрого процессора решает не всегда.
2. Одновременность или одновременная обработка.
Даже если одновременно происходит несколько событий, реакция ни на одно из них не должна запаздывать. Это означает, что система реального времени должна иметь встроенный параллелизм (несколько процессоров или многозадачную операционную систему).
1.2. Системы жесткого и мягкого реального времени
Системы реального времени можно разделить на системы жесткого и мягкого реального времени.
Признаки систем жесткого реального времени:
· недопустимость никаких задержек ни при каких условиях;
· бесполезность результатов при опоздании;
· катастрофа при задержке реакции;
· цена опоздания бесконечно велика.
Хороший пример системы жесткого реального времени - бортовая система управления самолетом.
Система мягкого реального времени характеризуется следующими признаками:
· за опоздание результатов приходится платить;
· снижение производительности системы, вызванное запаздыванием реакций, приемлемое.
Примерами могут служить автомат розничной торговли и подсистема сетевого интерфейса. В последнем случае можно восстановить пропущенный пакет, используя сетевой протокол, повторяющий передачу пропущенных пакетов. При этом, конечно, произойдет снижение производительности системы.
Итак, различие между системами жесткого и мягкого реального времени определяется следующими требованиями: система называется системой жесткого реального времени, если она "не имеет права опаздывать", и мягкого реального времени, если ей "не следует опаздывать".
Не существует операционных систем жесткого или мягкого реального времени. Понятия системы реального времени и операционной системы реального времени (ОСРВ) часто смешиваются.
Система реального времени - это конкретная система, связанная с реальным объектом. Она включает в себя необходимые аппаратные средства, операционную систему и прикладное программное обеспечение.
Операционная система реального времени - только инструмент, помогающий построить конкретную систему реального времени. Поэтому бессмысленно говорить об операционных системах жесткого или мягкого реального времени. Можно говорить только о том, можно ли с помощью данной операционной системы построить систему реального времени. Конкретная ОСРВ может только предоставить вам возможность создать систему жесткого реального времени. Но обладание такой ОСРВ вовсе не делает вашу систему "жесткой". Для создания системы жесткого реального времени необходимо сочетание подходящих аппаратных средств, адекватной операционной системы и правильного проектирования прикладного программного обеспечения.
Если решено построить систему реального времени, обслуживающую TCP/IP-соединение через Ethernet, она никогда не будет системой жесткого реального времени, поскольку сам Ethernet непредсказуем.
Если, с другой стороны, создаётся приложение над такой ОС, как Windows 3.11, то система никогда не будет системой жесткого реального времени, поскольку непредсказуемо поведение операционной системы.
Определим операционную систему реального времени как операционную систему, с помощью которой можно построить систему жесткого реального времени.
1.3. Обязательные требования к ОСРВ
Требование 1: ОСРВ должна быть многонитиевой или многозадачной и поддерживать диспетчеризацию с вытеснением
Поведение ОСРВ должно быть предсказуемым. Это не означает, что ОСРВ должна быть быстрой, но означает, что максимальный промежуток времени для выполнения любой операции должен быть известен заранее и должен быть согласован с требованиями приложения. Например, Windows 3.11 - даже на процессоре Pentium Pro с тактовой частотой 200 МГц - неприменима для построения систем реального времени, поскольку одно приложение может навсегда захватить управление и заблокировать все остальные (Windows 3.11- кооперативная система).
Итак, первое требование состоит в том, чтобы такая ОС была многонитиевой или многозадачной и, кроме того, планировщик должен иметь возможность вытеснять любую нить (задачу) и передавать управление той нити (задаче), которая больше всего в этом нуждается. Для обеспечения вытеснения на уровне прерываний структура обслуживания прерываний (и аппаратная архитектура) должна быть многоуровневой.
Приведённые утверждения относительно нитей и многонитиевых операционных систем верны также и для процессов и многозадачных (многопроцессных) операционных систем.
Требование 2: Должно существовать понятие приоритета нити (задачи)
Как найти нить (задачу), которая нуждается в ресурсах больше всего? В идеальном случае ОСРВ предоставляет ресурсы той задаче или драйверу, у которых осталось меньше всего времени до истечения срока реакции на событие (такая ОС также называется управляемой критическими сроками). Однако для реализации этого механизма нужно уметь прогнозировать, сколько времени понадобится задаче для завершения своей работы и сколько времени понадобится другим задачам для того, чтобы они успели к своим критическим срокам. Подобная ОСРВ пока еще не создана из-за сложности реализации.
Поэтому разработчики ОС используют другой метод: они вводят концепцию приоритетов для нитей (задач).
При построении конкретной системы реального времени разработчик должен выстроить приоритеты задач таким образом, чтобы каждая из них успела с реакцией к своему критическому сроку, то есть он должен трансформировать базовое требование реального времени "успеть с реакцией к нужному моменту" в комбинацию приоритетов и в сценарий их динамического изменения. Ясно, что при этой трансформации возможны ошибки, приводящие к неправильной работе системы. Для помощи в этом вопросе можно воспользоваться, например, теориями монотонного планирования и различными средствами моделирования, но и они не всегда помогают. Как бы то ни было, но во всех современных ОСРВ приходится использовать механизм приоритетов как один из инструментов предсказуемости.
Требование 3: ОС должна поддерживать предсказуемые механизмы синхронизации нитей (задач)
Все нити (задачи) разделяют данные (ресурсы) и должны обмениваться между собой информацией, поэтому необходимы механизмы межзадачного (межнитиевого) взаимодействия.
Требование 4: Должен существовать механизм наследования приоритетов (система должна быть защищена от инверсии приоритетов)
На самом деле именно эти механизмы синхронизации и тот факт, что разные нити выполняются в одном и том же пространстве памяти, и определяют различие между нитями и процессами. Процессы не разделяют одно и то же пространство памяти.
Комбинации приоритетов нитей и разделяемых между ними ресурсов могут привести к классической проблеме инверсии приоритетов. Для создания условия инверсии приоритетов должно быть задействовано как минимум три нити. Если нить с самым низким приоритетом заблокировала ресурс (который она делит с самой высокоприоритетной нитью), в то время как работает нить с промежуточным приоритетом, возникает следующий эффект: нить с наивысшим приоритетом ожидает освобождения ресурса; нить с промежуточным приоритетом вытесняет низкоприоритетную нить и работает, пока не завершится; управление получает низкоприоритетная нить, освобождает ресурс, и только после этого нить с высоким приоритетом может продолжить свою работу. В этом случае время, необходимое для завершения нити с наивысшим приоритетом, зависит от времени работы нити с более низким приоритетом. Очевидно, что в такой ситуации высокоприоритетная нить может "прозевать" критическое событие.
Чтобы избежать таких ситуаций, ОСРВ должна быть снабжена механизмом наследования приоритетов, то есть блокирующая нить должна наследовать приоритет нити, которую она блокирует (конечно, только в том случае, если заблокированная нить имеет более высокий приоритет).
1.4. Временные требования к операционной системе
В самом деле, разработчик должен знать все времена выполнения системных вызовов и уметь предсказывать поведение системы в любых ситуациях. Поэтому производитель ОСРВ обязательно должен давать информацию о следующих временных характеристиках системы:
1. задержка прерывания (interrupt latency) - то есть время от момента появления запроса на прерывание до начала его обработки;
2. максимальное время исполнения каждого системного вызова. Оно должно быть предсказуемым и не зависеть от количества объектов в системе;
3. максимальное время, на которое ОС и драйверы могут блокировать прерывания.
Разработчик также должен знать следующее:
1. уровни системных прерываний;
2. уровни прерываний устройств, максимальное время, которое занимают программы обработки прерываний, и т. д.
Если все перечисленные времена известны, то имеются все предпосылки для создания системы жесткого реального времени. Конечно, при этом требования к производительности разрабатываемой системы должны быть согласованы с характеристиками выбранной ОСРВ и аппаратуры.
2. Windows NT как операционная система реального времени
Windows NT проектировалась без учета требований, предъявляемых к операционным системам реального времени (ОСРВ) - она разработана как операционная система общего назначения (точнее, как сетевая ОС). Тем не менее благодаря тому, что Windows NT создавали разработчики операционной системы реального времени VMS, в нее заложены некоторые механизмы, присущие ОСРВ. Например, введены классы процессов реального времени, которые диспетчеризуются так же, как и в операционных системах реального времени. Кроме того, при обслуживании прерываний используется очень эффективный алгоритм. Но достаточно ли этого, чтобы квалифицировать Windows NT как операционную систему реального времени?
2.1. Поддержка многозадачности
Windows NT является многонитиевой и многозадачной. Планировщик системы поддерживает вытеснение. Следовательно, Windows NT удовлетворяет Требованию 1.
А как насчёт предсказуемости Windows NT? Вспомним кратко структуру Windows NT и посмотрим, выполняются ли остальные требования реального времени.
2.2. Приоритеты нитей
В системе реального времени не все задания имеют одинаковые приоритеты. Критичные по времени задания имеют высокие приоритеты. Другие, такие, как отображение состояния системы, запись сообщений о событиях в файле протокола или конфигурирование системы, имеют низкие приоритеты. Поэтому ОС должна уметь назначать заданиям различные приоритеты.
В Windows NT система приоритетов достаточно сложна:
В ней предусмотрено два класса приоритетов процессов: класс реального времени и динамический класс. Процессы из класса реального времени имеют фиксированный уровень приоритета, который может быть изменен только самим процессом, тогда как приоритеты процессов динамического класса изменяются планировщиком в зависимости от типа исполняемой работы (интерактивная или нет). В системе реального времени может использоваться только первый из этих классов, так как только он может обеспечить предсказуемость системы.
Любой процесс имеет базовый уровень приоритета, который может изменяться только им самим (для случая класса реального времени).
Нить внутри процесса может иметь приоритет в диапазоне 2 от базового приоритета этого процесса и, кроме того, два экстремальных уровня приоритета данного класса. Например, нити процесса с базовым приоритетом 24 (класс реального времени) могут иметь любые приоритеты между 22 и 26, а также приоритеты 16 и 31.
Таким образом, второе требование к системам реального времени (приоритеты процессов и нитей) также выполняется. Правда, здесь есть одна проблема: количество возможных приоритетов очень мало. Большинство современных ОСРВ допускают использование как минимум 256 приоритетов.
В чем суть проблемы? Ответ очевиден: чем больше приоритетов в вашем распоряжении, тем более предсказуемую систему вы можете создать. При оптимальном проектировании системы различным нитям присваиваются различные приоритеты. Но в Windows NT внутри одного процесса доступно только 5 (7, если учитывать два экстремальных) уровней приоритета. При таком ограничении большая часть нитей будет работать на одном и том же уровне и, если вы должны управлять одновременно несколькими критическими событиями, предсказуемость системы будет невысокой. Можно, конечно, возразить, что может быть много процессов. Но даже и тогда общее количество приоритетов всего лишь 16. Более того, время переключения контекста между нитями из различных процессов значительно больше, чем между нитями внутри одного процесса.
2.3. Инверсия приоритетов
Как упоминалось выше, проблема инверсии приоритетов является классической для систем реального времени. Поэтому системные вызовы синхронизации, такие, как мьютексы (mutex), семафоры и критические секции, должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, так что требование 4 не выполняется.
Еще одна проблема, относящаяся к инверсии приоритетов в Windows NT, связана со способом реализации некоторых вызовов графического интерфейса пользователя (GUI). Эти вызовы управляются синхронным образом (вызывающая нить приостанавливается до завершения обработки вызова) процессом, работающим в классе динамических приоритетов (не реального времени), что создает все предпосылки для инверсии приоритетов (разделяемый ресурс здесь - системный вызов GUI)
Как мы видим, из-за относительно небольшого количества возможных приоритетов и проблемы их инверсии Windows NT пригодна только для простых (небольшое количество различных видов событий) систем реального времени.
2.4. Характеристики API-интерфейса Win32
Почему же все-таки Windows NT выбирают для построения систем реального времени? Во-первых, очень соблазнительно использовать на разных уровнях промышленной иерархии одну и ту же ОС. Ещё одна причина - богатый возможностями и мощный интерфейс прикладных программ (API) Win32, хорошо поддерживаемый разнообразными средствами разработки. Немаловажен и тот факт, что с API-интерфейсом Win32 хорошо знакомо огромное количество программистов. Словом, достоинств у этого API множество. В нем есть все, что нужно для построения мощного многонитиевого приложения. Осталось выяснить, можно ли построить на базе этого интерфейса надежную прикладную программу реального времени.
Для этого время выполнения системного вызова должно быть предсказуемым и не зависеть от количества объектов в системе.
Для измерения времени выполнения некоторых системных вызовов подготовили несколько простых тестов [1]. Был разработан процесс (принадлежащий классу реального времени) с нитью, исполняющей системные вызовы синхронизации (Get Mutex). До и после каждого системного вызова Get Mutex отмечалось время (с помощью системного вызова QueryPerformanceCounter).
На время исполнения теста запретили своппинг и, кроме того, никакие ресурсы системы не были заблокированы - поэтому измерения корректны. Тестирование выполнялось на компьютере с процессором Pentium с тактовой частотой 100 МГц и 24 Мбайт оперативной памяти.
Для выполнения системного вызова Get Mutex (запрос на получение мьютекса), было получено среднее время исполнения 35 мкс. Но один раз максимальное время дошло до 670 мкс!
Почему? Да просто потому, что произошло прерывание от диска или сетевой платы - никакой другой деятельности во время исполнения теста не могло быть. Эта ситуация воспроизводилась множество раз во время исполнения теста - достаточно было увеличить количество передач с диска или из сети. С помощью подобного приема было достигнуто задержки выполнения этих системных вызовов до нескольких миллисекунд!
Конечно, API-интерфейс Win32 очень богат возможностями. Но следует отметить, он не слишком хорош для создания приложений реального времени. Например, запросы на получение мьютексов устанавливаются в очередь на исполнение в порядке их поступления, а не в порядке приоритетов породивших их нитей, что является недостатком с точки зрения предсказуемости. Системные вызовы, используемые в приложениях реального времени, следует выбирать с большой осторожностью. Например, для синхронизации нитей внутри одного процесса следует отдавать предпочтение критической секции перед всеми остальными системными вызовами (этот вызов занимает всего несколько микросекунд по сравнению с 35 микросекундами для Get Mutex).
Последнее замечание по поводу этого API: при использовании системных API-вызовов следует отметить, что некоторые из них обрабатываются системными процессами, работающими с низкими приоритетами (динамического класса). При этом вызывающая нить ожидает завершения исполнения вызова. А это чревато инверсией приоритетов.
На основании этих простых тестов было сделаyj следующее заключение: несмотря на все достоинства API, он опирается на плохо приспособленные к обработке событий реального времени ядро и менеджер ввода/вывода.
2.5. Управление прерываниями
Любая система реального времени взаимодействует с внешним миром через аппаратуру компьютера. Внешние события преобразуются в прерывания и обрабатываются драйвером устройства.
Доступ к аппаратуре имеют только драйверы. Поскольку приложения реального времени часто работают со специфическими внешними устройствами, требующими и специфического управления, разработчик системы реального времени под Windows NT должен уметь разрабатывать драйверы устройств. Посмотрим, как работает драйвер устройства.
Драйвер отвечает за обработку прерываний, генерируемых устройством. Для увеличения реактивности системы был разработан оригинальный механизм, при котором прерывания обрабатываются в два этапа. Сначала прерывание обрабатывается в очень короткой процедуре ISR (Interrupt Servicing Routine) внутри драйвера. Эта процедура выполняет только критические действия, блокируя при этом другие прерывания. Остальная часть обработки прерывания откладывается и ставится в очередь при помощи вызова процедуры отложенных прерываний DPC (Deferred Procedure Call). Последовательность действий при этом следующая:
1. происходит прерывание;
2. процессор сохраняет значения счетчика команд (PC) и указателя стека (SP) и обращается к диспетчеру (планировщику);
3. ОС сохраняет контекст и вызывает обработчик прерываний драйвера ISR;
4. выполняется ISR (критическая обработка);
5. драйвер вызывает функцию отложенной обработки прерываний DPC (на самом деле это очередь, обрабатываемая менеджером ввода/вывода);
6. драйвер устройства выходит из ISR;
7. ОС восстанавливает контекст;
8. процессор восстанавливает содержимое счетчика команд и указателя стека;
9. производится диспетчеризация отложенного прерывания на уровне приоритета диспетчеризации (DISPATCH-LEVEL). Это разновидность программного прерывания;
10. после завершения исполнения всех отложенных прерываний (DPC) ОС производит передиспетчеризацию пользовательских прикладных программ.
Из этого описания понятно, что обработка прерываний в Windows NT достаточно сложна. Более того, процедура обслуживания прерывания ISR должна быть написана очень грамотно и должна выполняться очень короткое время. Поэтому большинство драйверов выполняют основную часть обработки прерывания в DPC (которая может вытесняться только любой ISR). Различные DPC работают на одном и том же уровне приоритета и не могут вытеснять друг друга. Таким образом, время реакции разработанного вами драйвера сильно зависит от других драйверов.
Такого не должно быть в операционных системах реального времени. В ОСРВ разработчик в первую очередь узнает, на каких приоритетах работают драйверы других устройств. Здесь обычно существует свободное пространство для прерываний с приоритетами выше приоритетов стандартных драйверов. Вся критическая работа затем выполняется в ISR, позволяя разработчику настраивать конфигурацию его драйверов в зависимости от временных ограничений на прикладную программу. В Windows NT ISR очень быстрые, поэтому прерывания не блокируются на длительный период, но в самих ISR ничего не делается. Большая часть работы откладывается на DPC. Поэтому если вы пользуетесь плохо спроектированным драйвером от независимого поставщика, то, в конце концов, не уложитесь в заданный временной интервал, за исключением тех случаев, если вы будете выполнять всю работу в ISR - но тогда зачем нужна ОС?
2.6. Управление памятью
При проектировании системы реального времени необходимо рассмотреть и другой важный вопрос: как строится политика управления памятью в ОСРВ? Процессы Windows NT исполняются в собственном адресном пространстве, используют системные механизмы виртуальной памяти и страничной организации памяти. При этом страницы памяти могут выгружаться на диск, если не хватает оперативной памяти. Для бизнес-систем это прекрасно, но для систем реального времени это плохо, так как трудно предсказать время работы программы при подгрузке страниц памяти с диска. Однако Windows NT содержит механизм, позволяющий заблокировать страницы в памяти (функция VirtualLock) и тем самым решить эту проблему.
2.7. Другие вопросы для рассмотрения
Рассмотрим еще несколько вопросов, которые важны при построении систем реального времени.
Важным фактором встроенных приложений является размер оперативной памяти контроллера. По сравнению с другими имеющимися на рынке ОСРВ, Windows NT занимает весьма большую память. Для многосерийного производства лицензия на Windows NT слишком дорога – на больших сериях это выше стоимости систем исполнения большинства других ОСРВ.
2.8. Заключение
Так может ли Windows NT использоваться в качестве ОСРВ?
Как видно из вышеизложенного, Windows NT, созданная для работы главным образом с классическими приложениями, не может служить хорошей платформой для приложений реального времени, так как:
1. количество доступных приоритетов в классе реального времени слишком мало;
2. проблема инверсии приоритетов не решена;
3. занимаемая память слишком велика для встраиваемых приложений, а лицензия слишком дорога;
4. драйверы устройств могут тратить слишком много времени на уровне DPC и их невозможно вытеснить другим DPC.
Однако Windows NT может использоваться при создании систем мягкого реального времени со следующими особенностями:
1. системы мягкого реального времени, которые иногда допускают пропуск временных сроков;
2. простые системы, где количество событий различного рода не слишком велико (предсказуемость DPC в этом случае значительно выше);
3. нагрузка на центральный процессор всегда остается низкой (у системных DPC есть время для исполнения);
4. небольшое количество или отсутствие драйверов сторонних производителей либо хороший выбор драйверов сторонних организаций.
5. ответственные участки заданий (или даже всё задание целиком) выполняются на уровне DPC или, лучше, в самой ISR.
Это последнее соображение, однако, делает использование любой ОС бессмысленной.
Использование Windows NT для систем жесткого реального времени даже не подлежит обсуждению. Ваша система никогда не будет достаточно предсказуемой.
Что же нужно изменить в Windows NT, чтобы появилась возможность использовать ее в системах жесткого реального времени? Процессы класса реального времени должны иметь большее количество уровней приоритетов. Следует решить проблему инверсии приоритетов. Необходимо изменить всю систему прерываний:
1. понятие DPC - великолепная идея, но они должны иметь много уровней прерываний;
2. DPC должны иметь возможность прерываться более высокоприоритетными DPC;
3. драйверы независимых производителей и системные драйверы должны быть конфигурируемыми (уровень приоритета ISR, уровень приоритета DPC);
4. необходимо предоставлять разработчикам детальное описание драйверов независимых производителей, которые, как минимум, должны сообщать максимальное время исполнения ISR и DPC;
5. максимальное время, на которое ОС блокирует прерывания, также должно быть известно разработчикам;
6. и, наконец, должно быть известно время исполнения каждого системного вызова.
3. Операционная система QNX
В начале 80-х в университете Waterloo (Ontario, Canada) в результате исследований, проводимых в одном из отделов, была разработана новая операционная система, позволяющая организовать работу в реальном масштабе времени. Изначально, двое ее авторов были приверженцами различных платформ: Intel и Motorola, и благодаря этому, первая версия этой системы одинаково хорошо работала на обеих платформах. Когда они решили выйти с этой системой на рынок, за основу, все же был взят Intel. Первая версия системы (названная тогда QUNIX) была выпущена в 1981 году. Это произошло еще до того, как IBM создала свой PC, и возможно, поэтому, событию не было уделено достаточно внимания среди широкого круга пользователей. Однако, это событие не прошло незамеченным для промышленных и военных структур. Фирма Quantum Software Systems Ltd. (с марта 1993 года - QNX Software Systems Ltd.), организованная авторами новой ОС, начала разработку коммерческого варианта операционной системы QNX. Она выступила родоначальником многих современных технологий программирования. Когда UNIX вышел на арену со своей технологией макроядра, концепции микроядра с IPC (Inter Process Communications) на основе передачи сообщений, заложенные в QNX в 1980 году, уже не были новинкой.
При поддержке монолитных ОС возникает ряд проблем, связанных с тем, что все функции макроядра работают в едином адресном пространстве. Во первых - это опасность возникновения конфликта между различными частями ядра, во вторых - сложность подключения к ядру новых драйверов. Преимущество микроядерной архитектуры заключается в том, что каждый компонент системы представляет собой самостоятельный процесс, запуск или остановка которого не отражается на работоспособности остальных процессов. Основная идея, заложенная в технологию микроядра, будь то операционная система или графический интерфейс, заключается в том, чтобы конструировать необходимую среду верхнего уровня, из которой можно легко получить доступ ко всем функциональным возможностям уровня аппаратного обеспечения. При такой структуре ядро служит стартовой точкой для создания системы. Искусство разработки микроядра заключается в выборе примитивов, которые должны в нем находиться для обеспечения необходимого и достаточного сервиса.
Процессы
Рис.1 Ядро ОС QNX
В QNX размер ядра составляет около 10 Кбайт и обеспечивает поддержку 14 основных системных вызовов для предоставления сервиса по четырем направлениям:
1. IPC.
2. Диспетчеризация процессов.
3. Обработка прерываний.
4. Перенаправление сообщений по сети.
QNX поддерживает три основных типа IPC: сообщения, proxies и сигналы.
IPC на основе передачи сообщений базируется на трех основных примитивах Send(), Receive() и Reply(). Например, процесс A посылает сообщение процессу B с помощью функции Send(), принимающий процесс (B) находится в состоянии ожидания при помощи функции Receive(). После приема сообщения, процесс B, с помощью функции Reply(), отвечает процессу A, который находится в состоянии ожидания ответа. После чего посылающий процесс (A) разблокируется и продолжает работу. Такой механизм взаимных блокировок позволяет легко синхронизировать выполнение взаимодействующих процессов. Весь остальной сервис, предоставляемый в плане взаимодействия процессов (конвееры, очереди сообщений и т. п.), основывается на этом механизме. QNX копирует сообщения непосредственно из адресного пространства передающего процесса в адресное пространство принимающего, без создания дополнительных буферов. Поэтому “доставка” сообщений выполняется, практически, со скоростью, которую может позволить аппаратное обеспечение.
Рис.2 Диаграмма производительности механизма передачи сообщений в зависимости от объема сообщений (в байтах) для различных аппаратных платформ
Proxy - является специальным видом сообщения, которое позволяет посылающему процессу избегать блокированного состояния. В данном случае посылающий процесс сигнализирует о каком-либо событии с помощью функции Trigger() и, не дожидаясь ответа, продолжает работу.
Сигналы представляют собой традиционный метод асинхронного взаимодействия, который многие годы используется в различных ОС. В данном случае, стоит только отметить, что QNX поддерживает все типы сигналов, описанные стандартом POSIX, сигналы, специфичные для QNX, а также набор сигналов, исторически сформировавшийся в UNIX.
К выполнению своих функций, как диспетчера, ядро приступает в следующих случаях:
· какой-либо процесс вышел из блокированного состояния
· истек квант времени для процесса, владеющего CPU
· работающий процесс прерван каким-либо событием
Диспетчер выбирает процесс для запуска среди неблокированных процессов, в порядке значений их приоритетов, которые располагаются в диапазоне от 0 (наименьший) до 31 (наибольший). Обслуживание каждого из процессов зависит от метода диспетчеризации с которым он работает (уровень приоритета и метод диспетчеризации могут динамически меняться во время работы). В QNX существуют три метода диспетчеризации: FIFO (первым пришел - первым обслужен), round-robin (процессу выделяется определенный квант времени для работы) и адаптивный, который является наиболее используемым. Процесс, работающий с адаптивным методом ведет себя следующим образом:
Когда процесс полностью использовал выделенный ему квант времени, его приоритет снижается на 1, если в системе есть процессы с тем же уровнем приоритета, готовые к исполнению.
Если процесс с пониженным приоритетом остается необслуженным в течении секунды, его приоритет увеличивается на 1.
Если процесс блокируется, ему возвращается оригинальное значение приоритета.
Быстродействие многозадачной системы в значительной степени зависит от того, как быстро она может осуществлять переключение задач, конкурирующих за процессорное время. Этот фактор важен не только в случае создания программных комплексов, критичных ко времени, но и для любых диалоговых систем, когда медленная реакция системы не только снижает скорость работы, но и отрицательно сказывается на нервной системе пользователя. В результате проведения тестов различных ОС на различных аппаратных платформах были получены следующие результаты:
Табл.1. Время переключения контекстов в различных OS.
OC | ЭВМ | Время на переключение, (микросекунды) |
QNX 4.2 | 60 MHz ALR Pentium | 28 |
HP-RT 1.1 | 100 MHz HP-747x | 34 |
QNX 4.2 | 66 MHz IBM 80486DX2 | 44 |
QNX 4.2 | 33 MHz IBM 80486DX | 80 |
DEC OSF/1 V1.3 | 150 MHz DEC 21064 | 93 |
SunOS 4.1.3 | 50 MHz SuperSPARCv8 | 95 |
DEC 3000 | 150 MHz DEC 21064 | 100 |
AIX 3.2 | 62 MHz RS6000 | 102 |
HP-UX 9.x | 66 MHz snake | 106 |
SunOS 4.1.3 | 40 MHz viking | 128 |
Ultrix 4.3 | 40 MHz Digital MIPS R3000 | 132 |
Linux 0.99.13p | 66 MHz Gateway 80486DX2 | 171 |
SunOS 4.1.1 | 33 MHz Sun SPARC | 198 |
386BSD 0.1 | 33 MHz IBM 80486DX | 210 |
AIX 3.2 | 50 MHz RIOS | 212 |
SunOS 4.1.3 | 50 MHz SPARCv7 | 230 |
Unicos | Cray Y/MP | 373 |
QNX 4.2 | 16 MHz IBM 80386SX | 525 |
Solaris 2.3 | 50 MHz microSPARCv8 | 595 |
Система обработки прерываний, заложенная в ядре, служит для перенаправления аппаратных прерываний процессам, осуществляющим передачу данных между компьютером и переферийными устройствами на низком уровне. Этот механизм позволяет пользователю избежать работы с аппаратным обеспечением напрямую, и тем самым, избегать конфликтов между различными процессами, работающими с одним и тем же устройством. Для обработки сигналов от внешних устройств чрезвычайно важно минимизировать время между возникновением события и началом непосредственной его обработки. Этот фактор существен в любой области применения, от работы терминальных устройств до возможности обработки высокочастотных сигналов.
Табл. 2. Показатели задержки по времени между возникновением события и началом непосредственной его обработки
ЭВМ | Задержка, (микросекунды) |
Pentium/60 | 3 |
486DX2/66 | 5 |
486DX/33 | 8 |
386DX/33 | 15 |
В плане распределенных вычислений, с QNX пока трудно соревноваться какой-либо ОС. Она может обеспечивать одновременную передачу данных по 3 сетям, сочетая разнообразный набор сетевого оборудования. Так, на одном компьютере, в одно и тоже время могут использоваться Arcnet, Ethernet и Token Ring. Кроме того, сеть можно организовать без использования сетевых карт, ограничившись интерфейсом RS232. Хотя, в определенном смысле, это является скорее расширением, чем ограничением. Так как, подсоединив модем к своему компьютеру, Вы можете организовать полноценную сеть с узлами, территориально удаленными на любое расстояние.
Для обеспечения передачи данных по сети она использует администратор сети (Net), который взаимодействует непосредственно с ядром. Когда ядро получает запрос на передачу данных процессу, находящемуся на удаленном узле, он переадресовывает этот запрос Net, в подчинении которого находятся драйверы всех сетевых карт. Имея перед собой полную картину состояния всего сетевого оборудования, Net может отслеживать состояние каждой сети и динамически перераспределять нагрузку между ними. В случае, когда одна из сетей выходит из строя, информационный поток автоматически перенаправляется в другую доступную сеть, что очень важно при построении высоконадежных систем. Кроме поддержки своего собственного протокола, Net обеспечивает передачу пакетов TCP/IP, SMB и многих других, используя то же сетевое оборудование. Производительность QNX в сети приближается к производительности аппаратного обеспечения. Тесты, проведенные с различными сетевыми картами (Corman Arcnet, NE2000 и Thomas-Conrad 100Mbit TC3045-CX), вставляемыми в шину ISA, показали следующие результаты:
Рис.3 Диаграмма производительности QNX сети в зависимости от объема передаваемых данных (в байтах) для различных типов аппаратного обеспечения.
Немаловажным фактором обеспечения работы в реальном масштабе времени является производительность файловой системы.
Fsys - это менеджер ресурсов, который обеспечивает пользователю POSIX - стандартную файловую систему в среде QNX. Основным ее преимуществом по сравнению с файловой системой UNIX является живучесть, уменьшенная фрагментарность файлов и увеличенная скорость работы. Сами файлы в QNX организованы по принципу набора участков, ссылки на которые находятся в дескрипторах файлов и в отдельных участках дисковой памяти. Он создает следующую дисковую структуру: для отслеживания свободного дискового пространства он использует битмэп, а для организации данных - массив расширений для каждого файла. Такая структура позволяет процессам пользователя осуществлять доступ к данным на диске со скоростью, близкой к скорости аппаратного обеспечения. На 33 MHz 486 чтение производится со скоростью 2.2 M/sec, запись - 1.85 M/sec. На 60 MHz Pentium чтение - 2.8 M/sec, запись - 2.5 M/sec. Для этого теста использовался Buslogic BT-445S VESA Localbus SCSI контроллер.
Для улучшения целостности данных в работу файловой системы добавлен вызов функции fsync(). В большинстве UNIX систем, когда вы работаете с файлом в синхронном режиме, любой обмен данными с файлом влечет за собой обращение непосредственно к диску и изменение структуры данных, значительно снижая производительность. Вызов fsync(), описанный в POSIX 1003.4, позволяет вам работать с файлом в асинхронном режиме, вызывая fsync() только после прохождения критических участков (например, по окончании обмена) чтобы гарантировать, что все структуры данных на диске были изменены соответствующим образом.
Основные принципы архитектуры QNX остались неизменными с момента создания ее коммерческого варианта в 1982 году - микроядро, окруженное группой взаимодействующих процессов, которые обеспечивают высокоуровневый сервис ОС, но производительность QNX значительно возросла пройдя эволюционный путь от версии 1.00 до версии 3.15.
Общая проблема создания всех ОС реального времени заключалась в том, что каждая такая система снабжалась своим собственным уникальным интерфейсом. При отсутствии индустриального стандарта - это было нормальным состоянием при жесткой конкуренции на рынке. С появлением стандарта POSIX 1003.4, операционные системы реального времени получили ориентир для стремления к всеобщей совместимости.
В 1989 году была начата разработка новой POSIX-стандартной версии QNX (4.0). Целью этого проекта было повышение производительности и гибкости, которые обеспечивали предыдущие поколения системы. Новая версия была выпущена в 1991 году.
Благодаря соответствию стандарту POSIX пользователи QNX получили целый ряд преимуществ: совместимость исходных текстов прикладных программ, составленных в разных операционных системах, независимость от типа процессора, возможность сокращения штата разработчиков за счет того, что программисты, имеющие опыт работы в других POSIX-стандартных ОС без особого труда могут работать в среде QNX.
Необходимость лучшей совместимости особенно актуальна для рынка ОС реального времени, который отличается большим разнообразием используемых процессоров и операционных систем. Кроме того, дополнительная проблема при создании таких систем заключается в том, что многие разработчики большую часть программ пишут на ассемблере, пытаясь обеспечить лучшую производительность. Недостаток такого подхода очевиден: для переноса таких программ на другую аппаратную платформу требуется полная их переработка. Использование компилятора C фирмы Watcom в среде ОС QNX позволило пользователям составлять свои критичные ко временным характеристикам программы на языке высокого уровня без снижения производительности.
В настоящее время QNX версии 4.21, представляет собой гибрид 16/32 - битовой операционной системы, которую пользователь может конфигурировать по своему усмотрению. Время, необходимое для полной инсталляции системы, которая занимает на диске менее 7 Mb, составляет всегоминут, в зависимости от быстродействия компьютера.
Существует поддержка SCSI устройств, c полным распараллеливанием доступа к дискам, стримерным лентам и CD-ROM. Это большой плюс для систем RAID, требующих количества устройств, большего, чем может поддержать одна карта.
Разнообразием различных графических интерфейсов QNX может порадовать любого разработчика. Это, в первую очередь, библиотека графических функций, в составе пакета Watcom C, полнофункциональная оконная система QNX Windows, выполненная в соответствии со стандартом Open Look, графический интерфейс для ограниченной в ресурсах встраиваемой системы - Photon, поддерживающий Motif стандарт и требующий всего 256K оперативной памяти, X Window - графический стандарт для всех открытых систем, и, наконец, если вам нужен доступ к популярному настольному программному обеспечению, вы всегда можете запустить Microsoft Windows с помощью утилиты Rundos.
Благодаря своей модульной архитектуре QNX обладает чрезвычайной гибкостью при конфигурировании системы. Поэтому она может использоваться и как среда разработки на мощных компьютерах и как среда исполнения в миниатюрных встраиваемых системах. С точки зрения разработчика большое преимущество заключается в том, что разработку и отладку можно производить в той же среде, в которой будет функционировать готовая система. Однако, при желании, в качестве кросс-среды можно использовать UNIX или DOS. Это свидетельствует о совместимости программных продуктов для этих систем на уровне исходных текстов.
На сегодняшний день, QNX используется, по крайней мере, в 200,000 систем, преимущественно там, где высокая производительность, гибкость системы и прекрасные сетевые возможности являются фундаментальными требованиями. Широкая область ее применения была обеспечена тем, что технология микроядра подходит для создания систем критичных ко времени и ресурсам, таких как управление процессами, медицина, обработка финансовых документов и т. д. Более чем 10-летняя проверка временем подтверждает ее жизнеспособность. Со времени первого появления QNX на рынке операционных систем, она была использована во многих тысячах проектах. Наиболее яркими примерами ее использования является всемирно известная система кредитных карточек VISA, система обработки видеоизображений фирмы Kodak, система управления ядерным реактором, разработанная приморским отделением канадской компании Atomic Energy of Canada Ltd., система автоматизации добычи нефти и газа фирмы Texaco, система управления движением городского транспорта в городе Оттава - Карлетон (Канада). На сегодняшний день ОС QNX охватывает 80% рынка Real Time ОС для PC. К 1994 году фирма QNX Software Systems Ltd. имеет дистрибьютеров в более чем 60 странах мира. Пользователями QNX являются такие фирмы, как Alcatel, Asea Brown Bovery, British Telecom, Canon, Honda, Mitsubishi, Panasonic, Saab, Siemens и Sony. В России QNX также успешно используется многими промышленными предприятиями. В настоящее время трудно найти отрасль в которой QNX еще не нашла себе применения. Разнообразные системы на базе QNX используются в медицине, фармацевтике, металлургии, автомобилестроении, коммуникациях, торговле, банках и в любых областях промышленности, где требуется распределенная обработка информации в реальном масштабе времени.
4. Примеры современных систем регулирования и управления
4.1. Автоматизированная система контроля теплопрочностных испытаний продукции
4.1.1. Введение и постановка задачи
Существует большое количество различных ограничений, нормативов, стандартов для материалов, из которых изготавливают те или иные конструкции, сооружения или фрагменты техники. Регламентируются не только граничные величины таких параметров, как допустимые температура эксплуатации и механическое напряжение, но и их градиентные значения. Космический корабль, проходящий через плотные слои атмосферы, взлетающий самолет или ледокол, прорубающий толщу льда, испытывают колоссальные температурные и механические нагрузки. И от того, насколько точно была рассчитана реакция конструкций при возможных пиковых температурах и силовых воздействиях и насколько близки расчетные значения к реальной картине испытаний, напрямую зависит безопасность многих людей. Определить поведение материалов в тех или иных условиях позволяют теплопрочностные испытания (ТПИ). Они, как правило, являются многофакторными испытаниями, при проведении которых к материалу или конструкции прикладываются одновременно несколько типов воздействий: нагрев, силовое нагружение, давление. Такие испытания позволяют не только определить поведение материала в тех или иных условиях, но и выявить возможные скрытые дефекты, такие как пустоты, образующиеся при литье, или дефекты кристаллической структуры, возникшие при нарушении условий технологического процесса.
НПО машиностроения в подмосковном г. Реутове разработало стенды, обеспечивающие проведение теплопрочностных испытаний крупногабаритных изделий.
Наиболее ответственная часть такого стенда — подсистема воспроизведения температурных полей и градиентов, близких по конфигурации к возникающим в реальных условиях. В соответствии с ожидаемыми условиями эксплуатации производится расчет изменения температуры поверхности изделия во времени.
Для воспроизведения профиля температуры на поверхности изделия с заданной точностью разбивают поверхность изделия на определенные участки — зоны нагрева. На каждую зону нацеливается матрица галогеновых ламп, которые запитываются от управляемых источников электроэнергии. Для каждой зоны нагрева задается временная зависимость изменения температуры, максимальное значение температуры и скорость нагрева.
Аналогичным образом в зависимости от реальных условий эксплуатации рассчитываются используемые в прочностных испытаниях законы изменения во времени прикладываемых к изделию сил и давлений.
Специалистами НПО машиностроения были разработаны соответствующие методики и предложена структура автоматизированной системы контроля (АСК) теплопрочностных испытаний. В качестве разработчика этой системы, поставщика специализированного оборудования и программного обеспечения выступила фирма Антрел. Новая разработка заменила морально устаревшую и не удовлетворяющую современным требованиям систему. Ранее результаты испытаний оценива лись по графикам, вычерчиваемым самописцами. Для того чтобы контролировать соответствие измеряемых и расчетных параметров, на бумагу для самописцев заранее наносились кривые функциональных зависимостей, согласно которым должны изменяться температура или напряжение материала в определенной зоне испытываемого образца (опорные графики). Характерной особенностью проводимых на стендах испытаний является высокая динамика изменения контролируемых параметров, чем обусловлены жесткие требования к быстродействию системы. Время реакции системы (промежуток времени от изменения сигнала на входе до отображения на экранах АРМ операторов) должно быть не более 100 миллисекунд при более чем 100 контролируемых входных параметрах.
Образцы, испытываемые в НПО машиностроения, отличаются размерами и материалами, из которых они изготовлены, следовательно, требуют индивидуальных методик испытаний. Таким образом, перед разработчиками встала задача создать универсальную систему, которая могла бы быть легко и быстро переконфигурирована в соответствии с условиями каждого конкретного испытания.
4.1.2. Структура АСК
В соответствии с поставленными задачами была разработана двухуровневая АСК теплопрочностных испытаний. Структурная схема этой системы представлена на рис. 1.
Рис. 1. Структурная схема АСК теплопрочностных испытаний
Нижний уровень образует два контроллера сбора данных. Верхний уровень состоит из одиннадцати компьютеров, которые представляют собой АРМ системного оператора, АРМ ведущего оператора, восемь АРМ операторов нагрева и АРМ оператора нагружения.
Прием данных от нижнего уровня происходит с помощью последовательного интерфейса RS-485 в ПК системного оператора. На остальные рабочие места данные транслируются через локальную сеть Ethernet.
4.1.3. Функции, выполняемые АСК
Нижний уровень:
Контроллер № 1 предназначен для сбора данных с термопар, тензодатчиков, датчиков перемещения и давления, установленных на испытуемом объекте, а также для управления программируемым калибратором. Роль процессорной платы выполняет микроконтроллер CPU188_5MX фирмы Fastwel. Для ввода аналоговых сигналов в контроллере использованы следующие комплектующие:
· 32-канальный коммутатор аналоговых сигналов AIMUX-32-2 фирмы Fastwel для ввода сигналов от потенциометрических датчиков давления и смещения (на этой плате также расположен датчик для измерения температуры холодного спая термопар);
· 16 изолированных модулей аналогового ввода 5B37 фирмы Analog Devices, установленные на плате 5B02 и предназначенные для преобразования 16 гальванически не связанных общими цепями аналоговых сигналов от хромель-алюмелевых термопар (типа К) в напряжение от 0 до 5 В; с выхода платы 5В02 сигнал поступает на один из входов AIMUX-32-2;
· два 16_канальных изолированных модуля для ввода аналоговых сигналов от термопар; эти адаптеры были специально разработаны для НПО машиностроения фирмой Антрел, поскольку на этом предприятии используются термопары различных типов, в том числе отечественного производства (хромель-копель, вольфрам-рений), которые не поддерживаются стандартизованными зарубежными адаптерами; использование данных устройств позволяет плавно перестраивать шкалу измерения каждого термопарного входа от 10 до 100 мВ индивидуально в процессе калибровки, что минимизирует погрешности;
· четыре модуля нормализации сигналов тензомоста ADAM_3016, подключенные к мультиплексору AIMUX-32;
Контроллер имеет возможность дистанционного управления внешним калибратором измерительных каналов. Точность измерения параметров изделия (температура, давление, нагружение) — не ниже 0,1%.
Согласно техническому заданию контроллер должен быть установлен в стойку, поэтому для сборки его корпуса был использован приборный конструктив серии Сompac и деталировка Евромеханики фирмы Schroff. Это, конечно, дороже, чем использование электротехнического шкафа той же фирмы для размещения узлов контроллера, однако пропорционально стоимости корпуса возросла и плотность упаковки оборудования в нем.
Для контроллера создано специальное программное обеспечение, реализующее функции опроса всех входных сигналов с заданным периодом, управления внешним калибратором и поддержки специально разработанного протокола обмена с компьютерами верхнего уровня.
Технологический контроллер № 2 предназначен для контроля сигналов управления и мониторинга значений токов и напряжений, поступающих с ртутно_преобразовательной подстанции, осуществляющей питание нагревательных элементов. Данный контроллер построен на базе изделий фирмы Advantech. В его состав входят процессорная плата PCA-6135L, открытый крейт ICP-6006, плата АЦП PCL-813B и модуль преобразователя интерфейса RS-232/485 ADAM-4520. Оборудование собрано в электротехническом шкафу CONCEPTLINE (600×400×4220) фирмы Schroff.
Специально разработанное программное обеспечение позволяет вести сбор данных со входов АЦП и их усреднение за заданный период времени, а также обмен данными с компьютерами верхнего уровня с помощью протокола обмена, подобного используемому в контроллере № 1.
Все программное обеспечение нижнего уровня написано на языке С.
Верхний уровень:
Программное обеспечение верхнего уровня осуществляет управление процессом теплопрочностных испытаний изделий, который заключается в одновременном силовом нагружении и нагреве, а также сбор технологических параметров, позволяющих судить о ходе испытаний. В зависимости от сложности и характера испытаний может использоваться от 1 до 8 зон нагрева. В свою очередь, каждая зона может включать от 1 до 12 термопар. Таким образом, каждая зона нагрева характеризуется:
· количеством измеряемых параметров (1-12 термопар);
· номерами каналов, к которым подключены термопары;
· типами термопар;
· опорными графиками для каждой зоны.
В параметрах силового нагружения варьируются количество и типы датчиков давления, перемещения и силы, а также номера аналоговых каналов, к которым они подключены.
Гибкая настройка системы осуществляется процедурой «Конфигурирование системы», которая обеспечивает создание различных настроечных файлов и их выбор для конкретного испытания. Настроечные файлы хранятся в компьютере системного оператора и считываются оттуда по локальной сети Ethernet при запуске других АРМ.
За операторами системы закреплены различные функции.
1. Системный оператор осуществляет полный контроль испытаний. На экране его компьютера в числовом и графическом виде отображаются все измеряемые параметры. С АРМ системного оператора по локальной сети подаются команды о начале, паузе и окончании испытаний, выполняются настройка системы и архивирование данных.
2. Ведущий оператор осуществляет наблюдение за процессом нагрева. На экране АРМ ведущего оператора в виде графиков отображается протекание процесса нагрева по всем зонам и выполняется контроль соответствия реальных параметров опорному графику нагрева.
3. Оператор нагрева осуществляет наблюдение за процессом нагрева, регулирует вручную скорость нагрева, управляя напряжением, подаваемым на нагревательные элементы, контролирует соответствие процесса испытания опорному графику зоны.
4. Оператор нагружения осуществляет контроль силовых параметров испытаний и ведет нагружение системы в соответствии с опорными графиками силы и давления по каждому каналу.
Все программное обеспечение рабочих станций создано с помощью пакета LabVIEW 5.0, и работает под управлением операционных систем Windows 98/2000. Выбор данного программного пакета обусловлен тем, что он, обладая гибкостью мощного языка программирования, позволяет разработчику найти оптимальную синхронизацию процессов приема-передачи, обработки и отображения информации в реальном времени, получить эргономичную картину процесса с динамикой изменения, близкой к предельной скорости восприятия оператора. Например, вполне удается плавная прорисовка нескольких температурных кривых от термопар в поле графика, на которое с опережением в 10 секунд наносится кривая опорного графика из заданного файла; при этом данные от термопар перед отображением проходят полиномиальную линеаризацию. Об универсальности языка программирования LabVIEW можно судить и по тому, что процедуры обмена с контроллерами по RS-485 и между компьютерами верхнего уровня по Ethernet (протокол TCP/IP) были разработаны при помощи только базовых графических операторов языка.
4.1.4. Заключение
Результатом проделанной работы стала система, удовлетворяющая современным требованиям и реализованная на основе новейшей элементной базы. Это универсальная и легко переконфигурируемая система, позволяющая проводить испытания различной направленности и сложности.
Для того чтобы повысить воспроизводимость испытаний, планируется доработка существующей системы с целью добавления функции автоматического регулирования мощности, подаваемой на нагревательные элементы и механизмы нагружения.
4.2. Система стабилизации тока выпрямительных агрегатов электрохимических производств цеха №2 ЗАО "Каустик"
Одной из актуальных задач повышения эффективности электрохимических производств является устранение скачков питающего тока на входе в электрохимические агрегаты (электролизеры). Достижение данной цели возможно путем высокоточного управления дросселями насыщения (ДН), входящими в состав выпрямительного агрегата типа ВАКВ2 (рис. 2), включающего также силовой трансформатор с блоком регулирования под нагрузкой (РПН) и основные выпрямительные блоки (ВБ). Для решения поставленной задачи предлагается новая система, построенная на современных средствах автоматизации, позволяющая повысить точность и быстродействие системы стабилизации тока и управления агрегатом в целом и, тем самым, исключить броски тока.
Источники и потребители тока в данных производствах территориально разнесены, поэтому для реализации соответствующих алгоритмов синхронного управления и сбора данных предложено использовать распределенную сетевую структуру программируемых контроллеров серии ADAM-4000 с интерфейсом RS-485: модули цифрового ввода-вывода ADAM-4052, модули релейного цифрового вывода ADAM-4063, модули скоростного аналогового ввода ADAM-4017F и ADAM-4012. Они служат для передачи сигналов управления на реле переключения ступеней блока РПН и сигнала тока управления ДН, а также для передачи сигналов о состоянии агрегатов в целом. В качестве вычислительного ядра рабочей станции управления выбран промышленный компьютер фирмы Advantech PPC-123 с операционной системой Windows NT, обеспечивающий надежную работу в режиме реального времени. Вместе с дополнительными модулями (в том числе, модулем согласования интерфейсов ADAM-4520) и устройствами отображения и ввода информации он реализует процесс сбора информации реального времени с удаленных точек (объектов) обработки, анализа и возможного управления удаленными объектами. Требование обработки реального времени обусловлено необходимостью доставки (выдачи) всех наблюдаемых событий (сообщений) и данных на центральный интерфейс оператора. Основой программного комплекса является инструментально-исполнительная система реального времени GeniDAQ 4.11 фирмы Advantech. Для алгоритмизации процесса и моделей управления был использован язык моделирования UML, что позволило в рамках единой нотации анализировать задачи управления, стратегии программы и средства динамической визуализации информации. Применение SCADA совместно с языками моделирования UML позволяет достичь высокого уровня автоматизации в решении задач разработки и эксплуатации систем управления, сбора, хранения и отображения информации.
Неотъемлемой частью любого программного продукта, который предназначен для использования в интерактивном режиме, является человеко-машинный интерфейс. Он объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на взаимодействие пользователя с программным обеспечением. К этим элементам относятся: средства отображения информации, отображаемая информация, форматы и коды; командные режимы, язык пользователь-интерфейс; устройства и технологии ввода данных; диалоги, взаимодействие и транзакции между пользователем и компьютером; обратная связь с пользователем; поддержка принятия решений в конкретной предметной области.
Данная технология была применена при разработке интерфейса оператора системы. На рис. 3 представлен граф, отражающий взаимосвязь экранов интерфейса оператора при всех режимах работы системы. он представляет собой два подграфа: первый - линейный граф "Пуск"-"Режим"-"Останов" и регулярный полный граф степени 4 ("Режим", "Автомат", "Ручное", "Информация", "График"). Вершина "Режим" является точкой пересечения графов и предоставляет возможность перехода к любому экрану (вершине графа). Реализация указанного графа осуществлена в SCADA-системе GeniDAQ и представляет собой стратегию управления переходами интерфейса оператора в соответствии с выбранным режимом работы системы.
На рис. 4 представлен экран "Ручное". На нем имеются кнопки управления переходом к соответствующим экранам ("Режим", "Автомат", "Информация", "График"). Кнопки "Действия" позволяют, соответственно, организовать доступ к средствам управления экрана ("Разрешение"), зафиксировать экран ("Блокировка") и остановить выполнение текущего сценария управления программы ("Стоп"). Органы управления установками представляют собой визуальные имитаторы ползунковых круговых регуляторов и утапливаемых кнопок управления режимами работы агрегатов ("Вверх", "Вниз"). Экран замыкает на себя управление тремя агрегатами в ручном режиме работы системы. Динамическая индикация основных параметров работы агрегатов (выходной ток агрегата и токи управления) реализована при помощи цифровых индикаторов (текущее и заданное значение по каждому параметру).
Аналогично организовано взаимодействие оператора с агрегатом и управление переходами на остальных экранах интерфейса, которые имеют в общем случае зоны управления, индикации, переходов и действий. Только для экранов "Пуск" и "Останов", ввиду их концевого положения отсутствует зона перехода и действий, а зона управления предусматривает подробную трассировку команд в данных режимах.
Таким образом, разработанный интерфейс позволяет эффективно использовать экранную поверхность для взаимодействия оператора с органами управления системой во всех режимах работы агрегатов. В ответственных режимах "Пуска" и "Останова" экран интерфейса насыщен необходимыми органами управления объектом, в рабочих режимах функциональные экраны образуют единое информационное пространство с динамическим переходом.
В предлагаемой системе устранение колебаний и скачков тока производится путем управления блоком регулирования под нагрузкой совместно с плавным регулированием тока управления дросселей насыщения
- это обеспечивает устранение скачков тока при переключении ступеней основного питающего трансформатора и колебаний, вызванных изменением нагрузки.
Система обеспечивает управление тремя параллельно включенными выпрямительными агрегатами в ручном и автоматическом режимах. Предусмотрены также режимы автоматического «пуска» и «останова» всех 3-х агрегатов. В автоматическом режиме система обеспечивает амплитуду колебаний выпрямленного тока не более 
. В любом из режимов работы на компьютер оператора выводится информация о выходных токах всех агрегатов, о суммарном токе нагрузки и токах управления дросселей насыщения. Для обеспечения надежности обмена сигналами в алгоритмах работы системы предусматривается логическая проверка адекватности полученных сигналов процессу управления.
В настоящее время разработанная система изготовлена, отлажена и находится в опытно-промышленной эксплуатации.
4.3. Автоматика сушильных камер для качественной сушки пиломатериалов
4.3.1. Система автоматики сушильной камеры "Модуль-С1"
Автоматика сушильной камеры предназначена для контроля и управления технологическим процессом сушки древесины. Система обеспечивает контроль и поддержание заданных параметров температуры и влажности агента сушки в сушильной камере в соответствии с заданной программой.
Комплект поставки "МОДУЛЬ-С1".
1. Микропроцессорный шкаф управления.
2. Силовой шкаф управления.
3. Комплект датчиков для измерения температуры и влажности.
4. Комплект датчиков для измерения влажности пиломатериала.
5. Приточно-вытяжные заслонки с электроприводом и без электропривода (ведущие и ведомые).
6. Клапаны подпитки водой парогенератора и психрометрических датчиков влажности сушильной камеры.
7. Блоки исполнительного механизма управления вентилем теплоносителя.
8. Распределительная коробка и кабели соединения силового и микропроцессорного шкафа.
9. Технология процесса сушки (алгоритмы сушки) и рекомендации по сушке пиломатериалов.
Рис. 5. Демонстрация заказчику на рабочем макете возможностей системы управления "Модуль-С1"
Поставляемые составные части выполнены в виде законченных узлов, готовых к монтажу. Соединительные провода, трубопроводы в комплект поставки не входят. Определённые параметры - мощность и количество электродвигателей, их реверс, расположение заслонок, оговариваются при заказе. В оперативной памяти микропроцессорного контроллера "Модуль-С1" заложено 144 программы для сушки различных сортиментов древесины, при этом с ПК или микропроцессорного шкафа, возможно, корректировать любую из программ по усмотрению оператора сушильной камеры.
Рис. 6. АСУП Модуль-С1 комплекса камер сушки в работе
Рис. 7. Автоматика сушильной камеры Модуль С - 1. Обучение оператора заказчика на действующей сушильной камере. (Вологодская обл. 2005г.)
Комплект аппаратных и программных средств автоматической системы управления "Модуль-С1" камерой сушки древесины обеспечивает:
1) Контроль:
· состояние приточно-вытяжных заслонок;
· архив контролируемых параметров;
· температуры наружного воздуха, сухого и влажного термометров в сушильной камере и температуру теплоносителя;
· влажность пиломатериала кондуктометрическим способом;
· наличие воды в парогенераторе и ванночке психрометра.
2)Управление сушильной камерой через силовой шкаф:
· системой увлажнения, кондиционирования и пропарки;
· вентиляторами и их реверсом;
· подпитка водой системы увлажнения;
· подпитка водой влажного термометра;
· управление контуром водяного обогрева;
· звуковой и световой аварийной сигнализацией.
3)Отображение на панели контроллера:
· текущей температуры сухого и влажного термометров;
· температуру окружающей среды и теплоносителя;
· текущей влажности пиломатериала,
· просмотр архива контролируемых параметров;
· состояние механизмов и датчиков.
4)Задание следующих параметров:
· конечная влажность пиломатериала;
· степень жесткости режима сушки;
· порода древесины;
· толщина пиломатериала и другие технологические параметры.
5) Диагностика:
· датчиков температуры;
· наличие трехфазного напряжения;
· включение механизмов;
· других аварийных ситуаций.
Микропроцессорный контроллер имеет интерфейс для подключения к персональному компьютеру. К одному ПК одновременно можно подключить до 16-ти контроллеров, т. е. с одного персонального компьютера можно управлять работой 16-ти автономных сушильных камер. ПК может находиться на расстоянии до 1000 м от шкафов управлении и сушильных камер. Программное обеспечение персонального компьютера позволяет:
· изменять технологические параметры в процессе сушки древесины;
· дистанционно управлять процессами в сушильной камере и проводить диагностику;
· рассматривать, документировать и распечатывать параметры процесса сушки;
· задавать режимы сушки, степень жесткости режима.
Система "Модуль–С1" позволяет максимально снизить влияние человеческого фактора на процесс сушки, произвести сушку древесины с соблюдением отработанной и заданной технологии, проконтролировать соблюдение технологического режима и максимально облегчить работу оператора при управлении сушильной камерой. Возможно заключение договора на проведение пуско-наладочных работ системы, обучение персонала и проведение контрольной сушки.
Литература
1. Real-Time Magazine, №2, 1997.
2. Ющенко C. В. ОС QNX - реальное время, реальные возможности...– Мир ПК, №5-6, 1995.
3. и др. – Современные технологии автоматизации.
4. Современные технологии автоматизации, №1, 2002.
5. http://www. *****/index. htm.
