Модернизация АСДУ центров обработки данных: проблемы и решения

Введение. Пора начинать модернизацию

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

Обозначив эту цель как показатель эффективности работы диспетчерско-эксплуатационной службы, следует понимать, что для её достижения ни­когда не стоит считать эксплуатируемую вами АСДУ совершенной. Раз­витие методов и систем диспетчеризации продолжается непрерывно, поэтому существующая система диспетчеризации была совершенной, в лучшем случае, только в процессе её проектирования. На этапе интенсивной эксплуатации АСДУ всегда появится це­лый список пожеланий и замечаний по улучшению работы системы, её модификации. Например, служба эксплуатации стала замечать, что простые на их взгляд операции взаимодействия с АСДУ, такие как получение графиков параметров из архива или переход от одной подсистемы к другой, занимают на автоматизированном рабочем месте (АРМ) диспетчера неоправданно длительное время. Или стали раздражать невнятная цветовая схема отображения нештатной ситуации и необходимость последующей длительной навигации в системе, когда, скажем, вместо одного щелчка мыши на тексте аварийного сообщения для перехода к подсистеме, его вызвавшей, АСДУ заставляет вас производить целую серию различных манипуляций, чтобы получить на экране параметры неисправного узла.

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

Короче говоря, первоначальные по­ложительные эмоции от общения с сис­темой диспетчеризации забылись, а ко­личество претензий и пожеланий начинает увеличиваться по нарастающей. И это тем более досадно, когда вы знаете, что все ваши претензии устранимы, пожелания вполне реализуемы, а новые программные продукты сулят куда бо'ль­шие возможности, подобно тому, как, например, SCADA-система ICONICS GENESIS64 делает изображение на экране диспетчера 3D-сценой с полной иллюзией вашего присутствия в любой точке контролируемого объекта и свободного перемещения по нему.

Всё это означает, что ваша АСДУ требует глобальной модернизации. Рас­смотрим некоторые часто встречающиеся на практике аспекты.

Организация пользовательского интерфейса. Разделение по группам пользователей

Безусловно, появление в последнее время программных решений и подходов, связанных с методами интеллектуальной визуализации, направило вектор развития АСДУ именно в эту сторону. Поэтому переход на 64-разрядные SCADA-системы с 3D-визуализацией и поддержкой распределённого принципа организации пользовательского интерфейса “HMI/SCADA on Any Glass, Any Time™” (интерпретация ICONICS, дословно – «HMI/SCADA в любое время, на любом стекле») следует рассматривать как одну из глобальных целей проводимой вами модернизации АСДУ ЦОД. Такой подход обеспечит не только максимальную эффективность работы диспетчерской службы, но и её интеграцию в реальном времени с действиями всего обслуживающего персонала ЦОД – техниками и инженерами по обслуживанию энергетического обеспечения, специалистами климатических установок, службой безопасности и контроля доступа и др. Рассмотрим последовательно возникающие аспекты осуществления такой модернизации.

Одной из задач в построении пользовательского интерфейса является необходимость его разделения для разных групп пользователей. На практике часто бывают случаи, когда изначально вводится в эксплуатацию ядро АСДУ ЦОД, разработанное как система отображения состояния объекта для его диспетчера и главного инженера. В процессе эксплуатации неизбежно появляется потребность обеспечить прямой доступ к АСДУ также другим группам сотрудников, непосредственно эксплуатирующих оборудование. Это могут быть, например, персонал отдела IT, электрики, другие технические специалисты. Понятно, что специалистов, поддерживающих работоспособность системы бесперебойного гарантированного электропитания, интересуют, прежде всего, показатели качества электроснабжения, а также состояния источников тока/напряже­ния и дизель-генераторных установок, поэтому параметры именно этого оборудования должны в первую очередь отображаться на экране для таких специалистов при входе в систему. Сотрудникам других служб понадобятся на первом плане, например, тепловая и влажностная карты ЦОД, информация о состоянии дверей (как межкомнатных, так и в серверных стойках), видеоизображения с телекамер, размещённых в помещениях ЦОД, и др. Одновременно с решением данной задачи часто возникает потребность в увеличении количества АРМ.

В то же время для получения из АСДУ необходимой информации о состоянии подсистем кондиционирования и пожаротушения или о температуре воды в системе отопления нет необходимости ставить дополнительные АРМ для сотрудников, обслуживающих кондиционеры, или АРМ сантехника. Вполне разумно обеспечить этим специалистам быстрое подключение к АСДУ с любого компьютера в сети организации, а в общем случае – и с мобильных уст­ройств, ноутбуков, планшетных компьютеров, если это не противоречит политике безопасности. Такой подход вполне соответствует уже упоминавшемуся принципу “Any Glass, Any Time”, причём с использованием технологии «тонких» клиентов совершенно не обязательно, чтобы клиентское программное обеспечение SCADA-системы было установлено на устройстве доступа. Войдя и зарегистрировавшись в АСДУ с произвольного компьютера, технический специалист получит на экране мнемосхемы с данными по оборудованию, соответствующие именно его зоне ответственности. Система автоматически будет распознавать его как пользователя конкретной группы и активизирует на экране персональное рабочее место в строгом соответствии с политикой безопасности.

Такая методика была применена при модернизации АСДУ ЦОД одного известного банка. Для решения данной задачи в рамках 32-разрядной SCADA-системы ICONICS GENESIS32 идеально подходит программное обеспечение ICONICS WebHMI™. В 64­-­­разрядной системе ICONICS GE­NESIS64 Web-доступ уже включён в саму SCADA-систему, основанную на технологии .NET. Идеология построения дополнительных виртуальных рабочих мест состоит в том, что с помощью программных продуктов ICONICS GENESIS32 + WebHMI™ или ICONICS GENESIS64 вы создаёте в интрасети объекта (а при желании и в Интернет) Web-сервер. На этом Web-сервере размещаются наборы страниц, каждый из которых соответствует ра­бочему столу соответствующей группы специалистов. За процедурой доступа к такому виртуальному рабочему столу, на котором отображаются как данные реального времени, так и архивные параметры, следит сервер безопасности SCADA-системы. Он же и определяет, на какую страницу (набор страниц) будет направлен пользователь, который введёт свои учётные данные. После входа в систему конкретный пользователь увидит только те данные, которые находятся в его компетенции.

Такой подход является независимым от конфигурации конкретного компьютера, с которого происходит вход в систему (для связи с АСДУ используется только Internet Explorer). Однажды созданная конфигурация является легко администрируемой – все дополнительные рабочие места расположены (как и было сделано в упомянутом проекте модернизации) на одном Web-сервере АСДУ с программным обеспечением Microsoft Windows Server 2008 x64, включённой ролью Internet Infor­mation Service и поддержкой WebDAV. В случае необходимости внесения изменений в АСДУ системный администратор может просто опубликовать на Web-сервере обновлённую структуру пользовательского интерфейса.

Однако для реализации такого подхода организация пользовательского интерфейса должна быть системно-ориентированной. На практике же широко распространено отображение, основанное на анимированных по­этажных планах объекта. Собственно по­этажные планы («поэтажки»), электрические схемы, технические описания оборудования – это первое, что предоставляет заказчик для разработки АСДУ. Его персонал уже тысячу раз видел эти чертежи, привык к ним, и в качестве просьбы часто звучит: «Сде­лайте на АРМ так, чтоб внешний вид был, как на чертежах».

Рис. 1 иллюстрирует организацию набора мнемосхем в АСДУ по принципу сочетания на одном экране фрагментов поэтажных планов помещений.

Легко заметить, что отображение в АСДУ, основанное на поэтажном плане, удобно в основном только для диспетчера, осуществляющего общее наблюдение за всем комплексом. Например, из­менением цвета прямоугольника, отображающего фрагмент оборудования, можно показать, что в нём произошла аварийная ситуация и следует оповестить соответствующие службы. Но вот специалисту, обслуживающему, скажем, систему кондиционирования, надо будет сначала щёлкнуть мышью в определённом месте на мнемосхеме, чтобы перейти к отображению конкретного кондиционера. Потом ему понадобится выбрать в нём определённые параметры, которые надо посмотреть. Далее может потребоваться доступ к архивам, как технологических параметров данного кондиционера, так и его аварий, сформировать отчёт в виде графиков, таблиц и т.д. Понятно, что поэтажная схема организации пользовательского интерфейса мало подходит для технического специалиста.

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

Для комфортной работы диспетчера прежде всего вводим как элемент ин­тер­фейса динамическую ленту диспетчеризации. Она одновременно будет яв­ляться информационно-управляющей областью (главным меню) пользовательского интерфейса, расположенной в верхней части мнемосхемы. Исполь­зование диспетчерской лен­ты позволит уйти от необходимости постоянного отображения поэтажного плана и навигации в нём. Информа­ционную область ниже диспетчерской ленты бу­дут теперь занимать мнемосхемы систем жизнеобеспечения ЦОД или 3D-сцены с по­являющимися информационно-ин­ст­рументальными панелями. Сразу следует отметить необходимость избавления от всех элементов, динамика которых подразумевает исполнение кода VBA, – опубликовать такую форму на Web-сервере АСДУ будет невозможно, поэтому всю динамику, написанную для экранных форм GENESIS32 на VBA, необходимо перевести на VBScript или JScript. Сказанное не касается SCADA-системы ICONICS GENESIS64, в которой VBA не используется.

Примеры вариантов диспетчерской ленты показаны на рис. 2. 

В верхней её части, помимо логотипа организации и часов, расположены клавиши доступа к архиву тревог и смены пользователя. Посередине ленты по всей её длине размещён элемент индикации тревог. На рис. 2а он в неактивном состоянии (серого цвета). Изображение полицейского проблескового маячка в его левой части также неактивно (зелёного цве­та). При возникновении аварийной си­туации индикатор становится активным и начинает мигать красным цветом. Одновременно начинает воспро­изводиться звук сирены. Также возникает красная рамка вокруг клавиши пе­рехода по подсистемам в нижней части диспетчерской ленты, обозначая вы­звавшую аварию подсистему (рис. 2б). В данном варианте на динамических лентах в качестве примера присутствуют три контролируемые подсистемы: «Сер­верные стойки» (собственно серверное помещение ЦОД, или «Ма­шинный зал»), «Система кондиционирования» и «Электроснабже­ние». Име­ется ещё достаточно свободного места для размещения пиктограмм перехода к другим подсистема ЦОД. Это могут быть, например, система видеонаблюдения, контроля доступа и другие. Теперь после перехода к пользовательскому интерфейсу, организованному по об­служиваемым АСДУ подсистемам, дис­петчеру до­статочно нажать на полосу отобра­жения аварии или подсвеченную клавишу перехода для перемещения непосредственно на мнемосхему (или к 3D-сцене) оборудования, вызвав­­шего нештатную ситуацию. А для того чтобы увидеть пространственную струк­туру расположения оборудования, на ленте (в левом верхнем углу) имеется пиктограмма в виде домика – «Домой» (рис. 2в и г).

Для организации дополнительных АРМ, как говорилось ранее, теперь необходимо всего лишь опубликовать на Web-сервере комплекты страниц, которые соответствуют группам персонала. В случае интеллектуальной 64-разрядной визуализации на сервере публикуются динамические сценарии перемещений персонала в 3D-пространстве. Такие сценарии, кроме 3D-путей, включают также последовательности автоматического появления информационных панелей и всплывающих окон и распределение ролей между ними. Для каждой страницы (3D-сценария) при конфигурировании политики безопасности АСДУ стандартными средствами сервера ICONICS GENESIS32/64 легко формируется её доступность или функциональность отдельных элементов для каждой группы пользователей, таким же образом распределяется и предоставление прав выполнения тех или иных операций с данными (например квитирование тревог). Вход в систему осуществля­ется с любого компьютера в сети предприятия, на котором установлен Internet Explorer, простым вводом в адресное поле IP-адреса или имени Web-сервера АСДУ ЦОД. После прохождения авторизации пользователь перенаправляется на страницу (комплект сценариев), соответствующую его принадлежности к конкретной группе пользователей. Как показала практика применения такого подхода, в частности, в ЦОД банковского уровня, уход от ис­пользования стандартных «толстых» клиентов (ис­пользовался GraphWorX32) и переход к Web-интерфейсу на рабочих местах об­служивающего персонала увеличили скорость доступа к нужным мне­мо­схемам в разы. После того как все не­обходимые ActiveX-элементы были за­гружены (это занимает ощутимое вре­мя только при первом обращении к Web-серверу АСДУ), время перехода к нужной мнемосхеме (сценарию) определяется только продолжительностью пе­реключения потока данных, а это означает, что фактически нужная мнемосхема загружается если не мгновенно, то очень быстро.

Реализация пользовательского интерфейса 3D

Переход на 64-разрядную SCADA-систему ICONICS GENESIS64 предоставляет совершенно новые возможности по организации пользовательского интерфейса. Прежде всего, это использование цифровой 3D-модели объекта диспетчеризации, что позволяет создать для диспетчерской службы эффект непосредственного присутствия на объекте и перемещения в нём. Кроме того, самих возможностей по осуществлению наиболее производительного диалога между АСДУ и диспетчером здесь на­много больше. Покажем это на примере реакции диспетчера (выбора им 3D-сценария поведения) на аварийное событие в центре обработки данных. 

На рис. 3а и б показана 3D-реализация АСДУ для нашего обобщённого примера ЦОД, на котором проводится модернизация. На экране диспетчер наблюдает нештатную ситуацию – выход за установленные пределы температуры в серверной стойке ТШ-1.6. Изображение стойки начало мигать красным цветом. Одновременно раздался сигнал тревоги, и на экране появилось окно с сообщением от сервера тревог с описанием данного события. Далее диспетчер щёлкает мышью, подведя курсор к месту аварии либо установив его на окно с сообщением об аварии, и «камера» внешнего вида начинает пе­ремещаться к первому ряду телекоммуникационных стоек – к зоне, где произошла авария. Так происходит выполнение сценария перемещения к аварийному узлу. Через секунду «камера» уже переместится к нужному месту, и перед диспетчером возникнет ряд стоек, в одной из которых обнаружена нештатная ситуация. Поскольку возникшая тревога связана с превышением климатических уставок, то на экране автоматически появляются панели с текущими значениями температуры в стойках и с их уставками. Это тоже входит в упомянутый сценарий. Отметим, что объём информации, предоставляемой диспетчеру автоматически в виде возникающих при перемещении «камеры» по объекту панелей с данными, является настраиваемым. Он может уточняться и согласовывается с заказчиком на этапе опытной эксплуатации. Более того, если количества информации, предоставляемой автоматически при перемещении в 3D-пространстве объекта, показалось недостаточно, то диспетчер всегда мо­жет вызвать на экран любые данные через главное меню (диспетчерскую ленту) или просто щёлкнуть мышью, установив курсор на объекте (например, сетевом анализаторе или датчике), данные о котором его интересуют, либо на месте расположения такого объекта (группы объектов).

Поясним сказанное на примере. До­пустим, диспетчер находится на энергоузле (виртуальной 3D-модели) ЦОД. 

Рис. 4 иллюстрирует его поведение при просмотре параметров размещённого там оборудования. На рис. 4а диспетчер, находясь в энергоузле, рассматривает данные реального времени по кондиционеру 2.1. Ознакомившись с данными и проанализировав их, он решает проверить параметры работы источников бесперебойного питания (ИБП). Для этого ему достаточно щёлкнуть мышью, установив курсор на любом из них (расположение источников на рисунке отмечено стрелкой). После щелчка «камера» отображения перемещается к линейке ИБП, а на экране ав­томатически появляются данные по их загрузке и состоянию аккумуляторов (рис. 4б). Далее, выбрав из линейки па­нель с названием ИБП2, диспетчер по­лучает из архива данные по одноимённому источнику (рис. 4в).

Видно, что вся процедура в 3D-модели ЦОД полностью аналогична реальному поведению диспетчера, как если бы он находился в помещении энергоузла.

Дополнение АСДУ мультимедийными возможностями

Для всех вновь создаваемых АСДУ оповещения о возникающих в системе нештатных ситуациях по мультимедийным каналам передачи информации (СМС-оповещения и уведомления электронной почты, бегущие строки и всплывающие окна, Skype-оповещения) сейчас уже практически стали стандартным атрибутом, свидетельствующим о грамотном использовании современных средств при построении таких систем. Однако ранее созданные АСДУ могут и не обладать такими возможностями. В одном из описываемых проектов эти возможности надо было полностью интегрировать в действующую АСДУ, в другом требовалось расширить свойства СМС-оповещений. Например, отправка СМС-оповещений на объекте разделяется по группам обслуживающего персонала и по должностям руководства – понятно, что высшее руководство объекта стоит ставить в известность только о возникновении критических тревог, таких как по­жар, затопление или отключение внешнего электропитания объекта. Но встречаются и специфические варианты проведения тонкой настройки СМС-информирования, например, пе­реход на режим СМС-оповещения отсутствующих сотрудников дежурной смены по всем, даже некритичным авариям на время их обеденного перерыва и снятие такого режима по их возвращении.

Для АСДУ, основанных на SCADA-системах ICONICS GENESIS32/64, наиболее простым и часто достаточным способом внедрения мультимедийного информирования является инсталляция и конфигурирование программного комплекта AlarmWorX32 Multimedia. Однако это программное обеспечение не всегда подразумевает наличие тонкой настройки с дружественным интерфейсом, необходимым для обслуживания специалистами службы эксплуатации. Для внесения изменений в на­стройки, даже таких как исправление номера телефона сотрудника либо за­несение в список информирования по­средством СМС или электронной поч­ты нового лица в службе эксплуатации, понадобится знание хотя бы основ функционирования SCADA-системы. Этими знаниями стараются обзавестись в процессе сервисного обслуживания, в противном случае возникает необходимость прохождения сотрудниками заказчика специальных курсов.

Другая возможность организации тревожных оповещений посредством СМС или электронной почты – это использование встроенных в SCADA-систему языков программирования. Для GENESIS32 языками программирования являются VBA, VBScript и JScript. Организация программирования реакции системы на события (скриптов) в GENESIS64 основана на языке JScript.NET.

В качестве примера можно привести управление GSM-модемом, подключённым к COM-порту сервера АСДУ, с помощью АТ-команд. Используя из­вест­ный ActiveX-элемент MSComm (Mic­rosoft), очень просто по аварийному событию инициализировать открытие COM-порта модема и отправку нужного СМС-сообщения, управляя АТ-командами. Запуск такого скрипта производится стандартным сервером тревог. Как вариант, можно с интервалом, например, в 30 секунд отслеживать появление файла с текстом аварийного сообщения в специально вы­деленной папке на сервере. Если такой файл появился, то содержащаяся в нём информация отправляется указанному в нём же абоненту через СМС или электронную почту. После передачи со­общений файл уничтожается (или пе­ремещается в папку «Отправлен­ные»). Подобная организация рассылки тревожных сообщений часто при­меняется в ЦОД банковской и торговой сфер.

Заключение

В статье рассмотрены часто встречающиеся на практике аспекты проведения модернизации АСДУ ЦОД. На примере нескольких реальных проектов показаны наиболее востребованные пути улучшения комфортности использования и расширения рабочих функций действующих АСДУ систем жизнеобеспечения вычислительных и коммуникационно-серверных центров обработки данных. Представлены возможности применения в АСДУ инновационных решений на базе 64-разрядных SCADA-систем нового поколения, в частности, трёхмерной (3D) визуализации с эффектом присутствия.

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

Автор – сотрудник фирмы «НОРВИКС-ТЕХНОЛОДЖИ»
Телефон: (495) 232-1817
E-mail: info@norvix.ru