СКУД. Знать, что хочет заказчик

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

Это уже история, которая на тот момент была реальной, а моноплатные конструкции появились позже и тоже теперь уходят в прошлое, так как на смену им пришли монокристальные

В RS485 вообще нет гарантированной доставки и ничего, люди живут

Это про интерфейс или протоколы?

есть свое готовое решение по подтверждению того что нужно, которое может быть положено поверх UDP.

Колхоз покруче моего анализатора

Альтернативной было бы "не изобретать велосипед" и использовать TCP, но это более тяжело когда контроллеры должны постоянно обмениваться данными друг с другом

Так используйте, не можете сами возьмите готовые решения (есть даже аппаратные)

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

Эти рассуждения нужны для того, чтобы понимать насколько система "в теме" и сможет ли она справиться с поставленными задачами

Лучше смотреть на целевые показатели

Целевые показатели скрывают за собой страшные тайны. Сравним например "Уровни доступа" - одних их 256 на старший контроллер, у других 65535 на ситему (так в описании написано), но рассмотрим детально -

1. 256 уровней можно назначить на один считыватель или несколько, потом собрать их в глобальный и назначить несколько глобальных уровней на одну карту
2. 65535 уровней на систему - в каждый уровень можно собрать один или несколько считывателей, но на одну карту можно назначить только один из 65535

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

>; Эти рассуждения нужны для того, чтобы понимать насколько система "в теме" и сможет ли она справиться с поставленными задачами

Как вам поможет знание использует система UDP или TCP в понимании справится ли она с задачами? :) Абсолютно никак

>; Сравним например "Уровни доступа"

Конечно согласен что разные СКУД практически невозможно сравнить по функционалу из-за вот этого обилия нюансов во всем.

Эти нюансы функционала можно и нужно обсуждать, а на чем писать софт и какой протокол использовать - пусть решают программисты.

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

Это не так. В каждом Вашем утверждении - не так!

Все так...

UDP - User Datagram Protocol - это протокол. Он даже не содержит IP адреса ни отправителя, ни получателя, и вызывать какие-то штормы не может в принципе (см. рисунок п.2).

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

для организации рассылки UDP другим адресатам протокол UDP "заворачивают в протокол IP

В контексте указанного выше сообщения его надо рассматривать, как законченный продукт и детализировать в данном случае, что во что обернуто бессмыслено, так как врядли какая-то система будет использовать UDP без места назначения

И порождается сетевой шторм не протоколами (любыми!), а либо активным коммуникационным оборудованием, либо неправильной организацией самой локальной сети, либо либо умышленными действиями.

Вот именно - речь как раз об этом, зачем мне как инсталлятору зная о данных проблемах создавать себе лишние проблемы? Но к сожалению здесь не указана еще одна основная проблема - производитель системы: "как он это сделал - ему типа виднее как надо". Под это подходит как раз приведенный Вами лог - зачем по UDP отправлять запрос и получать ответ на сервер, когда есть TCP, исходя из этого можно смело забыть про автономный режим работы контроллеров - сообщения ГАРАНТИРОВАНО будут доставлены при восстановлении связи

UDP - инструмент, а не самоцель.

Основаня цель к чему я все это - инструмент в кривых руках....и в основном не инсталлятора с пользователем, а производителя!!!

P.S.Касательно приведенных логов мне сложно, что-то сказать, так как к сожалению недостаточно информации, но уже есть два вопроса:

1. Почему сервер с оборудованием для получения сообщений использует UDP?
2. И зачем оборудование отправляет запрос на сервер (опять же по UDP) "Доступ разрешен"?

Как вам поможет знание использует система UDP или TCP в понимании справится ли она с задачами? :) Абсолютно никак

Это не я развел курсы по углубленному изучению, но я описал в своем посту выше....

Почему сервер с оборудованием для получения сообщений использует UDP?

Ну тут видимо даже я (не производитель и не пользователь) могу догадаться зачем:

- да затем что бы в очередной раз "сэкономить" и посылать поверх UDP (т.е. сделав из него собственный транспорт над транспортом IP) 485 протокол в том неизменном виде, как оно есть:

RS-485: послал команду - жди получение ответа о приеме.

Т.е. сначала выкрикнуть во всю глотку стоя на одном конце заполненного перрона 48 байт в UDP/IP,

Ну а затем, стоя опять на том же самом перроне - слушать во все уши - как тебе кто-то что-то опять же в 48 байт UDP/IP - может быть и кВитанЁт в ответ (а может быть и нет).

:((

Раз заговорили про шторм, то хочется озвучить еще одну проблему, опять же - потому что "производитель":

Программисты не утруждают себя сложными реализациями и при написании кода для контроллеров используют прерывания. Берем контроллер и начинаем генерировать на порт поднесение карты с определенной частотой, параллельно начинаем подавать на дополнительные входы управляющие сигналы (особенно я люблю порт для противопожарного открытия дверей) и наблюдаем за поведением контроллера, обычно мы видим - контроллер начинает выплевывать в сеть бесперывно сообщения по указанному выше входу, что в лучшем случае ведет к задержке отправки сообщения на сервер или реакции контроллера, в худшем потере карты или падению сети (особенно на 485). Попадались такие системы, где недовернутая вертушка (по-моему это уж совсем безобразие) напрочь убивала систему

Интересная тут у вас беседа. Ага. Про КПВ (периметральный антипассбек) обмолвились.

Ребята я вам сейчас одну вещь как конечник скажу – как оказалось, нам этот антипассбек абсолютно не нужен. Более того, в ряде случаев вреден, особенно на больших предприятиях имеющих территориально удалённые площадки, как в нашем случае.

Поясню – при наличии массового захода/выхода людей через множество(>;10) ТД, зачастую система не успевает корректно отработать. При наличии нескольких удалённых площадок со своей группой контроллеров ( сервер СКУД нах-ся на основной площадке) всё становиться ещё печальней. Не стоит надеяться на эзернет и думать, что он будет всегда. Таким образом, при пропадании/падении сети мы рискуем вызвать не просто мелкие неприятности, но вполне серьёзный коллапс. Серьёзные СКУД на основании данных которых формируется табель УРВ должны быть высоконадёжными.

Вы хотите ЗНАТЬ - что ещё хочет заказчик?

Заказчик хочет, чтобы контроллеры были в корпусе на DIN рейку!

Раз уж, они идут без БП, (мотив производителя – какой надо такой БП и поставите) – то пусть, по крайней мере они будут удобны для монтажа. Таким образом, контроллеры СКУД, источники питания, преобразователи, вспомогательное оборудование и промежуточные узлы коммутации будет размещаться в шкафах, установленных в непосредственной близости от ТД. Компактно, технологично, надёжно. Существующие коробки контроллеров СКУД занимают неоправданно больше места:

Это было приемлемо 7 лет назад но неприменимо в нынешних стремлениях к миниатюризации нанатехнологий. С этим надо что-то делать.

Ребята я вам сейчас одну вещь как конечник скажу – как оказалось, нам этот антипассбек абсолютно не нужен.

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

Поясню – при наличии массового захода/выхода людей через множество(>;;10) ТД, зачастую система не успевает корректно отработать.

Отечественные не могут - особенно линейные

При наличии нескольких удалённых площадок со своей группой контроллеров ( сервер СКУД нах-ся на основной площадке) всё становиться ещё печальней

Существующие коробки контроллеров СКУД занимают неоправданно больше места

У Парсека, Русгарда и т.д. есть корпуса на DIN рейку, для нас например это не особая проблема - мы делаем так:

Программисты не утруждают себя сложными реализациями и при написании кода для контроллеров используют прерывания.

А это как мне катца - как раз и есть проблема "экономии и снижение цены" при унификации и модульности в написании кода - а-ля блочно-модульный телевизор, причем не 2 или 3-УСЦТ, и даже не УПИМ-ЦТ, - а три отдельных блока БРК-2, БР-1 и БЦ плюсом отдельный БП от УЛПЦТ завязанные меж собой через 100% пассивный бок коммутации.

;) Дешево и сердито.

Берем контроллер и начинаем генерировать на порт поднесение карты с определенной частотой,

Опять же как лично катца мне - нехватка вычислительных ресурсов и частот работы тех "PIC" контроллерах в "налуженных шнягах" (здраствуюй любимая "экономия") есть вторая проблема почему даже такие монстры как Болид в своих С2000-Ethernet-ах при преобразовании и передачи своего 19 кбит-ного запросно-адресного 485 по сей день лепят 10 мбит-ный UDP.

:(