9.3. Опыт использования открытых scada-nPOrPamm

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

SCADA-программы состоят из двух взаимозависимых частей: Run Time и Development. Они опираются на возможности ОС, в которой работает SCADA-программа. Привязка возможностей, заложенных в Run Time, к конкретному объекту (инжиниринг) осуществляется посредством инструментальной части (Develop­ment). Совокупность SCADA-программы и ОС, таким образом, представляет собой симбиоз, который можно назвать базовым ПО. Инжиниринг фактически есть разработка прикладного ПО пунктов управления без использования традиционных языков программирования.

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

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

Рассмотрим эту важную процедуру подробнее:

1. Полный набор требуемых функций в конкретной системе управления обычно не может быть обеспечен только базовым ПО (например, решение расчетных задач и создание алгоритмов определения команд управления с пульта оператора). Раньше для их программирования в состав SCADA-пакета входил так назы­ваемый «технологический язык» (Basic-подобный или Script). В последнее время наметилась тенденция встраивания в SCADA-программу развитых языков программирования: С или VBA, что возвращает разработчика системы к традиционному программированию.

2. Организация многопользовательского пункта управления стала требованием сегодняшнего дня. Разработчики SCADA-npo- грамм предлагают клиент-серверную технологию: информация по­ступает на сервер, к которому по ЛВС подключаются АРМ поль­зователей. Появляется задача конфигурирования на базе SCADA ПО сервера и АРМ, которая требует специальных навыков как программирования, так и администрирования ЛВС. Достаточно отметить, что при создании БД параметров на сервере для некото­рых SCADA-программ необходимо указывать сетевые адреса кли­ентов, имеющих доступ^ к тому или иному параметру; для дру­гих — на компьютере клиента создается копия БД доступных па­раметров с перечислением сетевых адресов источника данных.

Особого внимания требует корректность сетевых и внутрен­них настроек каждого сервера и рабочего места. Передача дан­ных в другие АСУ (например, АСУ производственно-хозяйствен­ной деятельностью) может решаться с применением стандартных технологий — ODBC и SQL, поддерживаемых большинством SCADA-программ. Декларируется, что использование ODBC и SQL гарантирует взаимодействие с любой популярной БД.

Опуская проектирование структуры БД, с которой предполага­ется организовать взаимодействие, рассмотрим вопросы конфигу­рирования процесса обмена данными. Если даже предположить, что аббревиатура ODBC о чем-то говорит непрограммисту, то это требует от него корректной установки на рабочее место драйверов ODBC, конфигурирования ODBC-интерфейса к приемнику/источ­нику данных, решения прочих сопутствующих задач, что просто нереально, а главное, не нужно. При использовании SQL, также требуются услуги программиста: как минимум знание самого язы­ка SQL (средства «могучего», но сложного, со множеством тонко­стей) и хотя бы основных принципов управления БД.

Возможности SCADA-программ в части формирования отчет- но-учетных документов в последнее время ограничиваются прото­колированием, поскольку создание шаблонов плохо поддается унификации и требует мощного инструментария. Для этих целей обычно предлагается использовать ПО третьих фирм, например генератор отчетов Crystal Reports или электронную таблицу Microsoft Excel. Передача данных из SCADA-программы в эти приложения осуществляется, как правило, посредством процедур DDE. Отсюда вытекают такие требования к разработчику, как умение работать с электронными таблицами и БД, программиро­вать УВА или внутренним SCRIPT-языком, а также знание основ­ных принципов организации DDE-обмена. Последнее соображе­ние касается использования любого инструментального програм­много продукта — лучшим пользователем всегда будет являться программист.

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

Следующая иллюзия — двусмысленность непрофессионального восприятия заказчиками термина «открытая система», применяе­мого в отношении предлагаемых SCADA-прогамм. В первую оче­редь речь идет о возможности организации информационного обмена по сети с ПЛК и другими системами управления. Утвер­ждение о том, что современные SCADA-программы стали «от­крытыми» заказчиками воспринимается как гарантия отсутствия каких бы то ни было проблем по стыковке с любыми програм­мно-техническими средствами.

В отношении промышленных протоколов жесткие рамки от­крытости более прозрачны: необходимо использовать те ПЛК, драйвер для которых разработан под конкретную SCADA-np®- грамму. Разработка нового драйвера влечет за собой дополнитель­ные проблемы: организационные, программные и финансовые.

Для ЛВС проблема стыковки часто завуалирована словами «поддержка TCP/IP», на самом деле это не является достаточным основанием того, что данные, полученные от другой системы управления, попадут в вашу БД. Дело в том, что в соответствии с моделью связи OSI (Open System Interconnection) протокол TCP/IP функционально занимает четвертый уровень (уровень транспорта). На этом уровне гарантируется надежное поступле­ние сообщений и обеспечиваются механизмы проверки на ошиб­ку и управление элементами потока данных. Механизм интер­претации данных уровнем транспорта (т. е. любым транспортным протоколом, включая TCP/IP) не предусматривается, а это зна­чит, что без дополнительных средств получатель не способен по­нять, какую именно информацию (файл, сообщение, массив дан­ных и т. д.) передал ему отправитель. Необходим драйвер уровня приложений, который идентичен используемому в.другой АСУ. На сегодня нет такого единого драйвера для АСУТП, т. е. у каж­дой SCADA-программы он свой.

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

Несколько соображений о трудоемкости процесса создания ПО АСУТП. Возникает иллюзия волшебной палочки, позволяю­щей в одно мгновение разработать ПО АСУТП, оплатив лишь SCADA-пакет. Действительно, если раньше специалисты основ­ное время тратили на программирование процедур сбора инфор­мации и передачи управляющих воздействий, а также на разра­ботку своего ЧМИ, а вопросы архивирования информации, рас­четов, формирования отчетно-учетных документов решались в минимальном объеме, то сейчас использование SCADA-пакета позволяет программистам удовлетворить существенно возросшее требование к ПО, значительно повысить качество и функцио­нальный объем решаемых задач на верхних уровнях АСУ. При этом время разработки современного ПО пультов управления обычно составляет не дни, а месяцы. Фактически наблюдается закономерность технического прогресса: соотношение потреб­ность/производительность приближается к константе.

Анализ предложений ряда инжиниринговых фирм, проведен­ный для одного из конкретных автоматизируемых объектов, по­казал отношение стоимости SCADA-пакета к общей стоимости ПО АСУТП, равное 0,1 +0,4 %. При этом это отношение больше для «мощных» SCADA-пакетов, а общая стоимость ПО, естест­венно, уменьшается.