Перейти к содержанию
    

Прошу покритиковать идею УД.

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

Холивары

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

 

Проблемы

  • Пропускная способность каналов связи. Если иметь толстый канал то можно пустить всю информацию через этот канал. Интернет, Аудио, звук, управление.
  • Надежность каналов связи. Обрыв канала в одном месте обеспечивает полную работоспособность системы.
  • Жесткий realtime. Обсуждалось. Появлялись цифры около 20мс. Была информация на счет EtherCat что это очень realtime но канал должен быть выделен только под него.
  • Масштабируемость системы.
  • Устойчивость функциональности к аварии части системы. Падение любого элемента системы не приводит к ступору.
  • Возможность выхода вверх (облачные сервисы). Закрытие канала WAN не сказывается на функционале системы локально.

Подумав над проблемами появилась идея создать что-то на подобии backbone сети с элементами которые обеспечивают работу и постараться использовать стандартные решения.

Если присмотреться то похожие проблемы есть на цифровых подстанциях 61850. Там есть и толстый канал (process bus) с выходом вверх (goose protocol) и realtime(sv protocol) (передача до 4000 измерений на секунду от одного устройства). Также применяется технология G.8032v2 ERPS (Ethernet Ring Protection Switching ) . Так что первое что пришло в голову использовать в качестве основного канала связи 1G ETH и закольцовать в ринг. Элементом этого кольца будет Нод. Нод это такой автономный ПЛК со встроенным коммутатором на 3 порта 1G . Основные функции нода, это отработка например загруженной программы согласно с IEC 61131-3 стандартом. Обмен информации с соседними нодами если переменные выходят за пределы одного нода (sv protocol типа iec61850_9_2_LE ) и обслуживание ринга. Так как нод содержит коммутатор то без проблем можно подключить или компьютер или камеру. Это будет единая толстая бесперебойная транковая сеть в УД. Разделение vlan-ами позволяет отделить интернет от управления. С нодами похожее решение есть в KNX, там встречаются такие ноды что с одной стороны обслуживают магистраль KNX а также имеют по несколько входов/выходов а с другой имеют внутреннюю магистраль для подключения специфических актеров/сенсоров.

Схема будет выглядеть приблизительно как на рисунке.

1.thumb.png.6f5cd9f77ed458341cc82fd108f82897.png

2.png.10655adf9ecca186eca7bfaa99509dd6.png

Т.е. получается, что основная разводка проводов это в основном качественный кабель для сети CAT 5 / 6 и питание. Если поставить ноды в одном месте то будет система централизованная и эти ноды будут выглядеть как один ПЛК. Если разнести модули по этажам/ помещениям получается система децентрализованная. Если модуль упадет то перестанет работать только этот модуль и часть функционала с внешними состояниями. В качестве Eadge device можно использовать PC с OpenHUB. Если проблема с расстоянием можно использовать fiber (например видео домофон во дворе). Почему 1G? Ну в основном чтобы можно было гонять несколько потоков видео и работать с интернетом через эту сеть. Используя QoS i vlan можно управлять приоритетами и достигнуть realtime для канала управления даже с загруженной сетью. Это в общих чертах. Ну сколько бы это стоило? Идея появилась после предварительной грубой оценки цены. Из тяжелых элементов это шустрый MCU + коммутатор + питание.

На пример rt1064 + KSZ9897 + AC/DC 5W ~ 40$ + остальная часть 40$ в сумме такой нод должен получится около 80. Ну и конечно куча работы. Хотя с большой частью технологий я работал но и так всего самому не переделать. Есть идеи и наработки. Я сторонник открытых решений так что, если идея чего то стоит, то попробую более качественно описать и прозондировать на https://hackaday.io/  и запустить на https://www.crowdsupply.com/crowdfunding .

Хотелось бы услышать мнение спецов особенно AlexandrY i syoma ну и конечно всех остальных.

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я думал об идее ноды с тремя Eth портами. 3 Eth порта должны работать в режиме простого свича, к одному из которых (внутреннему) подключался бы локальный I/O микроконтроллер. В качестве протокола - MQTT. Зачем лепить всю эту сложность IEC61850?

Питание отдельно не надо - надо PoE. Желательно, чтобы когда устройство обесточивалось, ETH1 замыкался бы напрямую на ETH2 и остальная сеть работала дальше.

 

Тогда всякие Ring не надо. Просто от центрального коммутатора прокидываешь витую пару по комнатам, а в самих комнатах включаешь все ноды последовательно друг за другом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, framer said:

Т.е. получается, что основная разводка проводов это в основном качественный кабель для сети CAT 5 / 6 и питание. 

На пример rt1064 + KSZ9897 + AC/DC 5W ~ 40$ + остальная часть 40$ в сумме такой нод должен получится около 80.

Вау! 5-портовый гигабитный свитч с полной докой. В стоках полно.
Тогда конечно стоит делать, даже нет вопросов. 

Кста, у меня гигабитный интернет из подвала где-то 20 метров идет в самом дешевом UTP-5 без экрана. 
И нормально работает. 
Решение может быть даже дешевле чем кажется.
Эт конец  KNX-ишникам. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

48 minutes ago, AlexandrY said:

Вау! 5-портовый гигабитный свитч с полной докой. В стоках полно.

Где там  5-портовый гигабитный свитч с полной докой? не нашел.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 hours ago, syoma said:

Я думал об идее ноды с тремя Eth портами. 3 Eth порта должны работать в режиме простого свича, к одному из которых (внутреннему) подключался бы локальный I/O микроконтроллер. В качестве протокола - MQTT. Зачем лепить всю эту сложность IEC61850?

Питание отдельно не надо - надо PoE. Желательно, чтобы когда устройство обесточивалось, ETH1 замыкался бы напрямую на ETH2 и остальная сеть работала дальше.

 

Тогда всякие Ring не надо. Просто от центрального коммутатора прокидываешь витую пару по комнатам, а в самих комнатах включаешь все ноды последовательно друг за другом.

С POE интересно. Беру идею к анализу. Проблема будет только с тем что даже в режиме пассивного PD надо будет делать конвертер PD na PSE. По простому запитать и перебросить на другой порт не получится, Но вопрос с питанием стоит рассмотреть. Интересно мнение на счёт целесообразности применения РИНГ. Этот стандарт очень сильно променяют сетевеки на уровне L2. У меня была практика реализации этого протокола на AVR32 с похожим коммутатором. Протокол очень хорошо ложится в такие коммутаторы. Там основная проблема в возможности блокировки портов по MAC и очистки MAC таблиц при определённых условиях переключения направления. Что мы с рингом имеем, Если обрывается соединение в любой точке перебоя практически не видно и все узлы работают и видят друг друга. Утеря пакетов есть но она не превышает 50 мс. На конкретном примере. Скажем по схеме выше Нод 5 и 6 находятся на втором этаже. Если в ринге происходит обрыв между первым и вторым этажом в одном месте то для пользователей и управления это даже не заметно. На втором этаже работает интернет и все функции УД. Типа этого. 

ring.thumb.png.4c245985740a082f252e53b33a829bb0.png

 

Если такая функциональность избыточная то наверное не стоит запариваться. Хотя функции коммутатора оставить надо а следовательно реализация ринга это чисто программная фича . А функцию коммутатора следовало бы оставить потому что поток транковый с vlan и приоритетами. Я это позже опишу как будет выглядеть поток данных и аварии если интересно. Тут фишка такая что не все заминались сетями а из этого можно много чего вытянуть. А интересно как общая идея использовать толстый канал для всех подсистем? На счёт IEC61850 то это как показатель не обязательно его использовать но обратить внимание стоит. Можно даже руками потрогать. Об этом тоже могу написать. Тут вопрос следующий . Для realtime обмена данными лучше использовать уровень L2 чем L3. Как соберу мысли то напишу.

3 hours ago, AlexandrY said:

Вау! 5-портовый гигабитный свитч с полной докой. В стоках полно.
Тогда конечно стоит делать, даже нет вопросов. 

Кста, у меня гигабитный интернет из подвала где-то 20 метров идет в самом дешевом UTP-5 без экрана. 
И нормально работает. 
Решение может быть даже дешевле чем кажется.
Эт конец  KNX-ишникам. 

Да это одно из решений. В похожих ценах есть много решений. Есть тяжёлые клиенты но пробивные. Я как раз имел дело с Marvell. У них конечно мох и болото. Есть варианты с SERDES. Можно ставить каналы под SFP. Если постараться то можно достать. Ну и Microsemi pod Microchip легла и открылась. В общем выбор есть.

 

2 hours ago, Myron said:

Где там  5-портовый гигабитный свитч с полной докой? не нашел.

https://www.microchip.com/wwwproducts/en/KSZ9897

http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9897S-Data-Sheet-DS00002394C.pdf

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, framer said:

Интересно мнение на счёт целесообразности применения РИНГ. Этот стандарт очень сильно променяют сетевеки на уровне L2. 

Стоит ли запариваться с РИНГ (не знаю что это такое) если KSZ9897S  поддерживает Rapid spanning tree protocol и Multiple spanning tree protocol? 
Т.е. можете хоть все 4-е оставшихся порта занять дублирующими кабелями и эти протоколы все равно все разрулят в лучший вариант топологии. 
Т.е. в несколько раз надежней РИНГ (если судить по вашей схеме)

С питанием я бы сделал аккумуляторное, а не PoE. 
Система стала бы гораздо живучей.
Эти UTP кабеля как только не кромсают, побоялся бы я делать PoE.
Ставку делать на экономичность и микроразмеры. 
Иначе глазом не успеете моргнуть как вашу идею захватят вот такие кубики - https://habr.com/ru/company/selectel/blog/525250/ 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Плохо. Цепь - неудобная топология для размещения. К тому же, в доме, как ни крути, нужны свичи. Хотя бы для вайфая. От них провести 10 метров кабеля будет еще и дешевле этого изврата. Не говоря уж о том, что для 90% устройств не нужен никакой жесткий реалтайм, и всё работает на вайфае, или каком-ниубдь еще радио с батарейками.

Изменено пользователем rkit

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

12 minutes ago, rkit said:

Плохо. Цепь - неудобная топология для размещения. К тому же, в доме, как ни крути, нужны свичи. Хотя бы для вайфая. От них провести 10 метров кабеля будет еще и дешевле этого изврата. Не говоря уж о том, что в 90% случаев не нужен никакой жесткий реалтайм, и всё работает на вайфае, или каком-ниубдь еще радио с батарейками.

Так KSZ9897 и есть 5-и портовый свитчер.
Больше не нужны никакие сторонние свитчеры. 
Более того, поскольку он поддерживает кучу MIB счетчиков 

Quote

- MIB counters for fully-compliant statistics gathering 34 counters per port

то он становится идеальным узлом управляемой по SNMP сети. 
Эт вооще новый уровень управляемости и диагностики.
SNMP менеджеры покажут вам проблемы которые еще не начались.
И этих менеджеров бесплатных - море:  https://www.dnsstuff.com/snmp-monitoring-tools  
Никакой дешевый домашний роутер такого сервиса не даст. 

А RF или BT чип занимает всего 1 см^2 на плате. Так что о такой мелочевке не стоит даже вести речь.
Она будет по умолчанию или как опция, это уже не важно. 

WiFi неэкономичный в плане потребления, и может встретить жесткое нежелание заказчика. 
Хотя WiFi модуль это тож не больше 2 см^2 на плате. Можно поставить как опцию. Тем более что у RT1064 для него найдется отдельный SDIO. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

15 minutes ago, AlexandrY said:

Так KSZ9897 и есть 5-и портовый свитчер.

Да, но в доме он уже есть. Не нужно платить за еще четыре шутки лишних с жизанутой топологией сети.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, rkit said:

Да, но в доме он уже есть. Не нужно платить за еще четыре шутки лишних с жизанутой топологией сети.

То вам свичеры нужны, то они уже есть. 
Не важно что там у вас есть, можете выкинуть если так будет легче. :biggrin:
Каких только лишних побрякушек не покупают юзеры пока ищут лучшее решение.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

28.10.2020 в 16:57, framer сказал:
  • Пропускная способность каналов связи. Если иметь толстый канал то можно пустить всю информацию через этот канал. Интернет, Аудио, звук, управление.
  • Надежность каналов связи. Обрыв канала в одном месте обеспечивает полную работоспособность системы.
  • Жесткий realtime. Обсуждалось. Появлялись цифры около 20мс. Была информация на счет EtherCat что это очень realtime но канал должен быть выделен только под него.
  • Масштабируемость системы.
  • Устойчивость функциональности к аварии части системы. Падение любого элемента системы не приводит к ступору.
  • Возможность выхода вверх (облачные сервисы). Закрытие канала WAN не сказывается на функционале системы локально.

Вот как всегда в данных темах смешалось все в кучу...  Зачем толстые каналы? Для инета, видео и пр - да хорошо, но зачем для систем управления? 

Надежность? Нет ничего надежнее провода. Обрывы? Вы серьезно? У вас сейсмика большая или прокладка кабеля на отвали? Тогда кто его будет рвать? У вас часто электропроводка в доме рвется? Смешно же...

Реалтайм? Особенно жесткий? Э то что, система управления станком ЧПУ? Тогда на кой она нужна, человек управляет чем-то, время реакции человека какое, 1сек до 100мсек, куда быстрее-то...

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

Устойчивость к "падениям" - тут только резервирование, тема не простая, в 2х словах не объяснить.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 hours ago, mantech said:

Вот как всегда в данных темах смешалось все в кучу...  Зачем толстые каналы? Для инета, видео и пр - да хорошо, но зачем для систем управления? 

 

Был один клиент. Обьект был большой. За основу был использован KNX от GIRA . Проблемы начались когда клиент хотел, чтобы на панелях интегрировать видеодомофон с системой видеонаблюдения и управления. Хотел поговорить через домофон с человеком перед калиткой. Открыть гараж или калитку, Покрутить камерой видеонаблюдения, Хотел чтобы все регистрировалось. Дубовый и дорогой homeserver https://partner.gira.com/en/systeme/knx-system/knx-produkte/server/homeserver.html от Gиры мог показывать только картинки с частотой отрисовки 1 секунду. Но надо было еще как то эти картинки с системы видеорекордера достать, Отдельно канал KNX, отдельно сеть ETH для панелей. Отдельно видеорекордер. Надо было везде тянуть свои кабели. Для видеонаблюдения свои для управления свои для видеодомофона свои. Ну если принять, что этот весь поток данных идёт одним каналом то хотя бы появляется возможность интеграции. Ещё была сигнализация периметра. Ну в данном случае можно было бы подключить через такой Нод IP камеру с PTZ для видеонаблюдения, IP камеру с микрофоном и динамиком как видеодомофон. Входа/выхода нода использовать для открытия электрозамка в калитке и кнопку вызова/звонка. Вот под такой сценарий по моему Нод и подходит. Поэтому и появилась идея одного канала.

3 hours ago, syoma said:

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

Да согласен. С рингом перебор. RSTP как раз то, что надо и топология сети получается гибкая.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, framer сказал:

Отдельно канал KNX, отдельно сеть ETH для панелей.

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

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

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...