Но более актуально рассмотрение ограничений на используемые ActiveX-объекты. При встраивании объектов ActiveX может использоваться, по крайней мере, 47 типов объектов (см. табл. 3)

Говоря о технологиях Active X, предлагается выделить следующие аспекты:

· выбор типов, ActiveX-объектов, используемых в конкретной SCADA-системе;

· ограничения, накладываемые на применения объектов ActiveX;

· простота применения в приложении.

Первый аспект является решающим, и рассмотрение поддерживаемых типов важно при тестировании.

Объект ActiveX играет роль сервера по отношению к контейнеру (например, SCADA-приложению), являющемуся клиентом. Объект ActiveX может быть реализован в двух основных режимах: как сервер, встроенный в процесс (in-process), и как сервер, исполняющийся в отдельном процессе (out-of-process)

Сейчас все более актуальными становятся вопросы, связанные с новыми технологиями, с применением в SCADA-системах OPC и ActiveX. Не остались они в стороне и при тестировании. Организация инструментальных средств (Toolkits) для создания OPC-серверов допускает при обмене данными с OPC-сервером два режима:

· периодический режим, когда с заданной частотой данные запрашиваются OPC-клиентом;

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

Предпочтительным является второй тип обмена, конечно, если он поддерживается в рассматриваемых SCADA-продуктах

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

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

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

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

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