Контакты
Подписка
МЕНЮ
Контакты
Подписка

Как обеспечить бесперебойность работы ИК СФЗ

В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Как обеспечить бесперебойность работы ИК СФЗ

В статье рассматривается один из возможных способов повышения надежности интегрированного комплекса системы физической защиты (И К СФЗ) за счет "горячего резервирования" центрального контрольно-исполнительного оборудования. Среди ключевых понятий, которые уместно здесь употребить, следует назвать "горячее резервирование", "контроллер", "сервер".


Д.Ю. Шмалько

Руководитель группы стендовых испытаний ЗАО "КОМПАНИЯ БЕЗОПАСНОСТЬ"

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

"Горячее резервирование" центрального оборудования

Для минимизации рисков при аварийных ситуациях обычно еще при проектировании системы закладывают частичное замещение отдельных технических подсистем. Например, при сбоях в системе обнаружения и защиты от проникновения (СОЗП) охраняемая территория должна хорошо просматриваться системой видеонаблюдения. Другой вариант, о котором и пойдет речь в данной статье, - "горячее резервирование" центрального оборудования. Для повышения устойчивости функционирования ИК СФЗ1, который представляет собой сложную техническую систему и отдельные компоненты которого (компьютеры, локальная сеть, специальное оборудование, программные приложения) могут давать сбои, одним из возможных средств поддержания заданного уровня надежности комплекса при недостаточно надежных компонентах и элементах является "горячее резервирование"2. Цель данной операции -обеспечить безотказность комплекса в целом, то есть сохранить его работоспособность при возникновении отказа одного или нескольких элементов.

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

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

На сегодняшний день практически весь спектр предлагаемого на рынке контрольно-исполнительного оборудования имеет встроенную память, в которой можно хранить происходящие события, базу данных карт сотрудников, определенные настройки комплекса, в том числе и реакцию системы на конкретные события. То есть мы можем заранее сконфигурировать в контроллере включение нужного нам реле по сигналу тревоги на определенном тревожном шлейфе (ТШ). Кроме того, существует порт для связи с верхним уровнем (управляющим сервером) и порты для связи с периферией. Чтобы реализовать принцип "горячего резервирования", необходимо организовать связь между основным и резервным контроллером - фактически заложить в концепцию контроллера отдельный порт для резервирования. Благодаря каналам связи по данному порту контроллеры получат возможность обмениваться БД, что обеспечивает актуальность БД резервного контроллера в любой момент времени. По этому же порту резервный контроллер с определенной периодичностью опрашивает состояние основного контроллера, аналогично тому, как это делается в компьютерных сетях командой Ping. Данные схемотехнические решения требуется описать в программе (прошивке) контроллера, предусмотрев режим, в котором порты связи с периферией будут пассивны (то есть работать только на прием) либо полностью деактивироваться.


На рис. 1 изображена принципиальная схема, иллюстрирующая резервирование контроллеров СКУД, подключенных к одному управляющему серверу через коммутационные реле. Благодаря именно такому подключению контроллеров упрощается состав комплекса в целом. Ведь все конфигурирование системы происходит для одного контроллера, а когда включается механизм резервирования, то резервный контроллер подключается в тот же порт управляющего сервера. Линии связи от всех периферийных устройств заводятся параллельно: с одной стороны, это упрощает коммутацию и не требует использования реле для переключения линий связи от периферии, с другой - требует деактивации портов у пассивного контроллера. Для полноценной работы механизма резервирования используется несколько ТШ, заведенных на реле.

В начальном состоянии управляющий сервер связан через коммутационные реле с основным контроллером, который является активным. Сервер получает от основного контроллера всю передаваемую им информацию, может загружать изменяемую конфигурацию и управлять периферией. Резервный контроллер постоянно обновляет свою БД, линия связи с управляющим сервером разорвана коммутационными реле, а порты связи с периферией деактивированы. Как только основной контроллер выйдет из строя (например, по причине потери электропитания, физического разрушения, перегорания электрических цепей), резервный контроллер, не дождавшись ответа на запрос о состоянии основного контроллера, автоматически берет на себя активность. При этом у него активируются порты связи с периферией. Поскольку линии связи от периферии постоянно подключены к резервному контроллеру, то он сразу же начинает принимать от нее информацию и получает возможность управления комплексом в целом. Таким образом, сохраняется полная работоспособность комплекса, продолжают работать контроль доступа, световая и звуковая сигнализация. Максимальное время, на которое система может остаться без управления, фактически равно периоду между опросами резервным контроллером состояния основного. Как только резервный контроллер активировал свои порты связи с периферией, он может подать команду на коммутационные реле, переключив линию связи с управляющим сервером на себя. Лучше всего использовать реле периферийных модулей, к которым подключаются оконечные устройства, такие как считыватели и охранные датчики. В большинстве систем контроля доступа и охранной сигнализации с такой иерархией устройств имеются необходимые для реализации механизма резервирования реле. Нужно только учесть в прошивке контроллера возможность управлять данными реле по факту смены активности контроллеров. Чтобы избежать включения коммутационных реле 1 и 2, переключающих линию связи контроллеров и сервера, в тот момент, когда технический персонал восстановит работу основного контроллера и передаст ему активность, используется ТШ 4 (cм. рис. 1). Тревога на нем возникает при включении реле 4, а уже по этой тревоге включаются реле 1 и 2, переключая линию связи на резервный контроллер. Следует понимать, что переключение линии связи с управляющим сервером на резервный контроллер займет немного больше времени, нежели смена активности, тем не менее весь процесс восстановления контроля и управления охраняемым объектом занимает несколько секунд. В данную цепочку событий и действий можно также включить оповещение оператора о срабатывании механизма резервирования. Как показано на рис. 1, данная инструкция возникает по сигналу тревоги на ТШ 1, которая появляется после включения реле 3.


Переход обратно на обслуживание основным контроллером производится вручную. Отметим, что человеческий фактор требуется только для запуска алгоритма обратного переключения, например нажатия кнопки (на рис. 1 она подключена к ТШ 3), при котором возникнет тревога на соответствующем шлейфе, и необходим для предотвращения переключения линии связи от управляющего сервера на неработающий контроллер. Далее алгоритм отработает автоматически, выполнив набор необходимых управлений релейными выходами и тревожными входами, полностью возвращающих комплекс в исходное состояние. Одним из таких необходимых действий является выключение реле 5 с целью не допустить возникновения на ТШ 4 тревоги, по которой реле 1 и 2 включатся в сторону резервного контроллера.

Защита управляющих серверов

Схожий с вышеописанным принцип применяется и при резервировании управляющих серверов (рис. 2). Аналогично резервированию контроллеров используются основной и резервный серверы, каждый из которых может быть активным или пассивным. Говоря о резервировании серверов, мы подразумеваем резервирование некой программной части, отвечающей за обмен сообщениями между драйвером контроллера и клиентскими приложениями (далее - сервер обмена сообщениями), программ драйверов и БД. Причем для правильной работы резервировать нужно все вместе. В отличие от резервирования контроллеров для организации резервирования серверов достаточно только доработки программной части. Однако нужно учитывать, что серверы одновременно работают в компьютерной сети и должны иметь различные имена и IP-адреса. Соответственно для них понятия "основной" и "резервный" должны иметь непосредственное отображение в БД. При потере связи с основным драйвером основной сервер обмена сообщениями должен скомандовать резервному серверу взять на себя активность и одновременно дать команду клиентскому приложению на автоматическом рабочем месте (АРМ) разорвать связь с основным сервером обмена сообщений и присоединиться к резервному серверу обмена сообщениями. В то же время, если клиентское приложение теряет связь с основным сервером обмена сообщениями, оно должно самостоятельно присоединиться к резервному серверу, а резервный сервер - самостоятельно взять на себя активность. Чтобы клиентское приложение "знало", куда присоединяться в случае полного выхода из строя основного сервера, а на резервном сервере в такой ситуации сохранялась полная работоспособность системы, на каждом компьютере необходимо иметь локальную БД. Если в качестве БД используется Microsoft Access, то проще после каждого изменения конфигурации системы копировать файлы БД. При применении БД Oracle лучше использовать штатную возможность реплицировать БД. Однако при этом нужно быть внимательным, внося изменения в конфигурацию, чтобы не допустить коллизий.

Резервирование линий связи

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

Минимизация рисков

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

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

Опубликовано: Журнал "Системы безопасности" #2, 2010
Посещений: 12478

  Автор

Шмалько Д. Ю.

Шмалько Д. Ю.

Руководитель группы стендовых испытаний ЗАО "КОМПАНИЯ БЕЗОПАСНОСТЬ"

Всего статей:  2

В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик  |  К списку авторов  |  К списку публикаций