Главная Пресс-центр Статьи и публикации SCADA-системы: проблемы тестирования, "Мир Компьютерной Автоматизации", N 1, 2000

SCADA-системы: проблемы тестирования, "Мир Компьютерной Автоматизации", N 1, 2000

Куцевич Н. А., ЗАО «РТСофт», Москва

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

Введение

Наконец-то появилась статья [1], описывающая тестирование SCADA-систем, причём проведенное самими разработчиками приложений АСУ ТП. Как часто при анализе той или иной возможности SCADA-системы не хватает точки зрения пользователя. Попытки оценки SCADA-систем, предпринятые в тематическом выпуске МКА по SCADA-продуктам, представленным на российском рынке (МКА 3/99), оказались не очень успешными, поскольку ряд поставщиков/разработчиков, мягко говоря, необъективно отвечали на вопросы по возможностям SCADA-систем. И одной из идей было продолжить тот же опрос, но только среди пользователей, — именно их мнения не хватало для получения объективной картины. При этом следует отметить, что важна ассоциированная, а не частная точка зрения, т.е. выборка должна быть представительной. Это подтверждает и «самоотверженная» работа, описанная в статье [1].

Ранее информацию о тестировании данного класса систем мы черпали в основном из зарубежной прессы. Знакомились с выбором алгоритмов тестирования, критериями, почему выбраны одни алгоритмы или другие, причём анализ подобных алгоритмов в нашей прессе обычно не предлагался. Их выбор, конечно, зависит от того, кто проводит тестирование — журнал или организация для своей группы проектов. В первом случае ориентация делается на общие принципы построения продуктов, на многообразие поддерживаемых протоколов, на производительность и т.д. (сотни параметров), во втором случае оговариваются особые, ориентированные на определенные проекты условия, следовательно, возможны специализированные алгоритмы тестирования.

Взяться за такой труд при отсутствии достаточного финансирования — либо подвиг, либо недостаточное понимание сущности процесса тестирования. Как результат, большая часть тестов носит поверхностный характер. Можно разбирать тесты построчно, как это часто делается в деловых письмах, чтобы не упустить всех аспектов, но в журнальной заметке испытывать терпение читателей не стоит. Поэтому хочется остановиться лишь на отдельных важных моментах.

Общий поход к тестированию

В большинстве 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) каждой подсистемы, в том числе визуализации.

О встроенных языках

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

Сравнение скорости выполнения скриптового фрагмента повергает в недоумение. В SCADA-системах GENESIS32 и iFix используется один и тот же язык VisualBasic. Компиляторы или интерпретаторы для этих языков создавались, несомненно, профессионалами. Имело бы смысл указать, какой режим используется в указанных продуктах компиляции или интерпретации. Но, пожалуй, больший интерес в отношении скриптов представляет анализ механизмов конкурентного и рекурсивного исполнения скриптов, приоритетов в использовании различных типов скриптов. Разработчик SCADA-приложения часто не анализирует, создавая скрипты по различным событиям в приложении, как они «одновременно» будут исполняться, что, по логике, может приводить к непредсказуемым результатам работы приложения, причем такие результаты на первый взгляд кажутся случайными и поэтому трудно объяснимыми.

Об OPC-компонентах

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

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

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

Не очень убедительными кажутся результаты диагностики связи. Действительно, формат передаваемых данных определяется OPC-протоколом как V (Value -значение), Q (Quality — качество), T (Timestamp — метка времени). Но Quility — это составной параметр, значение которого зависит от многих условий (см. Табл.1, 2).

Если качество данных помечено как неудовлетворительное, то по полям Substatus можно более детально определить причину (табл. 2).

Для этого в SCADA-системах обычно присутствуют встроенные средства проверки взаимодействия с коммуникационным сервером. Причем реализации диагностических средств в SCADA-системах различаются — от самого прозрачного способа, когда в приложении имеется доступ непосредственно к Status и Substatus, например, через поля переменных (как это сделано в InTouch) до связывания всех проблем с подсистемой аппаратных алармов (как это реализовано в Citect). Но способ оценки качества связи, причём как связи между SCADA-приложением и сервером, так и сервера с контроллерным уровнем существовать должен.

Наличие в GENESIS32 встроенного OPC-обозревателя (OPC Browser) не является существенным, учитывая доступность множества свободно распространяемых в Web-мире OPC-обозревателей (OPC Explorer, OPC Browser).

О технологиях ActiveX

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

выбор типов, ActiveX-объектов, используемых в конкретной SCADA-системе;
ограничения, накладываемые на применения объектов ActiveX;
простота применения в приложении.

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

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

Для передачи данных из одного процесса в другой вводится механизм «маршалинг» (Marshaling). Стандарт COM, на котором строится ActiveX, поддерживает маршалинг.

Динамически подключаемые библиотеки ActiveX (ActiveX DLL's) или встраиваемые ActiveX

Поскольку эти объекты размещаются в пространстве процесса контейнерного приложения, то нет необходимости в использовании механизма «маршалинг» для организации передачи данных между приложением-контейнером и объектом ActiveX. Это уменьшает накладные расходы и увеличивает производительность. Существует ряд преимуществ в реализации объекта ActiveX как встраиваемого сервера.

Исполняемые в отдельном процессе ActiveX-объекты (out-of-process) загружаются вне пространства приложения-контейнера. Для передачи данных между ActiveX-объектом и контейнером используется механизм «маршалинг» (marshaling). Его применение заметно увеличивает накладные расходы и сильно влияет на производительность.

Так какой же тип объектов ActiveX использовался в тестах?

Но более актуально — рассмотрение ограничений на используемые ActiveX-объекты. При встраивании объектов ActiveX может использоваться, по крайней мере, 47 типов объектов (см. табл. 3). И далеко не все типы переменных поддерживаются в SCADA-системах. Так что же в этом случае предлагают разработчики рассматриваемых SCADA систем, какие вспомогательные приемы (типа wrappers) предлагают использовать, чтобы стало возможным применение действительно тысяч ActiveX-объектов?

Прерогативой программного кода самого ActiveX в первую очередь должна быть, по-видимому, обработка исключительных ситуаций, поскольку проанализировать необходимые исключительные ситуации может только его разработчик. Контейнерные приложения обычно создают программы обработки лишь самых распространенных исключительных ситуаций. И это тонкое место, препятствующее широкому распространению неподдерживаемых ActiveX-объектов.

На небрежность при подготовке тестирования указывает и такие недочеты, как выбранная конфигурация для тестирования в 64 Mбайт памяти, в то время как в требованиях к iFIX указано 96 Мбайт.

Заключение

1. Часть так детально описанных недостатков iFix превращается в большой плюс, о котором (думается) не ведают авторы, если, конечно, они не преследуют противоположную цель. Если бы аналогичная статья была написана по продуктам Wonderware InTouch, IndustrialSQL Server или Citect (CiTechnology), то она послужила бы неплохим «задачником» при анализе любой из этих SCADA-систем — как на курсах, так и в публикациях — с целью рассеяния проявившихся в ней заблуждений. Применение SCADA-систем, особенно для системных интеграторов — это не просто «click click», это еще и «толстый-толстый» слой технологий.

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

3. Учитывая количество предлагаемых на рынке сравнимых по базовым свойствам SCADA-систем, в условиях повышенных требований к оптимальному использованию конкретного высокотехнологичного продукта повышается роль технической поддержки при ужесточении требований к ее квалификации и компетентности менеджеров продуктов.

Ссылки

1. Владимир Бунин, Валентин Анопренко, Алексей Ильин, Ольга Салова, Наталия Чибисова, Алексей Якушев, «SCADA-системы: проблемы выбора», СТА, 4, 1999

 

19.04.2014