Блог производителя

Поскольку применительно к рангам сети СКУД нет общепризнанных или стандартизированных терминов, то начну с определений для этой заметки:

• Одноранговая сеть контроллеров СКУД — подход к построению сети контроллеров, при котором все контроллеры играют одинаковую роль в системе и непосредственно управляют исполнительными устройствами (дверьми, турникетами и пр.). Примеры систем: «Parsec», «Perco S-20» и другие.
• Двухранговая сеть контроллеров СКУД — подход к построению сети контроллеров, при котором часть контроллеров (будем назвать такие контроллеры интерфейсными модулями) занимается управлением исполнительными устройствами, в то время как другие — только управлением интерфейсными модулями. Примеры систем: «Apollo», «Кодос ПРО» и другие.

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

Сейчас одноранговую СКУД делать можно и нужно. Память и процессор, которые устанавливаются, например, в контроллер «Sphinx E900I», вместе стоят нам 8 долларов. При этом процессор достаточно быстр для задач СКУД, а энергонезависимой памяти там — 4 Мб, что достаточно много для задач, решаемых контроллером СКУД.

Оставшееся место я посвящу борьбе с пережитками, вернее с доводами в защиту двух рангов и смешанной архитектуры.

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

Будущее безусловно за децентрализованными одноранговыми системами.

Александр Рыжов, ar@spnx.ru

Ни в коем разе не полная подборка, просто напишу, что вспомню по тематике контроля доступа на выставке MIPS-2009.

1. Равелин показал интеграцию СКУД Gate с 1С:Предприятие 8. Интеграция состоит в дополнении конфигурации 1С объектами, отвечающими за взаимодействие с СКУД Gate, при этом управление списками держателей карт, отчетами и прочим можно выполнять прямо с платформы 1С.
Работа была отмечена наградой за лучшую инновацию, по-моему вполне заслужено.
Кстати, подобная по идеологии интеграция, насколько мне известно, есть еще только лишь у Шэлни.

2. Впервые на выставку приехала Минская компания Акова, производящая и активно внедряющая в Белоруссии СКУД Скат, а так же платежную систему собственной разработки.
Сейчас компания выходит на Российский рынок.
Сотрудники компании, которые работали на стенде, приятно удивили наличием юмора и прямолинейностью суждений
По самому предложению сказать что-либо сложно, я так понял что компания и сама пока до конца не определилась с ценовой политикой и позиционированием своего решения.

3. СКУД Quest (а также Videonet) теперь принадлежит некой компании Skyros corporation, а вовсе не Пентакон. Показаны новые модели контроллеров, если я все правильно понял по функционалу все тоже самое, но на новой элементной базе.

4. Альфа-прибор показывал новый контроллер АПДА.21. Два считывателя, цена порядка 10 тысяч рублей.

Александр Рыжов, ar@spnx.ru

По запросу потенциального заказчика провели тест на скорость получения отчетов при наличии в базе 20 миллионов записей о проходах.

Данные условия не являются критическими для «Сфинкс» в каком-либо смысле, ограничения программы многократно превосходят требования конкретного заказчика.

Как-бы то ни было, тест мы провели и, если кому еще это будет интересно, вот его результаты:

• Отчет: 20mln_test.pdf
• Приложения: 20mln_reports.zip

Вкратце результат таков: выборка из базы в 20 миллионов проходов нескольких сотен произвольных событий и построение на их основе аналитического отчета занимает не более 45 секунд.

Александр Рыжов, ar@spnx.ru

В качестве возражения на мой призыв следовать открытым стандартам в сфере безопасности мне часто приводят мысль, что открытые стандарты хуже в плане собственной безопасности, т.е. стойкости ко «взлому».

По данной теме уже все придумано до нас Концепция обеспечения безопасности посредством засекречивания алгоритмов и протоколов традиционно называется «security by obscurity» («безопасность через сокрытие»).

К шифрам при использовании этого подхода имеет доступ только очень ограниченное число людей. Основные особенности такого подхода:

1. Используемый шифр не прошел всестороннего независимого анализа. Остается полагаться на компетентность его разработчиков и на то, что они не допустили существенных ошибок. В противоположность этому при разработке открытого шифра весь мир имеет возможность в течение многих лет пытаться найти в нем изъяны.
2. Используемая реализация (компьютерная программа, аппаратная реализация) не прошла независимого анализа и тестирования. Любая реализация, как правило, содержит ошибки.
3. Зачастую про используемый закрытый шифр разработчик просто не сообщает достаточно сведений для оценки его стойкости. При этом коммерческий разработчик может быть мотивирован сделать шифр не самым стойким, но зато, например, сократить себестоимость производства устройств, реализующих шифр.
4. Вышеперечисленные негативные факторы частично компенсируются закрытостью шифра.
5. Утечка алгоритмов и протоколов в широкий доступ часто приводит к быстрой полной либо частичной компрометации шифра. Один из вариантов утечки — обратный анализ закрытой реализации (кстати, иллюстрация к этой заметке — закрытый шифр карт Mifare Classic, а вот тут можно посмотреть видео как их «ломали»).

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

Александр Рыжов, ar@spnx.ru

На сайтах производителей СКУД, в рекламных журналах и на интернет-форумах встречается информация о технических решениях, примененных при создании той или иной системы.

Примеры таких утверждений:

• В наших контроллерах стоит 32-х битный процессор
• В наших контроллерах стоят 5 процессоров
• Процессоры в наших контроллерах работают на частоте 1 ГГц
• На наших контроллерах исполняется ОС Linux
• Мы используем сервер БД Oracle
• Мы используем сервер БД Firebird
• Мы используем трехуровневую систему предотвращения зависания
• Мы используем свой уникальный протокол для связи контроллеров с ПК
• Наша система одноранговая
• Наша система двухранговая
• Наш контроллер однопортовый (на одну дверь)
• Наш контроллер восьмипортовый

Я специально намешал в кучу решения, которые я считаю удачными и неудачными, решения наши и решения других производителей. Зачастую разные производители отстаивают исключающие друг друга точки зрения.

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

Например, что дает 32-х битный процессор? В чем конкретно «мощность», «скорость», «современность»? Какое конкретное действие с системой происходит быстро? Насколько быстро в тех конкретных условиях, в которых решение будет использоваться? Сколько секунд это займет? Сколько в среднем, сколько максимум?

Имея конкретные метрики, нужно сравнить их с другими решениями. И тут может оказаться что все не так, как казалось по-началу, и что, например, 8-и битный процессор для СКУД ни чем не хуже 32-х битного (или не оказаться).

См. также «О скорости линии связи».

Александр Рыжов, ar@spnx.ru

Вот тезисы моих двух докладов, сделанных на слете проектировщиков (встреча, организованная sec.ru 4 февраля в процессе работы форума ТБ):

I. Доклад “Кризис глазами производителя”.

1. Объем рынка. Цифр пока ни у кого нет, можно лишь быть готовым к разным исходам, в том числе к кратному падению.

2. Повышение цен на ТСБ.
2.1. На импорт как минимум вслед за валютным курсом.
2.2. На отечественное. Причины:
2.2.1. В разработках используются преимущественно импортные комплектующие.
2.2.2. Складские запасы поставщиков комплектующих уменьшаются. Доставка комплектующих под заказ зачастую требует от производителей увеличения объема оборотных средств.
2.2.3. Поставщикам комплектующих не чужды проблемы, которые испытывают все (труднодоступность кредитов, падение спроса).
2.3. Рост цен на ТСБ также может учитывать проблемы на всех этапах цепочки поставки (перекупщиков кризис тоже не обошел).

3. Возможны проблемы с поставками ТСБ.

4. Замедление развития продуктов.
4.1. В первую очередь “под нож” идут разработчики.
4.2. Перенос разработки в другие регионы потребует времени на выведение новых людей на продуктивный уровень работы.

5. Перераспределение рынка.
5.1. Замещение импорта отечественными решениями.
5.1.1. Импорт был дороже.
5.1.2. Импорт дорожает быстрее.
5.1.3. Цена при этом становится критичным фактором.
5.1.4. Проблемы с поставками импорта.
5.1.5. Российские системы зачастую не хуже импортных. Нужно только преодолеть проблему их выбора из большого числа представленных на рынке.
5.2. Изменение состава покупателей.
5.2.1. Увеличение доли внедрений ТСБ, имеющих прямой экономический эффект.
5.2.2. Увеличение веса фактора цены при принятии решения.
5.2.3. Рационализация поведения.
5.2.4. Уменьшение доли крупных заказчиков.
5.3. Возможно уменьшение роли дистрибьюторов, сокращение цепочек поставки.
5.4. Перераспределение в пользу гибких и рациональных участников.

6. Что такое гибкий участник.
6.1. Имеет возможность обслужить заказчика любого масштаба.
6.2. Работает с несколькими разными системами, несколькими поставщиками.
6.3. Знаком с многими техническими решениями, постоянно пробует новые.
6.4. Рационален. При выборе решения опирается только на факты, способен отделять рекламные заявления от фактов.

II. Доклад “Стандартизация СКУД”.

1. Зачем нужны стандарты.
1.1. Обеспечение технической совместимости компонентов различных производителей.
1.2. Снижение издержек на разработку.
1.3. Снижение издержек на поиск и изучение свойств продукции.
1.4. Введение общей терминологии, классификации.

2. Какие есть стандарты.
2.1. ГОСТ Р 51241-98.
2.1.1. Терминология, направления классификации, минимальные технические требования.
2.1.2. Стандарт существенно неполон.
2.1.3. Не дает технической совместимости компонент различных производителей.
2.1.4. Влияние на каждодневную жизнь производителей и потребителей минимально.
2.2. Де-факто: EM Marine, Mifare, HID и др. Дают полную техническую совместимость.
2.3. Де-факто: Wiegand, Dallas TM. Дают техническую совместимость для типовых случаев.
2.4. Де-факто: RS-485, Ethernet. Дают минимальную техническую совместимость.

3. Каких стандартов пока нет.
3.1. Интерфейс считыватель-контроллер (более полно чем Wiegand/TM).
3.2. Интерфейс контроллер-контроллер и контроллер-сервер.
3.2.1. Положение дел в смежных областях, попытки переноса на СКУД (LonWorks, BACNet, EIB, CAN, ZigBee. СКУД Itrium).
3.3. Интерфейсы межсистемного взаимодействия (аппаратные и программные).
3.3.1. Положение дел в смежных областях (OPC).

4. Производители, которые не придерживаются стандартов. Почему, зачем.

5. Что делать. Будем пытаться вырабатывать недостающие стандарты.

В процессе ответа на вопросы по теме “Стандартизация СКУД” я еще сообщил то, что не было изначально тезисом, а именно некоторые идеи как вырабатывать недостающие стандарты:

• проще всего договариваться между собой производителям неконкурирующих продуктов (например, разных подсистем безопасности). Такие производители наиболее готовы к совместному диалогу, явно заинтересованы в стандартизации, для них это несет даже сиюминутную выгоду.
• данная работа должна делаться на принципах максимальной открытости и коллективизма.
• необходим “круглый стол” производителей, но для начала надо выработать хотя бы рамочное понимание задач, повестку встречи, мы этим занимаемся.

Александр Рыжов, ar@spnx.ru

Пришло время в очередной раз улучшить что-нибудь в наших контроллерах.

Текущее исполнение контроллеров: Плата, как показано вот здесь, металлический корпус с подводом проводов снизу и сверху, как показано здесь.

Как обычно изменение аппаратной части не повлечет потери совместимости либо каких-либо других лишних хлопот. Просто с некоторого момента будут отгружаться контроллеры в новом исполнении.

К текущему исполнению накопились следующие пожелания:

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

Сразу скажу что не все эти пожелания будут реализованы. Например, мы все еще считаем что блок питания не должен идти в комплекте.

Что интересно узнать:

1. Ваше мнение об этих пожеланиях: что стоит сделать, а что лучше оставить как есть.
2. Какие-то другие пожелания, если они есть.

Александр Рыжов, ar@spnx.ru

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

Не скрою, поводом к этой заметке послужила публикация вот этого сравнения. Данная публикация от «Легос» обладает типовой особенностью сравнения цен с конкурентами — в ней безапелляционно «побеждает» составитель сравнения

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

• Очевидные технические требования: число автоматизируемых дверей, турникетов, удаленных рабочих мест и т. п. Система может стоить дешево на одной двери, быть дорогой на 5 и снова оказаться дешевой (на фоне других) при 20 дверях.
• Какой функционал требовать от сравниваемых систем. Как правило, составители сравнения закладывают тот функционал, который у них стоит дешевле чем у других.
• Каких конкурентов включать в сравнение. Всего систем существует много, из них часть не универсальны, часть мало известных, часть нестабильных, а часть — просто «мутных» (когда нет цен в открытом доступе, плохая документация, не ясно какое требуется оборудование для решения задачи). Планки известности, стабильности и других требований устанавливает тот, кто составляет сравнение. Поэтому, как и в случае с техническими требованиями, «играя» с этими планками можно исключить из сравнения многих. Речь даже не идет обязательно о целенаплавленном исключении, спросите участнков рынка назвать 10 «достойных» систем и вы увидите разные ответы.
• Учитывать либо не учитывать в расчете вспомогательное оборудование (блоки питания, конверторы, повторители). Например, если конкурирующая система включает в комплекте блок питания и подключается к любому дешевому считывателю, то выгодно не включать в расчет по своей системе блоки питания и считыватели.
• Стоимость расширения. Система может стоить дешево, но при добавлении еще 100 сотрудников ее цена резко увеличится, а некоторое оборудование придется заменить.
• Техническая поддержка системы. Она бывает платной. Если у вас платная поддержка, то очевидное желание — не включать стоимость поддержки в ценовое сравнение.

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

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

Александр Рыжов, ar@spnx.ru

P.S.

Записали краткую видео презентацию, я попытался коротко рассказать, почему надо покупать именно наше оборудование.

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

Посмотреть можно тут:
http://www.spnx.ru/docs.php