Comments 33
Молодцы, что похоронили эту чудище сделанную дендерно-фикальным методом.
Интересная статья, автор пиши ещё!
"Ни в коем случае не менять направление турникетов на КПП" - вот это 100% подмечено. Тут в одном интерфейсе кнопки местами поменяли, эффект был разрушительным :-)
Спасибо за то что разбавил мою скучную лекцию по физике, статья мне понравилась )
C2000-Ethernet + C2000-2, по моему мнению хуже СКУД на Рубеж.
А лучше использовать нормальные контроллеры доступа, их российского производства полно: Apollo(завялено что теперь российская), Parse, Perco, Eslsys, Castle/Sphinx, Rusguard, и пр.
Плюс мильон, хуже не видел ....
+100500. БОЛИД это ж больше про охранную сигнализацию и пожарку, поэтому родной СКУД ставят прицепом к ним -- в такой схеме действительно и обслуживать проще и нет зоопарка производителей и встроенная интеграция. Но вот если брать и строить систему с нуля, то лучше какого-нибудь производителя именно СКУД: у них и возможностей больше и проще настройка
Использовать вами перечисленные может и лучше, но заказчик порой выбирает в пользу дешевизны. А болид дешевле парсека, перко и сигура тех же. Хотя и функционал у них значительно круче, а софт не такой убогий как болидовский орион.
СКУД , да ещё такой большой.. Геморой.. Нет уж
С АПС сухари приходят на разрыв цепи замка, так же в этой цепи должна быть кнопка аварийного открытия двери, которая тоже должна рвать контакт замка. Если должно отображаться состояние аварийной кнопки, то можно нормально открытые контакты кнопки подключить на контроллере на контакты предназначенные для охранных датчиков, к примеру. Всё что касается разблокировки двери по пожару, должно физически рвать цепь замка, а не выполняться скриптами на контроллере.
В реальном мире надёжнее всего физический разрыв питания замка. Моделируем ситуацию. Пожар, всё полыхает. Ваша сотня контроллеров в пожаре начинает вести себя чудесно. Какой-то контроллер сплавился и перестал отдавать сигнал дальше. Контроллеры не разблокируют двери, люди горят. Не лучший вариант. Теперь моделируем ситуацию с системой апс болид и с участием релейного модуля С2000-СП1. Цепь питания замка проходит через реле, которое после сработки пожарной тревоги отключается и замки разблокируются в любом случае, так как с реле уходит питание и оно перестаёт пропускать ток на замок. Люди целы, никто не сгорел, никто не сел в тюрьму. =)
как вы далеки от реального, на каждую железку есть нормы, сколько должна гореть, и кабелей это тоже касается, как и реакция ПС на первичные признаки возгорания.
Когда что то будет гореть, уже все должны покинуть защищаемое помещение.
Я не далёк от реального, я монтирую все СС, включая и АПС, и СКУД и знаю о чём говорю. Сколько горит железка без разницы и что там у неё в характеристиках горения. Самый лучший вариант разблокировки замка при пожаре, это физический разрыв электрической цепи замка. Более того, на большинстве объектов Москвы, особенно бюджетных, у вас иной вариант не примут принимающие организации.
Ну всё-таки правильнее сухарь АПС заводить на специальный вход "Пожар" контроллера СКУД. Другое дело что у БОЛИДовских С2000-2 такого входа нет :)
У болида есть С2000-СП2, которая замечательно рвёт цепь питания замка
Таки да, ваша правда. Я за специальный вход "Пожар" голосую исключительно потому, что тогда контроллеры не начинают спамить сообщением "Взлом двери".
Сейчас веду проект СКУД на контроллерах Parsec. Схема подключения следующая. Реле замка на контроллере, реле на С2000-СП2, кнопка УРД, замок. Кнопка УРД и С2000-СП2 отдают на контроллер информацию о своём состоянии(открыты/закрыты). Так как контроллер Parsec позволяет вытворять подобное, в отличие от болидовской С2000-2. Хотя теоретически, можно попробовать и УРД и С2000-СП2 подключить последовательно на клемник охранного датчика. Но не уверен, что клемник охранного датчика можно прикрутить в Орионе не как охранный датчик, а как контроль состояния открытия/закрытия реле.
Сталкивался, надо было обновить систему безопасности предприятия, даже турникет был своей разработки, поставить видеонаблюдение, внедрить систему Орион от Болида своими силами. Все участвующие, электрики, сисадмины попросили прибавку к зарплате и были посланы нафиг. Был конкурс из 5 фирм, мы оценивали коммерческие предложения. По итогу руководство привлекло ИП из своих, делали пол года, потом ИП кинули на деньги, работы прекратили, потом частично заплатили. Нам передали систему на обслуживание, накинули 1000 руб к зп. Я программировал приборы и т.п.
А почему не пошли дальше и не сделали проход по биометрии?
Ведь кучу всего меняли.
з.ы за статью спасибо, прочитал с удовольствием.
Тему биометрии даже и не рассматривали, честно говоря. Нет такой потребности. Конечно есть понимание, что использование биометрии более надёжно и не допускает таких ситуаций, как с картами доступа. Например, передача карты доступа коллеге для отметки в системе учёта рабочего времени. К слову, такая ситуация пару раз случалась (явление крайне редкое) и охраной пресекалась. И на этот случай вполне хватает функционала ПО Фотоидентификации на посту охраны и системы видеонаблюдения.
Я уже не говорю про вероятное удорожание проекта и возможные, хоть и временные, сопротивления среди персонала.
В общем, это пока для нас неактуально, как руководство посчитает нужным внедрять — сделаем.
Потому, что ЕБС
Сейчас про биометрию можно забыть навсегда.
Спасибо ебс и штрафам. Охотно верю в простоту интеграции. Но платить за кбс или тем более за доступ к общей базе не будут люди.
Сделали просто дополнительную кормушку.
прочитал с удовольствием.
могу заметить, что желательно такое создавать с изначально ведущимися проектом и журналами всех линий и коммутаций и обслуживающие подразделения буквально, как говорится, под угрозой всевозможных кар, вести журналы в бумажном и сводимое в единый электронный всех изменений и работ, иначе, буквально за год-два всё может пойти по звезде.
как все отметили - самое проблемное во всех работах безопасности, и не только, человеческий фактор.
и попытки руководства оптимизировать или как-то незамечать проблемы - вываливаются в дальнейшем в большой геморрой.
Оооо! Вижу за автором начало знакомства с многообразием способов взаимодействия со СКУДами. Из личного - виденные мной "Болиды" работали с картами EM-Marine, и хранят шестнадцатеричное представление номера карточек, другие системы могут их хранить как в виде "длинного целого", так и в виде "разделённого точкой" - все форматы замечательно конвертируются друг в друга (хоть на тетрадном листике, хоть простейшим скриптом). Упомянутый "расчёт компенсации питания" колхозил трижды, разными способами - от установки на раздаче столовой ПК (с ридером), отображающим данные желающего пообедать, интерфейсом 1С, до полностью самописной проги, дёргающей USB-релюшку, открывающую турникет на входе в столовую (прога тащила пропуска из БД "Парсека", "Болида" и текстового файлика, выгружаемого из аналога описанного в статье "Рубежа"), либо вообще, установкой Болидовского контроллера на кассе - если "проход разрешён", пробивается "бесплатный обед", если "проход запрещён" - идёт платное обслуживание (в том случае столовая находилась за территорией завода, и обслуживала всех желающих; данные в Болид импортировались из 1С:ЗУП, где в зависимости от графика смен, сотрудникам назначались "смены питания"). Во всех случаях на мне лежала как минимум интеграция разрозненных баз; обычно "модуль обмена" колхозил на PHP, иногда даже с вэб-интерфейсом... давно, правда, это было - думаю, с тех пор появились куда более продуманные и завершённые решения - например, последний проект, с которым я пересекался - пришлось загружать в какую-то надстройку над Р-Кипер активные пропуска под видом "абонементов"... благо, с тех пор отдалился от СКУДов и заводских столовых =)
Кипучий СКУД