ПО для распределенных многофункциональных объектов

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

Многосерверный и односерверный подход

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

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

Компромиссный вариант

Существует и третий вариант, когда в едином дата-центре возникает несколько серверов, что позволяет:

1. получить снижение нагрузки с одного отдельно взятого сервера;
2. увеличить скорость отклика системы на действие оператора;
3. уйти от физических ограничений единого сервера, не получив существенного увеличения расходов, связанного с ведением серверов СКУД по каждому филиалу отдельно.

Исходя из этого, можно сформулировать требования к ПО для подобного класса объектов.

Универсальность

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

В данном случае ПО СКУД должно подходить как для офисного здания или административного центра с большим потоком посетителей, так и гарантировать работу с парковкой и прочими вероятными элементами распределенных многофункциональных объектов.

Гибкость

Система должна уметь работать с максимально широким набором типов идентификаторов и считывателей, иметь интеграцию с актуальной и доступной биометрией и максимальные возможности на уровне интеграции со сторонними продуктами и иными системами, с которыми можно столкнуться на различного рода объектах:

1. видеонаблюдение;
2. ОПС;
3. лифты;
4. интеркомы;
5. системы хранения;
6. ключницы и т.д.

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

Соответствие корпоративным стандартам

Система, интегрированная в корпоративное ИТ-пространство, должна более или менее соответствовать корпоративным стандартам безопасности:

1. на уровне интеграции с Active Directory;
2. на уровне кросс-платфоменности системы, возможности организации сервера на базе альтернативной ОС;
3. на уровне определенных БД, используемых для хранения данных, шифрования части или даже всех данных, передающихся от одного компонента системы к другому, и т.д.

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

Ориентированность производителя на задачи распределенных объектов

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

Успех – в сотрудничестве

Задача оснащения СКУД распределенных многофункциональных объектов по определению относится к самому высокому уровню сложности. В этой области не следует искать или ожидать типовых решений.

Для эффективного построения системы требуется, чтобы в единой связке работали:

1. Заказчик с четким пониманием желаемого результата.
2. Опытный интегратор, готовый на всех уровнях поддержать и скорректировать идеи заказчика, перевести их в стадию серьезного, продуманного и обоснованного проекта.
3. Производитель СКУД, имеющий серьезный опыт реализации задач необходимого класса.

Фото: ru.freepik.com

Опубликовано: Журнал "Системы безопасности" #5, 2018