ЖУРНАЛ СТА №4/1999

Мы не ставили своей задачей выбрать абсолютного победителя, тем более что в такой быстро развивающейся области, как SCADA-системы, такое звание может быть весьма кратковременным и эфе- мерным. К тому же в различных проек- тах АСУ ТП могут оказаться наиболее важными совершенно различные ха- рактеристики SCADA-пакета. Думаем, читатель, ознакомившись с результата- ми испытаний и нашими, возможно, субъективными комментариями, сам сможет сделать необходимые выводы. В основном нас интересовали те характе- ристики пакетов, которые влияют на со- здание эффективного человеко-машин- ного интерфейса и на решение других задач, характерных для верхнего уровня АСУ ТП. Так как на нижнем уровне мы по-прежнему собираемся использовать программное обеспечение собствен- ной разработки, то инструментальные средства для программирования на язы- ках МЭК-61131-3 не рассматривались. Требования к SCADA Нас, в первую очередь, интересовали следующие характеристики SCADA-сис- тем: ● качество документации; ● техническая поддержка в России; ● открытость и масштабируемость; ● полнофункциональность; ● надежность; ● эффективность; ● цена. Мы считаем качество сопроводитель- ной документации одной из ключевых характеристик, так как наша фирма ра- ботает не по типовой двухступенчатой схеме «системный интегратор — конеч- ный пользователь», а по трехступенча- Введение Фирма, в которой мы работаем, — АО «Система-Сервис» — имеет достаточно богатый опыт в области создания сис- тем АСУ ТП для объектов магистраль- ных газопроводов, в первую очередь, для газокомпрессорных станций. В про- шлом применяемое нами программное обеспечение как нижнего, так и верхне- го уровня (APM сменного инженера) яв- лялось продуктом собственной разра- ботки. Но время показало, что дублиро- вание своими силами результатов дея- тельности специализированных фирм- разработчиков SCADA-систем — доро- гое удовольствие, отвлекающее к тому же ограниченные ресурсы наших про- граммистов от решения насущных про- ектных задач. Поэтому был поставлен вопрос о выборе стандартной SCADA- системы для решения, по крайней мере, задач верхнего уровня АСУ ТП, включая ПО операторского интерфейса. Работы проводилась в три этапа. На первом этапе по заявленным для раз- личных пакетов технико-коммерчес- ким характеристикам проводился пер- вичный отбор пакетов, подлежащих те- стированию. На втором этапе дистри- бьюторы и разработчики SCADA-сис- тем были приглашены для проведения презентации своих продуктов. Для уточнения характеристик двух систем, оказавшихся по итогам первых этапов наиболее перспективными (iFIX и GENESIS32), была разработана и реализо- вана программа и методика тестирования. Хотя работа проводилась для собст- венных нужд, мы сочли полученные ре- зультаты интересными и для других специалистов в области промышлен- ной автоматизации. ИНСТРУМЕНТАЛЬНЫЕ СИСТЕМЫ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 6 4/99 SCADA-системы: проблема выбора Владимир Бунин, Валентин Анопренко, Алексей Ильин, Ольга Салова, Наталия Чибисова, Алексей Якушев той. То есть мы делаем множество про- ектов в различных регионах России, со- провождение и изменение которых мо- жет выполняться специалистами заказ- чика и региональных сервисных фирм. Низкое качество документации (напри- мер, ее неполнота или англоязычность приведет к фактическому ухудшению качества сопровождения. Техническая поддержка определяет, сколько времени и сил придется затра- тить системному интегратору на освое- ние всех возможностей системы. При ее отсутствии зачастую оказывается, что проще и быстрее написать программу самим, нежели разобраться, как пользо- ваться готовой. Вопрос масштабируемости значим потому, что мы, как и любой другой сис- темный интегратор, имеем проекты разного масштаба (от сотен сигналов до десятков тысяч). Иметь SCADA-пакет, применяемый либо только в малых, ли- бо только в больших системах, непрак- тично. Требование открытости имеет не- сколько основных аспектов. ● Во-первых, это возможность сопря- жения данной SCADA с различными продуктами других фирм-производи- телей (ПО технологических контрол- леров, СУБД, другие SCADA). ● Во-вторых, это наличие мощного и универсального скриптового языка. ● В-третьих, это возможности встраи- вания в SCADA готовых компонентов (в первую очередь — ActiveX). Под полнофункциональностью по- нимается способность пакета решать весь комплекс задач промышленной ав- томатизации, выдвигаемых перед про- граммным обеспечением на верхнем