4.5. Выделенный сервер файлов

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

4.6. Резервирование сети

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

Рис. 24. Резервирование сети

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

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

Рис. 25. Резервирование контроллеров

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

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

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

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

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

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

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

5. Резервирование сервера технологических данных

5.1. Основные понятия

Сервер АСУТП является ключевым звеном для инте­грации АСУТП и систем управления ресурсами предприятия. Задача интеграции АСУП и АСУТП становится все более акту­альной. Основой объединения информационных потоков служат базы данных (БД). Исторически сложилось, что каналы обмена информацией между подсистемами оказались достаточно сла­быми, но возникла необходимость владения технологической информацией, в том числе и оперативной, на уровне управления производством. Важными компонентами, используемыми в обе­их системах, являются СУБД. Именно благодаря им пользова­тель может получить нужную информацию в нужном месте (не­зависимо от уровня) и в нужное время.

С помощью СУБД на предприятиях избавились от про­блем, связанных с огромными объемами дублированной и ино­гда противоречивой информации, предоставляемой к тому же различными и зачастую несовместимыми друг с другом спосо­бами. Однако использование традиционных реляционных БД, ориентированных на АСУП, не всегда возможно в АСУТП. Этому препятствует несколько основных ограничений:

• производственные процессы генерируют данные очень бы­стро. Чтобы хранить производственный архив системы, на­пример, с 7500 рабочими переменными, в БД каждую секун­ду необходимо вставлять 7500 строк. Обычные БД не могут выдержать подобную нагрузку;

• объемы производственной информации настолько велики, что они просто не вмещаются в традиционную БД. Например, многомесячный архив завода с 7500 рабочими переменными требует под БД около 1 Тбайта дисковой памяти. Сегодняшние технологии такими объемами манипулировать не могут;

• SQL как язык не подходит для обработки временных или пе­риодических данных, типичных для производственных сис­тем. В частности, чрезвычайно трудно указать в запросе пе­риодичность выборки возвращаемых данных.

Результатом преодоления этих ограничений стало появление класса продуктов, называемых базами данных реального време­ни (БДРВ). Отмечаются две концепции создания БДРВ:

• новая независимая разработка БД;

• разработка БДРВ на основе известных реляцион­ных БД, например, MS SQL Server.

Более перспективным представляется второй способ, по­скольку, во-первых, он дешевле, а во-вторых, технологичнее (идет по стопам Microsoft, используя его новые технологии). В качестве примера реализации БДРВ отметим, например, IndustrialSQL Server фирмы Wonderware. Именно этот продукт явля­ется основным компонентом сервера АСУТП.

Для примера можно выделить следующую достаточно сложную и многоуровневую систему АСУТП, используемую многими предприятиями, представленную на рис.28.

Рис.28. Схема АСУТП

На нижнем уровне данные собираются по разнообразным протоколам на коммуникационных серверах, в основу которых положена SCADA-система InTouch компании Wonderware. За­тем данные передавались на следующий уровень для архивации промышленной БДРВ IndustrialSQL Server той же компании Wonderware. После этого архивная и оперативная информация становится доступной различным клиентским приложениям. Для доступа к данным используется язык SQL. При этом воз­можно применение как готовых пакетов клиентских приложе­ний, поставляемых компанией Wonderware, так и пакетов, раз­работанных сторонними фирмами.

Таким образом, не было необходимости организовывать сбор технологических данных с нижнего уровня и можно было сосредоточить все усилия на создании надежной и отказоустой­чивой системы сбора и хранения собранной информации. Эта система реализована на платформе однопроцессорного сервера HP NetServer LH3, в котором использовался встроенный диско­вый RAID-массив (RAID - Redundant Arrays of Inexpensive Disks) 5-го уровня. Сервер управлялся операционной средой Windows NT 4.0.

Несмотря на все достоинства сервера HP NetServer LH3, он не обеспечивал требуемой надежности работы, коэффициен­та готовности и производительности системы. Дело в том, что в этом сервере резервирование осуществлялось только на уровне дисков встроенного RAID-массива. Однако по мере создания и наращивания системы цена потери информации возрастала. Эта цена складывается из ряда факторов: стоимости потерянной ин­формации, потери прибыли, неудовлетворенности клиентов, стоимости технической поддержки и восстановления и т. д. От­крытость и удобство доступа к архивным данным IndustrialSQL-сервера позволили подключиться самым разным отделам и службам, соответственно возросла потребность в постоянном доступе к ресурсам сервера. В результате всего перечисленного возникает необходимость строить систему сбора и хранения данных с резервированием на трех уровнях: аппаратном, сис­темного и прикладного ПО, в основу которой положена кла­стерная технология с применением в качестве аппаратной плат­формы серверов фирмы Hewlett-Packard HP NetServer LP2000r. Каждый сервер имеет в своем составе 2 процессора РШ с такто­вой частотой 1 ГГц.