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

И может ли одна компания системный интегратор провести подобное сравнение без профессионалов?!

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

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

Этот сервис (техническая поддержка) должен совершенствоваться, что очевидно из набора описанных в [1] тестов. Многие из них имели бы смысл в совокупности с другой сопроводительной информацией или в серии тестов. В данном случае напрашивается вывод: поддержка компаний поставщиков сравниваемых SCADA-пакетов, если ею пользовались разработчики тестов, явно неудовлетворительна.

Во-вторых, SCADA-системы можно анализировать в разных срезах и один из них: кто выбирает SCADA-продукт конечный пользователь, то есть технолог, или системный интегратор, поднаторевший в области создания проектов. Системный интегратор, особенно выбравший конкретный SCADA-продукт, должен иметь представление о его внутренней организации и не воспринимать его только как чёрный ящик с инструкцией по эксплуатации. Но будем надеяться, что теперь-то (после выбора продукта) задача системного интегратора, проводившего описываемое в СТА тестирование, упростилась все-таки хорошо разобраться в одной системе проще, чем в нескольких.

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

Безусловно, важно представление о модулях-компонентах SCADA-систем (подсистемы алармирования, архивирования и т.д.), о которых имеется достаточно подробная информация даже в журнальных статьях. Но не менее важны и протоколы, используемые для организации взаимодействия между компонентами, расположенными как на одном узле, так и на разных. Какие протоколы, для какой SCADA-системы предпочтительны и почему. На мой взгляд, при тестировании они должны быть указаны, поскольку от них зависит как производительность текущего SCADA-приложения, так и параллельно загруженных программ. Так, в SCADA-системе Citect (компания CiTechnologies) использование NetBEUI или TCP/IP может приводить к различным результатам по производительности. В SCADA-системе InTouch применение протокола SuiteLink, построенном на TCP/IP, предпочтительнее DDE (NetDDE). Если подобный анализ непозволительно трудоемок при формировании тестов, тем не менее, он необходим при тестировании конкретных модулей или возможностей системы, например, таких как:

· встроенный алгоритм приоритетов при активизации этих модулей;

· подстройка (tuning) каждой подсистемы, в том числе визуализации.