Резервирование в SCADA-системах

 

Рис. 30. Локальная система АСУ ТП

 

Локальная система АСУТП, показанная на рисунке 35, и распределенная система на рисунке 31 имеют одну общую особенность. Обе системы полностью выйдут из строя, если всего в ОДНОМ компоненте системы (компьютере, соединенном с контроллерами или сетью контроллеров) возникнет неисправность.

Рис. 31. Распределенная система АСУ ТП

Большинство современных компьютеров обеспечивают хорошие показатели надежности, но, тем не менее, они также выходят из строя, особенно при эксплуатации в жестких производственных условиях. Если какие-либо компоненты производственного процесса являются критически важными, или стоимость остановки производства очень высока, возникает НЕОБХОДИМОСТЬ построения резервируемых систем. В системах, обеспечивающих резервирование, выход из строя одного компонента не влечет за собой остановку всей системы. SCADA-системы ряда производителей поддерживают реализацию резервирования большинства компонентов, как вследствие особенности архитектуры, так и благодаря наличию встроенных механизмов.

Рассмотрим, какие возможности резервирования имеются при использовании технологии клиент-сервер.

Распределение процессов управления и контроля по нескольким компьютерам, объединенным в локальную сеть, позволяет увеличить эффективность и скорость работы всей системы. В такой системе компьютер, соединенный с промышленным оборудованием, становится сервером, предназначенным для взаимодействия с контроллерами, в то время как компьютеры в локальной сети - клиентами (рис. 32).

Рис. 32. Система с архитектурой клиент-сервер без резервирования

Когда компьютеру-клиенту требуются данные, он запрашивает их у сервера и затем обрабатывает локально.

Для обеспечения резервирования в систему может быть добавлен второй (резервный) сервер, также предназначенный для взаимодействия с промышленным оборудованием (рис. 33).

Рис. 33. Система с архитектурой клиент-сервер с резервным

сервером

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

Кроме резервирования серверов, возможно также резервирование на уровне задач. Кроме поддержки постоянной связи с промышленными устройствами необходимо также обеспечить сохранность и непрерывность данных, тревог и графиков в случае возникновения неисправности. Это может быть обеспечено путем разделения функций сервера на четыре основные задачи:

- ввод-вывод;

- тревоги;

- графики;

- отчеты.

Каждая из этих задач поддерживает свою базу данных независимо от других задач, так что можно дублировать каждую задачу в отдельности. Например, можно обеспечить параллельное исполнение задач отображения графиков на разных серверах в отличие от архитектуры основной/резервный, используемой для серверов ввода-вывода (см. рис. 34).

Рис. 34. Резервирование задач отображения графиков и вывода отчётов.

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

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

Рассмотрим, какие возможности предоставляет резервирование локальной сети. Структура, представленная на рисунке 33, увеличивает надежность системы путем устранения «слабых» мест - в данном случае сервера ввода-вывода. Однако если сеть выходит из строя, управление на клиентских компьютерах также нарушается. Дополнительная сеть и файловый сервер обеспечивают стабильность работы системы даже в случае выхода одной из сетей из строя (рис. 35).

Рис. 35. Резервирование локальной сети.

 

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

Рис. 36. Резервирование связи с контроллером.

 

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

 

Рис. 37. Резервирование обмена данными с помощью локальной сети.

 

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

Если устройство ввода-вывода поддерживает соединение точка-точка, можно обеспечить полное резервирование связи с контроллером путем дублирования устройств (см. рис. 38).

Рис. 38. Полное резервирование связи с контроллерами.

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

Вопрос о резервировании самих контроллеров остается открытым. В большинстве случаев контроллеры не резервируются. Это связано со следующими факторами.

1. Большое количество контроллеров (сотни и тысячи). Резервирование их приведет к значительному увеличению стоимости системы.

2. Для повышения надежности контроллеров применяются «внутренние» резервы, т.е. резервирование проводится внутри контроллера путем введения резервных узлов и цепей в структуру контроллера.

3. Отказ одного или нескольких контроллеров не приводит к остановке системы в целом. При отказе контроллера система может быть переведена в аварийный режим, до тех пор, пока не будет произведен ремонт или замена контроллера.

 

 

Выбор SCADA-системы.

Общий поход.

 

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

1) степень соответствия выбранного SCADA-пакета решаемой задаче;

2) понимание тонкостей реализации конкретной прикладной системы поставщиками SCADA-системы;

3) качество осуществляемой поставщиками технической поддержки.

При выборе ПО (инструмента) для задач АСУТП можно выделить два принципиально разных подхода. Первый из них – создание собственного ПО силами группы собственных специалистов. Второй – использование готового ПО. Рассмотрим их последовательно.

Программировать самим или покупать готовую SCADA-систему? Причинами, побуждающими к созданию собственного инструмента, могут являться:

1) намерение сэкономить средства;

2) попытка создать инструмент, удовлетворяющий всем функциональным запросам;

3) стремление избавиться от зависимости от поставщика.

Расходы на создание собственно ПО складываются из следующих компонентов:

1) заработная плата;

2) аренда помещения;

3) затраты на поддержание рабочего цикла (коммунальные услуги, услуги банка, уплата налогов, закупка канцелярии, расходные материалы);

4) средства связи;

5) командировки;

6) закупка оборудования, мебели, оргтехники, ПО, необходимого для работы;

7) расходы, связанные с тестированием производимого продукта.

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

1) потери времени за счет существенно более длительного срока разработки проекта;

2) риск, связанный с обкаткой ПО на собственном предприятии.

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

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

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

Использование готовой SCADA-системы, снимает с пользователя такие вопросы, как развитие ПО, зависимость от разработчика, качество ПО. Современные широко известные SCADA-пакеты имеют тысячи инсталляций и десятки тысяч человеко-лет полевой проверки.

Выбор SCADA-системы.

 

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

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

Характеристики объекта и требования к системе автоматизации:

- характер технологического процесса (непрерывный, периодический, дискретный и т.д.), его информационная мощность, динамика процессов, территориальная распределенность объекта управления;

- функции системы управления (контроль и/или учет, или контроль и управление, или диспетчеризация, или сочетание ряда выше приведенных функций);

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

- число измеряемых и управляемых величин и требуемые функции переработки текущей технологической информации на каждой операторской станции;

- требования к динамике обновления информации на экране операторской станции, к объему и периодичности записей данных в исторический архив, к формам дисплейных кадров, к удобству и полноте представления измеряемой информации оператору;

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

- перспективы повторного использования разработанного проекта или его фрагментов.

Характеристики разрабатываемой системы автоматизации:

- характеристики сетевой структуры системы автоматизации, протоколы и формы обмена информацией системы с другими подразделениями предприятия;

- информационная структура разрабатываемой системы - связи между источниками и потребителями данных (в вариантах: локальная структура - только непосредственные связи между операторскими станциями и контроллерами; распределенная структура: несколько станций используют общие контроллеры и обмениваются информацией между собой; клиент-серверная структура - сервер взаимодействует с контроллерами, а операторские станции, являющиеся клиентами, обмениваются информацией с сервером);

- типы контроллеров и других устройств, передающих и принимающих текущие данные от операторских станций, их число, типы передаваемых сигналов, наличие у них стандартного интерфейса ОРС (ОРС-сервера);

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

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

Для каждого конкретного проекта те или иные характеристики могут играть разную роль при выборе SCADA-программы. Поэтому рекомендуется применить следующую общую процедуру ее выбора:

- составляются полные, конкретные и однозначно понимаемые технические требования на SCADA-программу;

- на основе материала данного сопоставительного обзора, выделяются 3-5 SCADA-программ, лучше других удовлетворяющих составленным техническим требованиям с учетом экономических ограничений заказчика;

- продавцам выделенных SCADA-программ рассылаются приглашения на участие в закрытом конкурсе;

- формируются критерии выбора наиболее подходящей («оптимальной») SCADA-программы;

- при получении от продавцов технико-коммерческих предложений проводится их сопоставление по следующей процедуре:

1. анализ технических характеристик по представленным предложениям на соответствие техническим требованиям; если некоторые из предложений оказываются неполными или не соответствующими требованиям, они отклоняются;

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

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

4. ознакомление с опытом практического применения участвующих в конкурсе SCADA-программ: организация контактов с предприятиями, эксплуатирующими рассматриваемые пакеты; в переговорах с непосредственными пользователями должны быть выявлены достоинства и недостатки пакетов, которые проявляются только при практическом использовании;

5. на основе всей полученной информации и заданных заказчиком критериев экспертами производится ранжирование предлагаемых SCADA-программ по отдельным критериям;

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