Comments 5
Статься вызывает много вопросов к автору…
Вы примерно представляете, как должен работать скуд вкупе с остальными системами (охранка, пожарка, видео)? Например, по пожарным правилам, при пожаре должны быть автоматически открыты все двери на выход. В охранке — при поднесении карточки к считывателю и скуд определил возможность доступа, помещение автоматически должно снятся с охраны. Таких мест сопряжения между системами не счесть и рассматривать скуд как что-то отдельное неправильно.
Ну и как бы использовать wifi и облака просто нельзя, потому что охранка/пожарка/скуд по всем нормам должны быть локальной с резервированием питания (охранка на 2, пожарка на 24 часа), чтобы обеспечить независимость и работу 24/7. Как будете роутеры резервировать? Каждому из них поставите ИБП стоимостью в 5-10 роутеров?
Как вы думаете, почему такого до сих пор нет? Я работаю в разработке охранки и т.д более 25 лет, но НИКОГДА не удавалось ничего стандартизировать, ни контроллеры, ни датчики, ничего вообще? Потому что имеются чрезвычайно жёсткие требования по питанию, по цене, в наличии сильная конкуренция и поэтому малейшее ноу-хау может принести много денег. Состыковать две-три системы, чтобы прокидывать сообщения? На это идут почти все производители… Открыть протокол или начать работать в чужом протоколе? Только если это принесёт много денег и зароет конкурентов.
Так что, господа, стандартизация в охранке / пожарке /скуде просто невозможна, и у вас два пути — либо разрабатывать всё остальное и писать путные АРМы, либо интегрироваться с теми, кто это уже сделал.
Контроллер как сервер
СКУД как сервис
Вы примерно представляете, как должен работать скуд вкупе с остальными системами (охранка, пожарка, видео)? Например, по пожарным правилам, при пожаре должны быть автоматически открыты все двери на выход. В охранке — при поднесении карточки к считывателю и скуд определил возможность доступа, помещение автоматически должно снятся с охраны. Таких мест сопряжения между системами не счесть и рассматривать скуд как что-то отдельное неправильно.
Ну и как бы использовать wifi и облака просто нельзя, потому что охранка/пожарка/скуд по всем нормам должны быть локальной с резервированием питания (охранка на 2, пожарка на 24 часа), чтобы обеспечить независимость и работу 24/7. Как будете роутеры резервировать? Каждому из них поставите ИБП стоимостью в 5-10 роутеров?
Будущее
Стандартизация как тренд
Как вы думаете, почему такого до сих пор нет? Я работаю в разработке охранки и т.д более 25 лет, но НИКОГДА не удавалось ничего стандартизировать, ни контроллеры, ни датчики, ничего вообще? Потому что имеются чрезвычайно жёсткие требования по питанию, по цене, в наличии сильная конкуренция и поэтому малейшее ноу-хау может принести много денег. Состыковать две-три системы, чтобы прокидывать сообщения? На это идут почти все производители… Открыть протокол или начать работать в чужом протоколе? Только если это принесёт много денег и зароет конкурентов.
Так что, господа, стандартизация в охранке / пожарке /скуде просто невозможна, и у вас два пути — либо разрабатывать всё остальное и писать путные АРМы, либо интегрироваться с теми, кто это уже сделал.
ничто не мешает автономным контроллерам иметь ethernet-интерфейс, например. В чрезвычайной ситуации пропадет только связь, но аварийные сценарии работы будут выполняться.
Может быть вы не в курсе (надеюсь, что ошибаюсь), но даже древние контроллеры PERCo общались по Ethernet. И, собственно, эта логика и описана: мастер-контроллер программируется с рабочего места, а потом рассылает конфигурации подчиненным контроллерам (или они тоже централизованно программируются? не помню уже), которые действуют автономно до следующего обновления (кажется, ничего не перепутал).
Другое дело, что странно измышления на тему «должно быть стандартизировано» слышать от тех, кто вообще-то должен быть паровозом. Ну раз уж у нас PERCo один из лидеров в СКУД.
Другое дело, что странно измышления на тему «должно быть стандартизировано» слышать от тех, кто вообще-то должен быть паровозом. Ну раз уж у нас PERCo один из лидеров в СКУД.
я с perco дела не имел и, наверное, неправильно выразился. Ethernet удобен для передачи конфигурации и сбора информации о состоянии системы. Но в случае пожара или отключения электричества СКУД и пожарная сигнализация должны продолжать автономно функционировать и связь между элементами этих систем должна обеспечиваться отдельными линиями связи, не зависящими от сетевого оборудования. А что касается стандартов, вроде бы же есть ONVIF Profile A.
Если честно, я бы не удивился, если бы в PERCo про ONVIF в этом ключе вообще не знали.
Что касается СКУД, то, опять же, по моему мнению, эти товарищи уже «не первый раз в поход ходят», поэтому с железками и логикой проблем нет. Поэтому действительно, очень много вопросов к материалу.
Что касается СКУД, то, опять же, по моему мнению, эти товарищи уже «не первый раз в поход ходят», поэтому с железками и логикой проблем нет. Поэтому действительно, очень много вопросов к материалу.
Вроде этого, наверное, получится
Sign up to leave a comment.
Новые подходы к построению СКУД при использовании WEB-технологий