Комментарии 22
Все + облачного скуд, например удаленный доступ, да и остальное, впрочем, реализуется без всяких облаков уже 100500 лет.
sarcasm жду скуд с блокчейном.
Сейчас все больше и больше привязки к интернету охранных систем, да и разработчики идут за трендами, обновления рассылают автоматически и отлично ложат приборы.
Недавно, один из украинских разработчиков — разослал очередное обновление — результат 20 охранных приборов перестали заряжать акб и это на небольшой охранной фирме.
В следующий раз при обновлении прибор просто сходил с ума, оказалось, что новая версия ПО не совместима со старой конфигурацией.
Не пойму в чем сложность и разница проектирования скуд облачного и сетевого?
Считыватели/замки/контроллеры/блоки питания/витая пара никуда не денется.
В любом современном СКУД есть WEB Client. Сразу вопрос к объему его функционала 15- 30%.
Из Вашего поста действительно интересный вопрос о сложностях /разнице проектирования. На стороне аппаратной части разница не велика. Мы активно приветствуем сохранение часто уже установленных Парсеков, Болидов, Кодосов и Рубежей или даже рекомендуем их установку. И для заказчиков в первую очередь решаем задачу разгружая
- Бюро Пропусков -пропуска запрашиваются, согласовываются удалённо. Штатная единица отдела кадров постепенно рассасывается.
- Охрану на КПП- посетитель идёт со своим электронным пропуском на смартфоне. Тем не многим, пользующимся кнопочным телефоном, печатают QR пропуск. Экономию на rfid любого форм фактора легко посчитать. Охране остаётся иногда протянуть руку к чековому принтеру и надзирать за проходом. Тема верификации за скобками. Тут не комментирую.
Подробнее здесь https://www.youtube.com/watch?v=vWynPO7pyBc
Всё-таки я не вижу ни одного очевидного плюса, говорю вам как человек, который монтирует, обслуживает различные системы скуд, ос, пс, видеонаблюдения.
Облако системам безопасности ни к чему.
- Система должна быть максимально стабильной и безотказной.
2.Антивандальным должно быть всё.(привет сканер) - Личные данные
- Не знаю, как у вас, но наши клиенты очень не любят, когда они выступают тестерами и не очень горят желанием устанавливать багфиксы, которые могут с легкостью сделать из вашей кареты тыкву.
5.Работнику выдать карту не проблема и экономия на картах выглядит весьма неубедительной. Как и распечатка нового пропуска на принтере мне больше кажется дырой в системе безопасности, чем +
На тот же смартфон сфотографировал пропуск и вперёд )
Да, и думаю на месячную абонентскую плату можно прикупить вагон и маленькую тележку карт.
Дешевле/проще развёртывание? Да фигушки, основная работа — турникеты, магнитные замки, вот всё это никуда не девается.
Вот то, что вы ещё один рычаг управления безопасностью компании передаёте третьим лицам, подсаживаетесь на абонплату, вносите ещё одну точку отказа, это да, этого у облачных СКУД не отнять.
начну с конца. Возражение "подсадить на абонентку" это первое что мы услышали от нашего самого первого пользователя. К сведению это Завод в средней полосе России 2.500 рабочих. Быстро поняли что проблема волнует каждого без исключения и сделали со временем по запросу сборку на HW заказчика. Забавно, то, что наша, поверьте, очень недорогая опция локальной сборки микросервисов востребована только ведомствами, которые иначе не могут. Коммерсанты быстро меняют мнение получая регулярные обновления и багфиксинги, совершенствуя свои бизнес процессы в сообществе.
Насчёт дешевизны прокси карт и брелков. Они таки в разы дороже бумажного пропуска на кассовой ленте… https://www.youtube.com/watch?v=b9UsAPkL4MQ на 1:40 мин
а) У многих предприятий когда-никогда бывают периоды «не очень», когда денег на поддержку подобных сервисов реально нет. И что, в этом случае устраивать день открытых дверей?
б) Это же касается и облачных провайдеров. Сегодня он есть и работает, завтра набрал кучу клиентов и вконец охренел, реагируя по максимальному лимиту SLA, с «восемь часов на реакцию по каждому письму в переписке», послезавтра вообще загнулся. И что вы будете делать, если у вас хардварный вендорлок на облачного провайдера? Терпеть и платить, или демонтировать все эти малинки/ардуинки, и покупать/инсталлировать новую СКУД?
Поэтому нет, облачная СКУД — это плохая идея. Понятное дело, продать можно что угодно, лишь бы продажник был красноречив, но… вот вы даже сами плохо понимаете, для чего нужен подобный продукт:
Коммерсанты быстро меняют мнение получая регулярные обновления и багфиксинги
Какие, к лешему, регулярные обновления в СКУД??? Эта система должна быть стабильной, с минимумом обновлений, закрывающих только обнаруженные критичные баги.
вынашивая идею облачного СКУД мы напридумывали себе множество, как нам казалось, преимуществ. А на практике подтвердились лишь очень не многие, но за-то гораздо ярче чем мы ожидали. Вот некоторые:
- Наибольшим преимуществом оказалась возможность для любого Заявителя на пропуск, будь это Принимающая сторона, Посетитель, или, что нередко, третье лицо сделать это удалённо, пройдя согласование множества инстанций (пример из жизни; диспетчер экспедитора подающий заявку на своего водителя забрать груз для грузовладельца на складе временного хранения, пользователь системы в этом случае Складской Комплекс).
- Возможности руководителя/ управляющего объектом недвижимости оперативно видеть динамику заполняемости объекта. И отслеживать "авторов" этой заполняемости. Количество посетителей к тому или иному арендатору прямо пропорционально изношенности входных групп, кол-ву поломок лифта, грязи в с/у и т.п.
Если интересно, могу продолжить ...
Если речь идет об облаке, то это опасно всегда. Если речь о компьютерной сети, то для целей СКУД она должна быть только внутренней. Наружу должно выводиться только состояние системы и "тревожная кнопка" для принятия экстренных решений.
Мне не понятно, зачем удаленный доступ для ВСЕХ возможностей СКУД? Вы что, собираетесь открывать ворота или проходить через турникет, находясь в другом городе?
Для нескольких отчетов, необходимых руководству, не стоит подвергать опасности все предприятие. Лучше сменить руководство...
Идея с отчетами высосана из пальца. Отчеты нужны только кадровикам раз в месяц для расчета ЗП, да и то это можно автоматизировать, как и уведомления о нарушениях трудового распорядка. Никакой необходимости получать отчеты на смартфон нет, тем более смотреть онлайн.
очень в точку замечание про открывание ворот из другого города, да даже из соседнего здания. К слову, это может быть очень небезопасно. Честно сказать мы на это не сразу обратили внимание. Решение нашлось в привязке к геолокации смартфона и всплывающей кнопке уведомления или проверке BLE (если договариваемся пользоваться bluetooth)
Насчёт безопасности, ОЙ КАК СОГЛАШУСЬ. Каждый раз волнуюсь, когда совершаю очередной платёж в банкклиенте или apple pay. Регулярно проверяю не залез ли кто в эл. кошелек. До сих пор, как то обходилось. Просто мне везёт наверное… :)
Что вы там говорили про пропавший интернет? ДЦ Tier-3, два канала через разных провайдеров через один колодец?
А теперь подумайте о двух типах аварий:
- экскаватор в 200 метрах от территории перевопал кабельный ввод и накрылись оба канала
- ошибка с анонсами в BGP и на 30-120 минут ваш ЦОД (или ваши операторы) лишились связанности
В итоге любой простой приводит к крайне серьёзным последствиям для компании.
Если не хотите сложностей, то СКУД должен быть максимально локальным и максимально отвязанный от внешней сети. Всё, что можно свободно отдавать во внешнюю сеть — это статистика.
грамотное замечание. Молодец. Есть такие риски. Даже были пару раз в описанных ситуациях. Действительно, когда понимаешь что 12.000 пропусков разом встают, ооочень неприятное ощущение. На этот случай задумались делать резервное локальное зеркало на условно недорогом мини-ПК на объекте. На языке автомобилиста, так называемая "докатка". Надеемся "на 30- 120 минут" будет хватать.
В система с закрытым контуром сети (банки и пр.) никто вообще не будет использовать облачные решения по политикам безопасности
Таким образом, облачный скуд может не пустить меня в офис на ровном месте? Или — ещё лучше — не выпустить?!
«Только через твой труп!» © Японский отказ
1. Смартфоны нужны не самые дешевые. Не каждый будет внепланово менять смартфон по причине возможности его использования как пропуска
2. Шансы сломать\потерять\забыть телефон выше, чем RFID метку.
3. В некоторых местах проще поставить отдельный пост охраны, чем турникет. На случай отказа электричества \ Интернета должна быть возможность удостовериться что данный гражданин может пройти через пост.
4. Любые системы безопасности должны быть в одних руках, то есть видеонаблюдение, СКУД не должны быть в облаке.
5. СКУД должна обслуживаться ( в данном случае ) ограниченным числом лиц, остальные могут либо отправить заявку удобным образом, либо «только чтение».
2. Повторюсь смартфон в качестве средства хранения пропуска это опция. QR пропуск на бумажном носители, АРМ охраны, на том же смартфона- всё это остаётся.
3. Всё тот же смартфон в качестве АРМа Охраны. И турникет в принципе не нужен.
4. Без комментария. Если не должны, то не должны.
5. Управления правами пользователя, сотрудника объекта как в LAN так и в облаке одинаково работает.
Подробнее здесь www.youtube.com/watch?v=vWynPO7pyBc
2. В основе их решения — комбинация типовых метдово идентификации пользователя. И RFID, и NFC, и QR — все это уже давно отлажено и работает без проблем. Не упомянуты простые пин-коды, но и до них скоро додумаются (подсказка: HMI).
3. Некую особенность предлагаемому решению придает упор на гостевые пропуска. Думаю, что это даже не особенность, а основная часть решения.
4. Традиционный СКУД для их системы — это нижестоящая подсистема, реализующая функции управления устройствами преграждения. Очевидно (и логично), что парни не хотят заниматься контроллерами, они сосредоточены на серверном решении: согласовать, выдать, проверить и дать команды на открывание точки прохода. Если у СКУДа имеется API — решения легко соединяются. А если и нет API — контроллер для управления исполнительным устройством можно найти, или сделать самим.
5. Комбинация уже установленного на объекте СКУДа и предлагаемого решения может дать хороший результат (может и не дать, но это уже вопрос не технологий, а бизнеса).
Исходя из этих предпосылок очевидно, что целью статьи является привлечение внимания к решению, а не технические особенности реализации.
Молодцы!
Ворчать, брюзжать и приводить в пример "… опыт одного магазина..." (М.Жванецкий) — бессмысленно. Для продвижения решения нужна реклама, что мы и наблюдаем.
Еще раз: МОЛОДЦЫ!
Облачный СКУД — ЗА и ПРОТИВ из первых рук