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

Чем же отличается разработка крупных АСУ ТП в SCADA-системе?

Рис 1. «Эффект размера» - увеличение относительного времени разработки систем с большими информационными базами. Ряд 1 – время разработки проектов, когда время поиска ошибок пропорционально объему информационной базы. Ряд 2 время разработки проектов, когда время поиска ошибок неизменно.

В зависимости от специфики проекта «эффект размера» может проявляться при разном числе подключаемых устройств, но обычно, в той или иной степени он становится заметным уже в проектах с 1000 I/O и является ощутимым препятствием, когда число в системе достигает 5000 I/O. Системы, в которых проявляется «эффект размера» мы будем называть крупными.

Во-вторых, большие АСУ ТП предъявляют повышенные требования к производительности системы реального времени.

В-третьих, крупные АСУ предъявляют повышенные требования к надежности работы всех ее подсистем.

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

И наконец в-пятых, большие системы предъявляют повышенные требования к технической поддержке проектов.

Рассмотрим, какие операции необходимо выполнить инженеру при создании простой АСУ ТП с использованием технологии OPC, включающей два узла - один контроллер и одну операторскую станцию. В таком проекте сначала описываются переменные для связи с УСО в контроллере, программируются логические задачи, затем создается список переменных, передающихся в ПК. Все три операции являются ручными и в них будут обязательно присутствовать ошибки клавиатурного ввода и др. (в среднем при программировании характерна примерно 1 ошибка на 10 операций). Теперь необходимо запрограммировать OPC-сервер в ПК оператора: создать список переменных OPC-сервера, список переменных в SCADA, описать внутренние теги SCADA. Это еще три ручные операции (см. табл. 1). Итого шесть ручных операций, закладывающие базу для проявления «эффект размера» при масштабировании проекта.

Разработка проекта в ТРЕЙС МОУД осуществляется по-другому. В этой SCADA применены следующие три технологии, снижающие «эффект размера»:

1. Единая линия программирования операторских станций и контроллеров;

2. АвтопостроениеO проекта;

3. Единый проект для распределенной АСУ;

Настройку на УСО в ТРЕЙС МОУД делать не требуется. Благодаря технологии автопостроенияO ТРЕЙС МОУД генерирует первичные базы настроек автоматически. Технология автопостроения – это комплекс процедур автоматического создания и поддержания баз данных реального времени, повышающая производительность труда разработчика и снижающая «эффект размера». В ТРЕЙС МОУД 5 существуют шесть технологий автопостроения, но наибольшее значение имеют следующие три:

Рис. 2. В ТРЕЙС МОУД средства разработки операторских станций и программирования ПЛК интегрированы.

Поэтому отдельного списка параметров для передачи в ПК в этом случае создавать не требуется. Таким образом, мы видим, что из трех основных операций программирования контроллера две полностью автоматизированы. И соответственно при программировании контроллера в ТРЕЙС МОУД есть только одна ручная операция написания логических программ, а не три, как в традиционных системах.

При создании базы данных для ПК оператора в ТРЕЙС МОУД 5 мы также получаем значительный выигрыш в производительности по сравнению со SCADA на основе обычного OPC. И список переменных, передающихся из контроллера (из OPC-сервера) и список переменных в SCADA генерируются автоматически процедурой автопостроенияO ТРЕЙС МОУД. Остается только одна ручная процедура, которую должен выполнить инженер, работающий в системе – это описать внутренние переменные в SCADA. И опять – вместо трех ручных процедур, мы имеем только одну. Из таблицы 1 следует, что благодаря использованию технологий единой линии программирования и автопостроения можно сократить время, затрачиваемое на программирование одного параметра с 8,5 мин до 1,5 мин.

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

Приведенные данные свидетельствуют, что автоматизированные технологии ТРЕЙС МОУД позволяют сократить время, затрачиваемое на программирование каждого параметра ввода/вывода в несколько (6) раз. Мы видим, что хотя технологии автопостроения и единой линии программирования ускоряют разработку систем любого масштаба, их эффект наиболее ощутим в системах с более чем 500-1000 I/O. Ну, действительно, если традиционная SCADA очень нравится пользователю, то он может решить, что потратить три дня на программирование системы в 100 I/O допустимо и отказаться от автопостроения, которое бы позволило ему завершить работу к обеду первого дня. Но вряд ли даже он будет считать, сопоставимыми трудозатраты в 1 месяц и в 1 неделю (при 1000 I/O).

Таким образом, уже при 4 ПК в системе технологии автопостроения дают 10 кратный выигрыш в производительности по сравнению со стандартной технологией OPC. А при наличии 10 серверов в сети, только создание информационной базы в SCADA на основе OPC займет более 2,5 человеколет в проекте объемом всего в 5000 I/O.

По сообщению ЗАО ПИК ЗЕБРА в проекте АСУ ТП энергоблоков ГРЭС Нассирия объемом 10.000 входов/выходов, включающем 20 операторских станций суммарные трудозатраты на разработку программного обеспечения в ТРЕЙС МОУД составили 17 чел/мес (без учета пусконаладки). Из них на создание информационной базы было затрачено только около 1 чел/мес. Это значит, что рутинная работа по созданию базы была выполнена ТРЕЙС МОУД автоматически, а разработчики посвятили свое время творческой работе по разработке алгоритмов управления и мнемосхем.

Увеличение производительности системы реального времени

Для обеспечения высокой производительности передачи данных в ТРЕЙС МОУД разработан коммуникационный интерфейс I-NET. Наши сравнения показали, что I-NET способен передавать информацию в 16 раз быстрее чем DDE и в 8 раз быстрее, чем OPC (Рис. 3). Низкопроизводительные интерфейсы DDE и OPC используются в ТРЕЙС МОУД в силу их универсальности для связи с незнакомыми контроллерами, а не как основной механизм передачи данных, как это имеет место быть в некоторых SCADA.

Рис. 3. Сравнение производительности интерфейсов DDE, OPC и I-NET.

Аналогично и графическая подсистема ТРЕЙС МОУД лишь допускает (для целей универсальности) использование ActiveX, а не создается исключительно на их основе. Поэтому ТРЕЙС МОУД за 1 с способна обновлять на экране до 4000 пятидесятицветных индикаторов. Данные о производительности ТРЕЙС МОУД 5, полученные по результатам экстремального тестирования приведены в табл.6. Они удовлетворяют стандартам, принятым в таких требовательных отраслях промышленности как энергетика и атомная промышленность.

Горячее резервирование

Для обеспечения надежности работы диспетчерского комплекса ТРЕЙС МОУД располагает встроенной системой автоматического горячего резервирования контроллеров, серверов реального времени, серверов архива. Создавать системы с горячим резервированием в ТРЕЙС МОУД 5 просто - достаточно указать, что ПК или контроллер должен иметь дубль (рис. 4) и система сама сгенерирует и настроит необходимую базу данных (базу каналов). При изменении конфигурации основных узлов, ТРЕЙС МОУД 5 автоматически обновит узлы-дубли.

Рис. 4. Процедура создания резервированных узлов в ТРЕЙС МОУД автоматизирована.

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

Рис. 5. ТРЕЙС МОУД обладает функциями автоматического горячего резервирования датчиков, плат ввода-вывода (1), сетевых линий (2), операторских серверов (3), архивов.

Дублированные серверы реального времени ТРЕЙС МОУД обладают следующими функциями:

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

Рис. 6. Микро МРВ ТРЕЙС МОУД обладает функциями горячего резервирования датчиков и плат УСО(1), сетевых линий (2), контроллеров (3).

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

Обеспечение групповой работы разработчиков

Для обеспечения групповой разработки проекта ТРЕЙС МОУД обладает мощным объектным механизмом фрагментирования и сборки. Каждый фрагмент проекта является независимым объектом и может свободно редактироваться любым членом группы разработчиков. Все объекты могут сохраняться в файлы и свободно линковаться при их повторном использовании в тиражируемых проектах и структурах.

Объектом ТРЕЙС МОУД может быть практически любая часть прикладного проекта. Например в объект может быть выделен отдельный узел (контроллер или операторская станция) или группа узлов, фрагмент базы каналов узла, логическая программа на языках TechnoFBD или TechnoIL, графическая база (мнемосхемы) узла или группы узлов, отдельный экран, фрагмент экрана или группа экранов графической базы. Любой из этих объектов может быт вставлен в общий проект когда это потребуется и в том состоянии, в каком он находится в данный момент (рис.7). Причем при добавлении отредактированного фрагмента, ТРЕЙС МОУД производит корректное обновление проекта.

Рис. 7. ТРЕЙС МОУД обладает мощным объектным механизмом фрагментирования и сборки проекта.

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

Техническая поддержка крупных проектов

Для облегчения создания крупных проектов АдАстрА предлагает пакеты корпоративной технической поддержки. От бесплатной технической поддержки, предоставляемой каждому пользователю ТРЕЙС МОУД, они отличаются тем, что консультации оказываются по прикладному проекту пользователя, а не по инструментальным средствам разработки. Необходимость использования платных пакетов техподдержки обуславливается тем, что выделение средств на поддержку закладывается в бюджет при первоначальном планировании проекта, в то время как потребность в дополнительной техподдержке часто возникает на этапе внедрения и отладки. Это позволяет избавиться от необходимости вторичного выделения денег на один и тот же проект и добавляет разработчикам уверенности в скорейшем и более качественном результате работы.

Корпоративная техническая поддержка включает выезды специалистов к заказчику, обучение персонала, сопровождение проекта и написание специфических программ (драйверов, ActiveX объектов и т.п.). В зависимости от объема предоставляемых услуг пакеты корпоративной поддержки разделяются на два вида: серебряный и золотой. При исчерпании квоты на определённый вид работ, возможно перераспределение времени в пределах общей стоимости пакета.

Примером плодотворного использования корпоративной технической поддержки может служить работа инженеров технической поддержки АдАстрА в Ираке при восстановлении ГРЭС Нассирия. Как известно, запуск энергоблока ГРЭС был осуществлен 20 июня 2000 г. - через 15 дней, после приезда туда российских специалистов, а сдача в промышленную эксплуатацию состоялась в начале августа 2000 г., т.е. менее чем через два месяца.