Резервирование в 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. Отказ одного или нескольких контроллеров не приводит к остановке системы в целом. При отказе контроллера система может быть переведена в аварийный режим, до тех пор, пока не будет произведен ремонт или замена контроллера.