Введение. Пора начинать модернизацию
Правильно спроектированная автоматизированная система диспетчерского управления (АСДУ) центра обработки данных (ЦОД) значительно повышает безотказность работы всего центра. Кроме того, АСДУ способствует увеличению жизненного цикла оборудования ЦОД, минимизируя время его работы в экстремальных условиях. Поэтому, с точки зрения взаимодействия эксплуатационных служб ЦОД с системой диспетчеризации, важным является не только оповещение диспетчера об аварии, о выходе из строя того или иного узла, но и анализ динамики эксплуатационных параметров с целью недопущения их выхода на критические режимы.
Обозначив эту цель как показатель эффективности работы диспетчерско-эксплуатационной службы, следует понимать, что для её достижения никогда не стоит считать эксплуатируемую вами АСДУ совершенной. Развитие методов и систем диспетчеризации продолжается непрерывно, поэтому существующая система диспетчеризации была совершенной, в лучшем случае, только в процессе её проектирования. На этапе интенсивной эксплуатации АСДУ всегда появится целый список пожеланий и замечаний по улучшению работы системы, её модификации. Например, служба эксплуатации стала замечать, что простые на их взгляд операции взаимодействия с АСДУ, такие как получение графиков параметров из архива или переход от одной подсистемы к другой, занимают на автоматизированном рабочем месте (АРМ) диспетчера неоправданно длительное время. Или стали раздражать невнятная цветовая схема отображения нештатной ситуации и необходимость последующей длительной навигации в системе, когда, скажем, вместо одного щелчка мыши на тексте аварийного сообщения для перехода к подсистеме, его вызвавшей, АСДУ заставляет вас производить целую серию различных манипуляций, чтобы получить на экране параметры неисправного узла.
Помимо всего этого неизбежно и возникновение новых представлений о комфортности работы с системой диспетчеризации, основанных на появляющихся на рынке инновационных разработках, в том числе, систем интеллектуальной визуализации.
Короче говоря, первоначальные положительные эмоции от общения с системой диспетчеризации забылись, а количество претензий и пожеланий начинает увеличиваться по нарастающей. И это тем более досадно, когда вы знаете, что все ваши претензии устранимы, пожелания вполне реализуемы, а новые программные продукты сулят куда бо'льшие возможности, подобно тому, как, например, 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 GENESIS64 Web-доступ уже включён в саму SCADA-систему, основанную на технологии .NET. Идеология построения дополнительных виртуальных рабочих мест состоит в том, что с помощью программных продуктов ICONICS GENESIS32 + WebHMI™ или ICONICS GENESIS64 вы создаёте в интрасети объекта (а при желании и в Интернет) Web-сервер. На этом Web-сервере размещаются наборы страниц, каждый из которых соответствует рабочему столу соответствующей группы специалистов. За процедурой доступа к такому виртуальному рабочему столу, на котором отображаются как данные реального времени, так и архивные параметры, следит сервер безопасности SCADA-системы. Он же и определяет, на какую страницу (набор страниц) будет направлен пользователь, который введёт свои учётные данные. После входа в систему конкретный пользователь увидит только те данные, которые находятся в его компетенции.
Такой подход является независимым от конфигурации конкретного компьютера, с которого происходит вход в систему (для связи с АСДУ используется только Internet Explorer). Однажды созданная конфигурация является легко администрируемой – все дополнительные рабочие места расположены (как и было сделано в упомянутом проекте модернизации) на одном Web-сервере АСДУ с программным обеспечением Microsoft Windows Server 2008 x64, включённой ролью Internet Information 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 (Microsoft), очень просто по аварийному событию инициализировать открытие COM-порта модема и отправку нужного СМС-сообщения, управляя АТ-командами. Запуск такого скрипта производится стандартным сервером тревог. Как вариант, можно с интервалом, например, в 30 секунд отслеживать появление файла с текстом аварийного сообщения в специально выделенной папке на сервере. Если такой файл появился, то содержащаяся в нём информация отправляется указанному в нём же абоненту через СМС или электронную почту. После передачи сообщений файл уничтожается (или перемещается в папку «Отправленные»). Подобная организация рассылки тревожных сообщений часто применяется в ЦОД банковской и торговой сфер.
Заключение
В статье рассмотрены часто встречающиеся на практике аспекты проведения модернизации АСДУ ЦОД. На примере нескольких реальных проектов показаны наиболее востребованные пути улучшения комфортности использования и расширения рабочих функций действующих АСДУ систем жизнеобеспечения вычислительных и коммуникационно-серверных центров обработки данных. Представлены возможности применения в АСДУ инновационных решений на базе 64-разрядных SCADA-систем нового поколения, в частности, трёхмерной (3D) визуализации с эффектом присутствия.
Статья, думается, будет полезна для специалистов, делающих ставку на внедрение новейших технологий и разработок в области диспетчеризации и АСУ ТП. ●
Автор – сотрудник фирмы «НОРВИКС-ТЕХНОЛОДЖИ»
Телефон: (495) 232-1817
E-mail: info@norvix.ru