Оценка стоимости инструментальных систем

Стоимость SCADA-систем, на первый взгляд, кажется достаточно высокой. При этом механизм определения цены у разных фирм-разработчиков различен: стоимость InTouch, например, зависит от количества переменных, используемых в разрабатываемой прикладной программе, стоимость Simplicity определяете числом каналов ввода/вывода, которые должна поддерживать система, а пакет FactoryLink/Monitor Pro имеет высокую базовую стоимость, но не имеет ограничений по числу каналов и тэгов [14]. При оценке стоимости SCADA-системы учитываются минимальные и рекомендуемые ресурсы компьютера, необходимые для его установки. При этом в некоторых системах, например WinCC число допустимых переменных напрямую зависит от числа доступных ОЗУ. Квалифицированное использование SCADA-пакета позволяет уменьшить требуемое число переменных процесса, ко­торые влияют на стоимость.

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

Составляющая «стоимость сопровождения» (или «стоимость владения») обычно наиболее «скрыта от глаз пользователя» и за­висит от многих факторов, таких, например, как:

· стоимость «риска» покупки, определяемого рыночной надежностью фирмы-поставщика, рыночной стабильностью фирмы-изготовителя продукта;

· стоимость коммуникаций с фирмой-поставщиком;

· «время реакции» поставщика на проблемы покупателя;

· наличие реального прикладного опыта и хорошего знания поставляемого пакета специалистами поставщика;

· степень открытости, адаптируемости и модернизируемости пакета.

Эти и многие другие факторы, влияющие на «стоимость владе­ния», необходимо учитывать при выборе системы. Можно отме­тить, что использование разработчиками SCADA-систем Windows NT способствует снижению «стоимости владения» поль­зователем этими продуктами.

Стоимость, связанная с трудозатратами на разработку приложе­ний при использовании SCADA-систем, существенно уменьшается по сравнению с использованием традиционного программирова­ния. Например, работы по созданию системы информационного обслуживания в CERNe, которая содержала несколько десятков узлов, вместе с отладкой заняли около трех месяцев и выполнялись с помощью системы FactoryLink. Следует учесть, что сказанное выше относилось к стоимости системы разработки; стоимость систем исполнения составляет обычно 30...50% от стоимости систе­мы разработки.

Чтобы оценить время окупаемости SCADA-системы, необхо­димо учесть множество факторов, включая число проектов, реали­зуемых на основе этой системы, стоимость этих проектов и т. д. Ориентировочно, если речь идет о бизнесе системного интеграто­ра, реализация двух-трех проектов при приобретении системы разработки SCADA окупает ее (например, окупаемость проекта на TRACE MODE составляет 0,5-3 месяца).

Открытость систем

Описанные выше характерные черты и особенности SCADA-систем являются достаточно устоявшимися. Но немаловажное значение имеют вновь появляющиеся особенности систем, связан­ные с их «открытостью», с интеграцией их в структуру комплекс­ной автоматизации предприятия в целом. Свойство открытости всегда было одним из важных свойств SCADA, но сейчас оно до­полняется новыми средствами передачи данных между процесса­ми (OLE – Object Linking and Embedding – включение и встраива­ние объектов), стандартом общения с технологическими устройствами (ОРС – OLE for Process Control), встраиваемыми программными объектами (ActiveX).

Система является открытой, если для нее определены и описаны используемые форматы данных и процедурный интерфейс, что по­зволяет подключить к ней «внешние», независимо разработанные компоненты, адаптировать пакет под конкретные нужды с мини­мальными затратами. В принципе любой SCADA-пакет является «открытым». Весь вопрос в том – для кого? Понятно, что разработ­чик инструментального пакета, разработчик ПО на его основе и ко­нечный пользователь могут по-разному трактовать это понятие.

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

Современные SCADA-системы не ограничивают выбора аппа­ратуры нижнего уровня, так как предоставляют большой набор драйверов или серверов ввода-вывода и имеют хорошо развитые средства создания собственных программных модулей или драй­веров новых устройств нижнего уровня. Вопрос, однако, в том, достаточно ли только спецификаций доступа к ядру системы, по­ставляемых фирмой-разработчиком в штатном комплекте (TRACE MODE), или для создания драйверов необходимы специальные пакеты (FactoryLink, InTouch, Genesis), или же разработку драйвера нужно заказывать у фирмы-разработчика.

Для подсоединения драйверов ввода-вывода к SCADA-системе используются следующие механизмы:

· динамический обмен данными (DDE – Dynamic Data Exchange), ставший стандартом “de facto”;

· собственные протоколы фирм-производителей SCADA-систем, реально обеспечивающие самый скоростной обмен данными;

· ОРС – протокол, который, с одной стороны, является стандартным и поддерживается большинством SCADA-систем, а с другой стороны, лишен недостатков протоколов DDE.

Изначально протокол DDE применялся в первых человеко-машинных интерфейсах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК. До по­следнего времени DDE оставался основным механизмом, исполь­зуемым для связи с внешним миром в SCADA-системах. Но он является малопригодным для обмена информацией в реальном масштабе времени из-за своих ограничений по производительности и надежности (5...6 тыс. переменных/сек).

Для преодоления недостатков DDE, прежде всего для повыше­ния надежности и скорости обмена, разработчики предложили свои собственные решения (протоколы), такие как AdvancedDDE или FastDDE – протоколы, связанные с пакетированием информа­ции при обмене с ПЛК и сетевыми контроллерами. Но такие част­ные решения приводят к ряду проблем. Для каждой SCADA-системы пишется свой драйвер для поставляемого на рынок обо­рудования. В общем случае два пакета не могут иметь доступ к одному драйверу в одно и то же время, поскольку каждый из них поддерживает обмен именно со своим драйвером.

Технологии ОРС

Взамен DDE компания Microsoft предложила более эффектив­ное и надежное средство передачи данных между процессами – OLE (Object Linking and Embedding – включение и встраивание объектов). Механизм OLE поддерживается в RSView, Fix, InTouch, Factory Link/Monitor Pro и др. На базе OLE появляется новый стандарт ОРС (OLE for Process Control), ориентированный на ры­нок промышленной автоматизации. Новый стандарт, во-первых, позволяет объединять на уровне объектов различные системы управления и контроля, функционирующие в распределенной ге­терогенной среде; во-вторых, ОРС устраняет необходимость ис­пользования различного нестандартного оборудования и соответ­ствующих коммуникационных программных драйверов.

Основная цель стандарта ОРС заключается в определении ме­ханизма доступа к данным с любого устройства из приложений. ОРС позволяет производителям оборудования поставлять про­граммные компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК.

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

При широком распространении ОРС-стандарта появятся сле­дующие преимущества:

· ОРС позволят определять на уровне объектов различные сис­темы управления и контроля, работающие в распределенной гете­рогенной среде;

· ОРС устранят необходимость использования различного нестандартного оборудования и соответствующих коммуникацион­ных программных драйверов;

· у потребителя появится больший выбор при разработке приложений.

Рисунок 2.1.5 – Клиент-серверная архитектура системы ОРС

С ОРС-решениями интеграция в гетерогенные (неоднород­ные) системы становится достаточно простой. Применительно к SCADA-системам ОРС-серверы, расположенные на всех компь­ютерах системы управления производственным предприятием, стандартным способом могут поставлять данные со скоростью 10...20 тыс. переменных/сек в программу визуализации, базы данных и т. п., уничтожая, в некотором смысле, само понятие неоднородной системы.

На рынке появились инструментальные пакеты для написания ОРС-компонентов, например OPC-Toolkits фирмы FactorySoft Inc., включающий ОРС Server Toolkit, ОРС Client Toolkit, примеры ОРС-программ.

При обмене данными с ОРС-сервером допускается два режима:

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

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

Предпочтительным является второй тип обмена. Формат переда­ваемых данных определяется ОРС-протоколом как V (Value – значе­ние), Q (Quality – качество), Т (Timestamp – метка времени) [17].