Программное обеспечение систем управления

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

Синхронизация задач

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

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

2. Необходимо упорядочить доступ нескольких задач к разделяемому ресурсу.

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

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

Давайте рассмотрим все четыре случая более подробно.

Связанные задачи

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

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

Иногда сообщения передаются через отведенный для этого буфер определенного размера ("почтовый ящик"). При этом, как правило, новое сообщение затирает старое, даже если последнее не было обработано.

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

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

Общие ресурсы

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

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

Вот возможные пути решения проблемы.

1.He использовать алгоритмы планирования задач с вытеснением. Это решение, правда, не всегда приемлемо.

2. Использовать специальный сервер ресурса, то есть задачу, ответственную за упорядочивание доступа к ресурсу.

3. Запретить прерывания на время доступа к разделяемым данным Кардинальное решение, которое, впрочем, не приветствуется в системах реального времени.

4. Использовать для упорядочивания доступа к глобальным данным семафоры. Наиболее часто применяемое решение, которое, впрочем, может привести в некоторых случаях к "инверсии приоритетов".

Семафор - это как раз то средство, которое часто используется для синхронизации доступа к ресурсам. В простейшем случае семафор представляет собой байтовую переменную, принимающую значение 0 или 1. Задача, перед тем как использовать ресурс, захватывает семафор, после чего остальные задачи, желающие использовать тот же ресурс, должны ждать, пока семафор (ресурс) освободится. Существуют также так называемые счетные семафоры, где семафор представляет собой счетчик. Пусть к системе подключено три принтера. Семафор, отвечающий за доступ к функциям печати, инициализируется со значением 3, а затем каждый раз, когда какая-либо задача запрашивает семафор для осуществления печати, его значение уменьшается на 1. После завершения печати задача освобождает семафор, в результате чего значение последнего увеличивается на 1. Если текущее значение семафора равно 0, то ресурс считается недоступным, и задачи, запрашивающие печать, должны ждать, пока не освободится хотя бы один принтер.

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

Смертельный захват (Deadlock).

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



4.8 Синхронизация с внешними событиями

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

1. Стремление обеспечить максимально быструю и детерминированную реакцию системы на внешнее событие.

2. Старание добиться минимально возможных периодов времени, когда в системе запрещены прерывания.

3. Подпрограммы обработки прерываний выполняют минимальный объем функций за максимально короткое время. Задержки с обработкой прерываний могут привести к потере данных.

Синхронизация по времени

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

Для точной синхронизации таймера вычислительной системы с астрономическим временем могут применяться специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, которые позволяют воспользоваться атомными часами на борту орбитальных космических аппаратов, запущенных по программе Navstar.



4.9 Тестирование

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

В связи с этим всегда необходимо помнить, что

1)если наряду с разработанными вами программами используется программное обеспечение третьих фирм, вы не застрахованы от того, что там не встретятся участки кода, где прерывания запрещены;

2)практически любая ОС РВ имеет в своих недрах участки такого кода. Нам остается только надеяться, что разработчики ОС старались делать их как можно меньше;

3)всё ядро ОС РВ или его участки могут быть "невытесняемыми";

4)интеллектуальные контроллеры ввода/вывода типа SCSI могут инициировать в системе различные служебные операции, которые способны отразиться на ее характеристиках;

5)многое зависит от применяемой системы кэширования.

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

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

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

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



5. Программное обеспечение реального времени от фирмы On Time Informatik GmbH RTKernel 4.5

Многозадачное ядро реального времени, профессиональное инструментальное средство разработки 16-разрядных приложений реального времени и реализации многозадачности в среде MS-DOS

Общие сведения

RTKcrnel представляет собой мощную многозадачную систему реального времени, предназначенную для разработки программного обеспечения, исполняющегося на IBM PC совместимых контроллерах с открытой архитектурой в среде MS-DOS.

RTKerncI является библиотекой или модулем, который может быть скомпонован с прикладной программой. В состав RTKernel входят многочисленные функции и процедуры управления задачами, семафорами и прерываниями, а также средства обмена данными между задачами. Запуск на исполнение задач RTKcrnel производится из единственной программы, которая содержит ядро, необходимые драйверы и все задачи. Данная программа может выполняться из любой вычислительной системе, содержащей операционную систему MS-DOS. Хотя программа, в которой используется RTKemel, и обладает свойствами, характерными для мультизадачных систем реального времени, она по-прежнему остается приложением DOS.

Основные характеристики

Количество задач, выполняемых под управлением RTKernel, ограничивается общим объемом оперативной памяти. Для каждой задачи RTKernel дополнительно требуется около 1 кбайт памяти.

Время переключения задачи не зависит от количества задач и составляет около 6 мкс (80486/33 МГц).

Количество приоритетов задач - 64.

Виды планирования: коллективное (Cooperative), с вытеснением (Preemptive), с выделением квантов времени (Time-Slicing).

Переключение задач по событию или прерыванию.

Возможность |активизации задачи при возникновении аппаратного прерывания.

Возможность изменения периода поступления прерываний от таймера в диапазоне 0,1 ...55,0 мс.

Возможность измерения временных интервалов с разрешением 1 мкс.

Поддержка арифметического сопроцессора и его программной эмуляции.

Семафоры: двоичные, счетные, ресурсов.

Обмен данными между задачами с использованием очередей сообщений.

Непосредственный обмен данными между задачами с использованием механизма передачи сообщений.

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

Поддержка аппаратного буфера универсальных асинхронных приемопередатчиков (УАПП) семейства 16С550.

Драйверы для работы с таймером, видеоподсистемой, клавиатурой, принтером и локальными вычислительными сетями (ЛВС) Novell с протоколом IPX.

Использование простоев клавиатуры и дисковых накопителей для предоставления процессора другим задачам.

Отсутствие проблем повторной входимости, свойственных MS-DOS.

Возможность создания приложений RTKernel в виде резидентных программ.

Возможность запуска других DOS-программ, в том числе Windows 3.0/3.1, из приложения RTKernel.

Удобство отладки приложений путем использования встроенной возможности компиляции с добавлением отладочной информации, необходимой для Turbo Debugger или CodeView.

Возможность создания приложений, загружаемых из ПЗУ.

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

Отсутствие ограничений на количество разрабатываемых приложений.

Структура и принцип функционирования. Задачи RTKernel

Задачи RTKernel являются обычными Pascal-процедурами или Си-функциями без параметров, методы создания которых ничем не отличаются от традиционных. При старте программы на исполнение запускается только одна функция main. Несмотря на то, что в состав программы входит мультизадачная система реального времени, ее выполнение происходит последовательно, как в традиционных приложениях DOS.

Каждой задаче присваивается приоритет, значение которого может быть установлено в диапазоне от 1 до 64, а также выделяется собственная область стека. Самый высокий приоритет соответствует значению 64. Самый низкий -1. Все локальные переменные (за исключением статических), объявленные в пределах преобразованных в задачи функций (процедур), помещаются в собственные области стека каждой задачи. Это же относится и к функциям, вызываемым из задач RTKernel. Поскольку для каждой задачи формируется собственный стек, имеется возможность одновременного выполнения разными задачами одних и тех же участков кода. Структура приложения RTKernel показана на рис. 5.5.

Рисунок 5.5. Структура приложения RTKernel

Взаимодействие задач

Термин "взаимодействие задач" относится ко всем способам обмена информацией между задачами и методам синхронизации. RTKernel представляет три различных механизма взаимодействия.

Семафоры

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

Очереди сообщений

Очередь сообщений представляет собой буфер данных, в который может быть помещено фиксированное количество записей (сообщений). Очереди сообщений позволяют осуществлять обмен данными между задачами. Количество записей, помещаемых в очередь сообщений, устанавливается при ее создании.

Передача сообщений

Механизм передачи сообщений обеспечивает возможность обмена данными между двумя задачами без использования сигналов или очередей сообщений. Копирование данных производится непосредственно из одной задачи в другую.

Планировщик

Планировщик RTKernel предназначен для управления состояниями задач. Основной функцией планировщика является выявление задачи, которая должна исполняться в текущий момент времени.

Любая задача RTKernel всегда пребывает в одном из следующих состояний (рис. 5.6).

Рисунок 5.6. Состояния задачи RTKernel

Current (состояние исполнения)

Активная в настоящий момент времени задача характеризуется состоянием Current. По крайней мере, одна задача под управлением RTKernel должна пребывать в указанном состоянии.

Ready (состояние готовности)

Все задачи, готовые к исполнению, находятся в состоянии Ready. В текущий момент времени одна из данных задач переходит в состояние Current (состояние исполнения). Задачи в состоянии Ready имеют одинаковый или более низкий приоритет по сравнению с текущей активной задачей.

Suspended (состояние приостановки)

Задачи, исполнение которых явно приостановлено обращением к ядру посредством вызова RTKSuspend. Данные задачи могут быть переведены в состояние Ready только с помощью вызова функции RTKResume.

Blocked (состояние блокировки)

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

Delaying (состояние задержки)

Задачи в данном состоянии блокируют себя на определенный интервал времени. По истечении заданного интервала обработчиком прерывания RTKernel по системному таймеру производится перевод указанных задач в состояние Ready.

Timed

(состояние ожидания события с синхронизацией).

Состояние ожидания задачей события в течение заданного интервала времени. Перевод задачи в состояние Ready производится по истечении установленного интервала либо при наступлении ожидаемого события.

При инициализации RTKernel создаются две задачи: основная (Main Task) и "пустая" (Idle Task). Пустая задача, имеющая нулевой (самый низкий) приоритет, необходима для функционирования планировщика, поскольку условием его работы является наличие хотя бы одной задачи, находящейся в состоянии Ready.

Планирование в RTKernel происходит согласно следующим правилам.

1.Из всех задач, находящихся в состоянии Ready, в активное состояние переводится задача с наивысшим приоритетом.

2. Если в состоянии Ready пребывают несколько задач, имеющих одинаковый приоритет, в активное состояние переводится задача, не исполнявшаяся в течение наиболее длительного интервала времени.

3. Если несколько задач находятся в состоянии ожидания события, порядок их активизации при наступлении события осуществляется в соответствии с порядком убывания их приоритетов.

4. За исключением планирования исполнения задач с выделением каждой заданного кванта времени (Time-Slicing Task Switches), переключение задачи производится только в том случае, когда возникают предпосылки нарушения правила 1, что позволяет минимизировать количество переключении задач.

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

Прерывания

Процедуры обслуживания прерываний могут приостанавливать и активизировать исполнение задач. Данный факт позволяет квалифицировать RTKernel как систему "реального времени". Создание обработчиков прерываний производится обычным образом, принятым в средах программирования Си и Pascal, но с использованием специальных функций RTKernel получения вектора, установки вектора и т. п.

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

RTKernel, DOS и Windows

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

Рисунок 5.7. Взаимодействие Windows и RTKernel

Программа RTKernel может быть загружена в качестве резидентной (TSR -terminate and stay resident), после чего имеется возможность запуска на исполнение Windows 3.0/3.1 или приложения под управлением DOS-расширителя. В дальнейшем Windows и все приложения, запущенные под управлением Windows, рассматриваются RTKernel как одна задача. Другие задачи, входящие в состав RTKernel-приложения, продолжают выполняться в соответствии с требованиями, предъявляемыми к системам реального времени, и с возможностью неограниченного использования функций дискового ввода-вывода, а также взаимодействия с приложениями Windows посредством программных прерываний или специального модуля IPC (Inter-Process Communication - модуль межпроцессного взаимодействия). Таким образом, имеется способ создания сложных приложений реального времени, использующих интерфейс Windows (рис. 5.7). Вся работа в режиме реального времени выполняется под управлением RTKernel, тогда как интерфейс пользователя реализуется средствами Windows.

Драйверы устройств

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

Timer

Позволяет осуществлять измерение любого количества независимых временных интервалов с разрешением около 0,8 мкс. Длительность интервала может составлять до 3,7 лет. Кроме того, данный модуль предоставляет возможность изменения частоты системного таймера, которая обычно равна 18,2 ГЦ

RTKeybrd

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

KillKey

Дает возможность избежать нежелательных последствий, к которым может привести нажатие клавиш <Pause>, <PrintScreen> и т. п. во время исполнения приложения реального времени.

RTTextIO

Содержит средства, обеспечивающие совместное использование видеоподсистемы различными задачами путем предоставления каждой собственного окна ввода/вывода.

Spooler

Обеспечивает возможность вывода файлов на печатающее устройство (параллельный принтер) в фоновом режиме.

CPUMoni

Позволяет критичным по времени исполнения приложениям реального времени контролировать степень загруженности процессора.

RTCom

Содержит полную реализацию взаимодействия с последовательными портами. Прием и передача данных через последовательные порты СОМ1-СОМ4 может осуществляться как в режиме опроса, так и по прерыванию.

RTIPX

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

IPC

Облегчает реализацию взаимодействия между разными DOS-приложениями путем использования мультиплексного прерывания DOS. В основном это относится к резидентным программам, передающим данные основному исполняемому приложению. Кроме того, посредством IPC может быть организован обмен данными между приложением Windows и резидентной программой DOS.

RTKerneI-32

Многозадачное ядро реального времени для З2-разрядных встраиваемых систем

RTKerneI-32 представляет собой мощную мультизадачную систему реального времени, предназначенную для разработки встраиваемых приложений, использующих 32-разрядное линейное адресное пространство памятиRTKernel-32 является библиотекой или модулем, который может быть скомпонован с прикладной программой. В состав RTKemel-32 входят многочисленные функции и процедуры управления задачами, семафорами и прерываниями, а также средства обмена между задачами. Запуск на исполнение задач RTKernel-32 производится из единственной программы, которая содержит ядро, необходимые драйверы и все задачи. Исполняемый модуль приложения для запуска в составе встраиваемой системы, оснащенной процессором любого типа, поддерживающим Intel совместимый 32-разрядный защищенный режим, может быть подготовлен с помощью кросс-системы, подобной RTTarget-32, поставляемой фирмой On Time.

Количество задач, выполняемых под управлением RTKernel-32, ограничивается общим объемом оперативной памяти. Для каждой задачи RTKemel дополнительно требуется около 1 кбайт памяти.

Время переключения задачи не зависит от количества задач и составляет около 5 мкс (80486 33 МГц).

Количество приоритетов задач 16.

Виды планирования: коллективное (Cooperative), с вытеснением (Preemptive), с выделением квантов времени (Time-Slicing).

Переключение задач по событию или прерыванию.

Возможность активизации задачи при возникновении аппаратного прерывания.

Возможность измерения временных интервалов с высоким разрешением.

Поддержка арифметического сопроцессора и его программной эмуляции.

Пять типов семафорных примитивов.

Обмен данными между задачами с использованием очередей сообщений.

Непосредственный обмен данными между задачами с использованием механизма передачи сообщений.

Управление памятью в режиме реального времени (пулы памяти).

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

Совместимость с RTKernel-C для DOS.

Совместимость с Win32 API

Поддержка RTTarget-32 и других кросс-средств.

Возможность запуска в составе целевых систем на базе процессоров, совместимых с i386.

Возможность создания приложений, загружаемых из ПЗУ

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

Отсутствие ограничений на количество разрабатываемых приложений. Структура приложения RTKernel-32 показана на рис. 5.8.

Рисунок 5.8. Структура приложения RTKernel-32

Для обеспечения возможности переноса в среду RTKernel-32 существующих многозадачных приложений, созданных для функционирования под управлением Windows NT или Windows 95, в ее состав включен практически полный набор функций, образующих интерфейс Win32.



6. Программные комплексы для АСУ ТП

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

Типичным примером является компания Intellution - лидер в выпуске ПО АСУТП диспетчерского уровня (по английской терминологии - SCADA - или MMI - программ) на платформах Windows'95 и Windows NT фирмы Microsoft. Список программных продуктов Intellution и их краткое назначение приведены в таблице.

Paradym-31

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

В 1996 г. фирма Intellution приобрела компанию Wizdom Controls (США), которая являлась разработчиком одного из ведущих на американском рынке продуктов SoftLogic - пакета Paradym-31. Интегрировав этот пакет со своими продуктами, Intellution предложила потребителям Paradym-31 в одном ряду с FIX.

Пакет Paradym-31 позволяет программировать на трех графических языках стандарта МЭК 1131-3: SFC, LDD и FBD. После преобразования программы получается код на языке С++. Полученный С-код компилируется в ЕХЕ-файл. В целевой компьютер (контроллер) загружаются ЕХЕ-файл, драйверы связи с объектом и ядро РВ для ОС. Сейчас поставляются диспетчеры для МС-DOS и Windows NT. Кроме того, для ОС Windows NT разработано дополнение, превращающее ее в систему с жестким РВ с периодичностью такта 1005 мкс.

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

Paradym-31 выпускается в трех конфигурациях: basic, standart и professional. Конфигурация basic поддерживает мониторинг выполнения программы на контроллере; в конфигурации standart можно дополнительно использовать ПК как рабочее место с функциями узла View пакета FIX; наконец, конфигурация professional превращает узел Paradym-31 в SCADA-сервер FIX. Все узлы имеют модификации Development (этап разработки) и Runtime (этап выполнения). Как обычно, в модификации Runtime в отличие от Development нельзя оперативно изменять проект (программу, базу данных и графические экранные формы).

Для связи с FIX используется специальный драйвер FastLink. Через DDE-протокол Paradym-31 может обмениваться и с другими приложениями, например, с Exel или Word.

Конфигурация системы с Paradym-31 Professional и узлом FIX представлена на рис.5.9.

Пакет VisualBatch и batch-процессы

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

Рисунок.5.9. Примеры сети с использованием Paradym-31

Возможна различная классификация технологических процессов. В США принято разделение на дискретные, непрерывные и batch-процессы. К дискретным относятся, например, сборочные производства и электроника. В таких процессах основное внимание обращается на переходы между отдельными состояниями обрабатываемого продукта.

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

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

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

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

Чтобы облегчить автоматизацию batch-процессов, американское общество The Instrument Society of America (ISA) в 1990 г. начало работу по составлению стандарта, который бы регламентировал терминологию, набор понятий и моделей для этого типа процессов. В создании стандарта принимали участие как разработчики систем автоматизации ( в том числе и Intellution), так и ведущие американские компании, применяющие эти процессы - от Dow Chemical до Unilever.

В апреле 1996 г. названный стандарт был официально принят под № S88.01. Предполагается, что он должен использоваться разработчиками систем автоматизации и облегчить им общение с заказчиками, а также гарантировать правильную постановку задачи разработки АСУ.

Согласно стандарту № S88.01 batch-производство представляется тремя типами моделей: физической, процедурной и технологической моделями процесса. Физическая модель состоит из описания производственного участка (process cell), установок (unit), технологических модулей установок (equipment module) и элементов автоматизации управления установками (control module), т.е. датчиков и контроллеров.

Процедурная модель (procedure, или recipe) делится на процедуру или регламент процесса в целом (procedure), процедуру отдельной установки ( unit procedure), операцию (operation) и фазу (phase). Фазы - это наименьшие единицы процесса, "кирпичики", из которых строятся процедуры.

Технологическая модель процесса (process model) представляет собой объединение процедурной и физической моделей в производственном цикле (рис.5.10).

Процесс (process) - это реализация определенной технологической процедуры на производственном участке. При этом выполнение процедуры на установке образует стадию процесса (process stage); операция процесса (process operation) - это выполнение на установке отдельной операции, а под действием процесса (process action) понимается осуществление определенной последовательности технологических операций (фаз) на установке при помощи конкретного управляющего оборудования.

В соответствии с типами моделей стандарта № S88.01 пакет VisualBatch содержит две главные подсистемы: редакторы оборудования и регламентов. Оба редактора графические. Это означает, что разработчик манипулирует мнемосхемами оборудования и алгоритмами процедур (регламентов) на графическом языке. Установки и их подсистемы изображаются специальными пиктограммами, которые можно взять из заготовленной библиотеки или нарисовать самому. Алгоритмы регламентов процесса в целом, отдельных операций и фаз строятся на графическом языке последовательных функциональных схем (SFC) по стандарту МЭК 1131-3.

Рисунок.5.10. Модели batch-процесса по стандарту № S88.01

Регламенты делятся на главные (master) и управляющие (control). Главные регламенты заранее разрабатываются компетентным инженерным персоналом. Разработчик оперирует отдельными фазами процесса. Он устанавливает последовательность и условия запуска фаз, а также значения уставок. Поскольку таких регламентов на все возможные ситуации бывает достаточно много, то для их хранения могут использоваться реляционные базы данных, например Access и Oracle. В ходе разработки регламент можно проверить путем имитации его исполнения.

Управляющие регламенты выбираются из базы главных регламентов в соответствии с конкретными производственными условиями и исполняются при выпуске продукта на реальных технологических линиях. Оператор может запустить регламент, следить за его выполнением, приостановить, перевести на ручное управление и запустить заново. В VisualBatch ведется журнал выпуска партии продукта; с помощью специальных драйверов информация о выпуске продукта может передаваться на финансово-хозяйственный уровень производства типа SAR R/3, Oracle Application или Baan. Возможно параллельное управление несколькими технологическими процессами сразу.

Источником данных для VisualBatch служат DDE- или OPC-серверы. Протокол DDE- это стандартный протокол Microsoft для обмена данными между офисными приложениями. Информация о протоколе OPC приведена далее. Если VisualBatch работает совместно с пакетом FIX, то можно одним щелчком мыши перейти к отображению параметров установки в стиле рисунков FIX.

Узлы VisualBatch делятся на VB-серверы и VB-клиенты. Серверы поддерживают базу данных PB по выпуску партии продукта. Клиенты являются рабочими местами диспетчерского персонала. Пример архитектуры узлов VisualBatch приведен на рис.5.11.

Здесь на первом узле установлен программный пакет FIX SCADA и VP-сервер, а на втором - пакеты FIX View и VisualBatch-клиент.

Рисунок 5.11. Конфигурация узлов FIX и VisualBatch

Internet пакеты FIX WEB Server и FIX Broadcast Network

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

Здесь может помочь сеть Internet, которая радикально изменила общение людей. Широкие возможности она предоставляет и для подключения к производственным процессам. Для реализации этих возможностей Intellution предлагает два новых Internet-пакета: FIX WEB Server и FIX Broadcast Network.

Пакет FIX WEB Server позволяет наблюдать производственный процесс по Internet как по локальной компьютерной сети. При этом, однако, управлять процессом. Практически, чтобы получить доступ по Internet к производственной информации, достаточно установить в локальной сети рядом с узлом FIX SCADA Server дополнительный узел - FIX WEB Server. Этот узел должен иметь выход как в локальную производственную сеть, так и в Internet или Intranet (рис.5.12). На клиентском компьютере достаточно иметь стандартное ПО для доступа в Internet. Наблюдение за процессом в этом случае аналогично использованию узла FIX PlantTV.

Пакет FIX Broadcast Network автоматизирует функцию рассылки отчетов. Он реализует puch-технологию для получения периодических отчетов по Internet. Узлам-клиентам нужно иметь стандартное ПО для Internet и программу PointCast. Информационный отдел предприятия помещает отчеты о производстве на FIX Broadcast Network сервер, который может собирать данные из FIX, реляционных баз данных (Access, Oracle) или финансово-хозяйственных пакетов (SAP R/3). Архитектура системы с узлом FIX Broadcast Network аналогична архитектуре, представленной на рис.5.12.



Рисунок 5.12. Узел FIX WEB Server в сети

Интерфейсы OLE и OPC для SCADA-программ

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

За ее решение в 1995 г. взялись пять ведущих американских компаний в области АСУТП: Intellution, Opto-22, Fisher-Rosemount, Rockwell Software и Intuitive Technology. При содействии специалистов из Microsoft они образовали комитет по подготовке универсального протокола обмена данными РВ. Деятельность комитета широко освещалась на семинарах и выставках, к его работе привлекались и другие компании. Всего в обсуждении этого протокола приняли участие около 90 компаний по всему миру. Первая версия спецификации была выпущена в 1996 г. В ней предложен программный интерфейс для обмена данными в РВ. Этот протокол основан на стандартах OLE/COM и регламентирует интерфейсы программных объектов. Разработчики постарались сделать его максимально гибким в определении формата передаваемой информации, адресации в контроле, организации данных (индексной, теговой, последовательной или иерархической), произвольной группировки информации. Допускаются различные дисциплины сканирования (опрос или по изменениям). Для передачи по сети данные могут произвольно группироваться. В соответствии с объектным подходом OLE/COM возможно расширение интерфейса.

Этот новый интерфейс назван OPC (OLE for process control). После выпуска спецификации был создан фонд разработки и внедрения OPC. Протокол OPC можно использовать не только для связи между устройствами ввода/вывода, но и как основу при обмене между приложениями РВ. Фирма Intellution применила данный протокол в целях связи между своими узлами SCADA и VisualBatch.

Для реализации названного интерфейса в серверах ввода/вывода Intellution предлагает специальный пакет OPC Toolkit. Код, полученный с помощью этого пакета, может поддерживать интерфейсы TAPI, DCOM и OLE-автоматизацию. Он снабжен средствами документирования разработки, имеет встроенную справочную систему и обучающий курс. Если требуется, интерфейс OPC может быть добавлен к результирующему коду автоматически. Пакет OPC Toolkit содержит обычный для Windows-приложенный графический интерфейс, который облегчает конфигурирование, диагностику и отладку. Генерируемый код поддерживает многопоточность, очередь сообщений и обработку по изменениям. Построенный с помощью этого пакета сервер ввода/вывода открыт для приложений на Visual Basic. Он поддерживает разделение портов (коммуникационных каналов) между серверами, диагностику и конфигурирование по сети.

Дополнительную информацию об OPC-протоколе и образцы кода можно получить на WEB-сервере Intellution и комитета OPC Foundation (www. opcfoundation.org).

FIX Dynamics - компонентное построение SCADA-программ

К рассмотренным здесь наиболее актуальным направлениям развития ПО автоматизации относится и компонентное программирование, суть которого в следующем: программа строится из модулей с универсальным открытым интерфейсом. Этот подход аналогичен методике "plug-and-play" подключения аппаратуры. Такая система позволяет достаточно просто вставлять независимо разработанные программные модули.

В качестве компонентного решения SCADA-программ Intellution предлагает пакет FIX Dynamics, в котором реализован принципиально новый подход. В существующих пакетах все подсистемы: база данных (БД), подсистема рисования и просмотра, история, тревоги и др. - неразрывно связаны. Нельзя взять одну из этих подсистем у одного разработчика, а другую - у другого. В то же время если программы поддерживают стандартный интерфейс, то их можно достаточно просто объединять. Система становится открытой и наращиваемой. Многократно увеличивается рынок программных продуктов, которыми потребитель может воспользоваться.

Кроме того, меняется и методика разработки проектов. Сегодня разработка проводится по принципу "снизу вверх". Например, сначала нужно построить основу - БД РВ. Следующий этап - создание рисунков для анимации информации из БД. Затем требуется детальная привязка рисунков к тегам БД.

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

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

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

Рис.Рис.5 Компонентное построение SCADA-пакета

Такая компонентная архитектура принята в новом продукте FIX Dynamics. Ядром системы служит программа I-Core, к которой по интерфейсу COM или OPC подключаются другие модули (рис.5). Программа I-Core состоит из шести разных компонент: интегрированной оболочки Intellution Workspace, поддержки сети, службы тревог, защиты доступа, системы конфигурирования и поддержки VBA и OPC.

Intellution Workspace является интегрированной средой разработчика. Ее интерфейс содержит две панели. В левой в виде дерева представлен проект, в правой ведется графическая разработка проекта. Дерево проекта наращивается по мере добавления новых компонент. Поддерживается возможность редактирования методом "drag-and-drop".

Узлы FIX Dynamics могут быть объединены по сети с существующими узлами FIX 6,15, что позволяет безболезненно масштабировать систему автоматизации. Предусмотрена специальная защита от сбоев вставляемых элементов ActiveX Control. В качестве языка скриптов в новом пакете можно использовать Visaul Basic for Application, что многократно расширяет возможности построения пользовательского интерфейса.



7. Проектирование АСУ ТП на базе SCADA-системы

Что должна уметь система SCADA

Не вызывает сомнений, что АСУ ТП в большинстве случаев являются системами организационно-техническими, что означает наличие функций, выполняемых человеком (оператором).

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

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

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

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

Для начала остановимся на основных функциях, которые возлагаются на любую SCADA-систему, независимо оттого, является она широко тиражируемым продуктом известной компании или создана специалистами отдела АСУТП предприятия для своих конкретных нужд.

Не боясь быть банальными, еще раз переведем на русский язык понятие "SCADA-система" (Supervisory Control And Data Acquisition System) - система сбора данных и оперативного диспетчерского управления. Хотелось бы подчеркнуть, что в названии присутствуют две основные функции, возлагаемые на SCADA-систему:

сбор данных о контролируемом технологическом процессе,

управление технологическим процессом, реализуемое ответственными лицами на основе собранных данных и правил (критериев), выполнение которых обеспечивает наибольшую эффективность и безопасность технологического процесса.

...