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

У кого = есть ? У = Рыжова ?! :) Нема такого- ПИКавода, чтоб портировал на ARMе = RTOS ...)))

не могу навести = фокус на аппаратную часть сей = СКАЗКИ

платформу-аля-апполо с RTOS на борту + линукс + мной любимая ассиметричная архитектура ХАРД

Рискуешь . :) Щаас приползёт = Рыжов, и расскажет нам-за-ваш-алкотестер ...)))

)))

Апполо ?! :) Забудь ...))) Я пройдусь по сей теме = импортзамещение .

Все по аналогии с Cisco и уже давно )))

Как-то неловко что меня тут постоянно упоминают зачем-то, я бы со своей стороны с удовольствием пообсуждал что-нибудь по-существу, в т.ч.:

1) В каких терминах могла бы программироваться пользователем логика работы контроллера СКУД?

На SCADA я абсолютно не покушаюсь на обозримое будущее (вместо - интеграция), но и СКУД сам дает много простора для кастомизации. Например, какой-нибудь рукав, по которому машины друг на встречу другу ездят, светофоры тут же и пр.

Предположим надо выбрать что-то одно (ответить "сделай пятью способами на выбор" каждый может).

IEC 61131-3 FBD? или что?

в каких системах вам нравится как это сделано?

2) Какие должны быть правила работы глобального антипассбека при прямом обмене данными между контроллерами?

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

Кто из них и в какой степени должен ослабить контроль?

Сравнивать ЦИСКО VS АППОЛО

Я и не собирался сравнивать - я про то, что поддержим отечественного производителя https://www.cisco.com/c/m/ru_ru/local-manufacturing/index.html

Что есть у апполо, что-нам = не доступно ?! - могу поделиться

Ящик за 20-ть тыр ??? - ящик как раз не аполловский)))

Как-то неловко что меня тут постоянно упоминают зачем-то

Вроде это не ругательство...

На SCADA я абсолютно не покушаюсь на обозримое будущее

и не надо, лучше закончить начатое....

ответить "сделай пятью способами на выбор" каждый может

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

В плоских системах КПВ на 99% гибнет здесь - "сервер системы", в объемных - грани почти равнозначны, только сервер исключен (совсем исключен со своими 99%!!!)

Кто из них и в какой степени должен ослабить контроль?

Я уже описывал, что стараюсь делить на рубежи, причем аппаратно, посмотрите еще раз внимательно http://secuteck.ru/articles2/security-director/raspredelennaya-skud-i-urv-na-gornodobyvayuschih-predpriyatiyah/

а если умеете читать между строк, то найдете много полезного для себя материала, правда в статье к сожалению только часть материала представленного на All-over-IP 2015

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

ну вот я и задаю,

1) где по вашему мнению хорошо сделано описание логики?

2) в каких терминах ее описывать было бы вообще идеально?

бренды тут по-моему упоминаются без особых ограничений. если нет - плохо для тут, нам нужен другой форум.

>; В плоских системах КПВ в 99% гибнет здесь - сервер системы, в объемных - грани почти равнозначны, только сервер исключен (совсем исключен со своими 99%!!!)

я умею понимать что: есть N контроллеров, они в лучшем случае все на связи, есть N*(N-1) связей когда все хорошо. Но наступает момент, когда кто-то из контроллеров понимает, что связей у него лично уже не (N-1), а меньше. Как этот контроллер должен себя вести? отдельное еще приключение с самим пониманием что связь потеряна, связь восстановлена, все данные синхронизированы.

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

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

блин, к черту этот жанр. если вам есть что сказать, просто скажите.

Для этого я и предлагаю родить стандарт всем вместе - Вам, как производителям и нам, как потребителям.

я умею понимать что: есть N контроллеров, они в лучшем случае все на связи, есть N*(N-1) связей когда все хорошо. Но наступает момент, когда кто-то из контроллеров понимает, что связей у него лично уже не (N-1), а меньше. Как этот контроллер должен себя вести? отдельное еще приключение с самим пониманием что связь потеряна, связь восстановлена, все данные синхронизированы

Это Александр Вы судите по себе, а раз

бренды тут по-моему упоминаются без особых ограничений. если нет - плохо для тут, нам нужен другой форум

то у Аполло таких проблем нет - все существующие проблемы из-за нехватки или полного отсутствия знаний

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

Коммутация всегда сводится на один главный и все равно перерастает в дерево. Управляющий контроллер есть всегда и не важно что это за модель системы, в плоской это в определенный период времени, а в объемной постоянно. Главный контроллер берет на себя проблему осутсвия связи с сервером, которая обычно возникает при обновлении используемых продуктов, а если еще использовать "подписки", то заплатки придеться ставить постоянно....

блин, к черту этот жанр. если вам есть что сказать, просто скажите.

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

Конструктивного разговора по технологиям не получается ;)

По методам программирования логики вы просто ничего не предложили.

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

>; А тренд-2017 , софт = бесплатный ...)))

Я тут с вами не согласен. На мой взгляд тренды такие:

- Все превращается в софт. Решает софт (в т.ч. встроенный). Железо же "у всех одинаковое" (утрирую).

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

При таких вводных я бы не стал ждать что софт станет бесплатным.

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