партнерский раздел
ФорумЭксплуатацияИнтеграция оборудования Болид в стороннюю SCADA

Эксплуатация » Интеграция оборудования Болид в стороннюю SCADA

Стоит задача передавать данные с системы пожаротушения в БД сторонней SCADA. Для себя видим два варианта:
1. подключить С200-ПП, к нему потом прикрутить какой нибудь преобразователь протоколов( или контроллер), чтоб из modbus RTU конвертировал в общедоступные(лучше МЭК 60870-5-104);
2. установить Орион Про (или только её модуль управления) на сервер, где крутится SCADA и передавать данные с помощью XML-RPC. ОРС сервер не предлагайте по причине неприятия его  руководителем асушки (видимо опыт с частыми глюками). В связи с эти вопросы:

  1. Наличие связи через ПИ-ГР допускает одновременный опрос полевых устройств через ПИ-ГР и С2000М? (см. фрагмент схемы)
  2. Может ли «Модуль управления ИСО Орион» быть подключен к пульту С2000 через «Преобразователь интерфейсов RS-485/RS-232 в Ethernet С2000-Ethernet»?
  3. Возможна ли одновременная работа через С2000-Ethernet (или RS-485) с одним и тем же пультом С2000 1) компьютера с ПО «Модуль управления ИСО Орион» и 2) компьютера с ПО «Orion-Prog» (и/или с другим фирменным конфигурационным ПО)?
  4. Возможна ли одновременная работа двух компьютеров с одним и тем же пультом С2000 через С2000-Ethernet (или RS-485)?
  5. Возможна ли одновременная работа 1) ПО «Модуль управления ИСО Орион» и 2) ПО «Orion-Prog» (и/или другого фирменного конфигурационного ПО) с одного компьютера через С2000-Ethernet (или преобразователь интерфейса RS232/485) с одним и тем же пультом С2000? (информации на сайте Болид не нашел, может плохо искал).

Уважаемая тех поддержка подскажите по 2 варианту. с использованием модуля управления.
 

9 месяцев назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

7 ответов

Доброго дня, Андрей Тадеушевич.
Пока спциалисты по п.2 думают, и запрашивают у Вас информацию по системе,
по п.1, а именно С2000-ПП и по системе в целом у меня несколько вопросов к Вам:
1) Чем не стандартен для Вас Modbus RTU? он почти в каждой SCADA системе есть либо сразу, либо скадовским ОРС сервером ( которые даже сторонние есть) Заранее хочется уточнить, что преобразование протоколов это весьма сложная для реализации процедура, особенно если протоколы разные по сути.
2) Соответственно что у Вас за SCADA  система куда Вы хотите передавать информацию с системы пожаротушения? (для понимания возможностей интеграции)
3) Что именно Вы хотите передавать в свою SCADA систему ( ответ "ВСЁ" не годится. Ну то-есть годится конечно, но Важно понимать что для системы Пожаротушения Самое важное это вовремя сработать, и вовремя всё знать, а вопрос передачи данных на другую сторону это самый низкий по приоритету вопрос - и в самом крайнем случае Очень большой системы у Вас будут достаточно долго приходить данные в Вашу систему - и на ответ "ВСЁ" надо добавить ещё "за какое время". Потом можно взять эти два параметра, и посчитать за какое время Вы получите реакцию - в случае с С2000-ПП у него канал к Пульту С2000-М на скорости 9600, и каждый запрос может генерировать больше 3-х команд обмена информацией с пультом для получения данных. ну и надо будет учесть что у пульта на это скорости есть ещё большая куча дел - а именно управление системой и опрос датчиков)
Поэтому Важно знать Что именно, и Для чего Вы хотите получать от системы Пожаротушения,
4) Размер и состав системы пожаротушения? ( это важно для понимания сколько С2000-ПП Вам вообще нужно)
5) Удовлетворит ли вас Мастерскада 4Д - благо она есть на борту ПЛК М3000-Т Инсат ( у которого только 485е интерфейсы) в качестве преобразователя протоколов. В версии 1.1 или Вы опдождёте версии 1.2?

По пунктам 2. я за коллег не отвечу, но я бы на их месте запросил схему - к примеру что значит п.1 - куда Вы хотите ПИ-ГР поставить? к пульту или к оокнечным устройствам? если к оконечным устройствам - тогда один ответ, с режимами работы пульта. При этом Важно понимать что в системе Орион на линии 485-го интерфейса два мастер устройства не уживутся. когда Вы опрашиваете с его помощью Пульт- уже другая история. Ну и про Модуль Интеграции коллеги более развернуто расскажут. Хотя я бы на Вашем месте посмотрел на стоимость АРМ Орион-Про - она говорит о том, что сделать его, АРМ - на сторонней SCADA системе не так то и просто. Правильно сделать его ещё сложнее. И вопрос а не поставить ли на компьютер со SCADA системой АРМ Орион-Про будет, при детальном рассмотрении - возможно самым дешевым вариантом, в случае маленькой системы( и та важен пункт 3 из моих вопросов выше по тексту) .  А уж организвовать у диспетчера два/четыре/восемь монитора/ов с разными окошками в разы дешевле чем писать свой собственный АРМ. Но это уже ответят коллеги. 

 

9 месяцев назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Спасибо за комментарий.. Поясню, нам важно архивировать сигналы (неисправности-все, сработка датчиков- все, неготовность АПТ, пожар) с метками времени от С200М (он же это делает или ПО Орион Про?). В случае с применением С2000ПП, предполагаю, что время будет проставляться либо конвертером RTU в  TCP IP, либо самим сервером SCADA, что не есть хорошо. Такая же проблемма при применении OPC (или всё-таки есть возможность передавать события через ОРС с метками времнеи С2000М?). Для точной увязки времени и рассматриваем вариант с вариантом 2 . (установить Орион Про (или только её модуль управления) на сервер, где крутится SCADA и передавать данные с помощью XML-RPC). Орион Про все равно будем покупать для эксплуатации, но как подключать (вместо или вместе с "модулем управления")пока не понимаем. Узнали по XML- RPC отсюда стр.5  https://bolid.ru/files/373/566/pak_upr.pdf

Отвтеты на Ваши вопросы:
1) RTU не проблемма (кроме меток времени);
2) SCADA будут разные на разных объектах, пока точно не известно какие.И какакя разница, если возможности интеграции будут?
3) неисправности-все, сработка датчиков- все, неготовность АПТ, пожар
4) сейчас только идёт проектирование, промздание 500-600 м2, помещений для сигнализации около 20, направлений водяного ПТ 5
5) Спасибо, за предложение, почитаем подумаем.

8 месяцев 30 дней назад

avatar
Знатоки, кто-нибудь ответит на мои вопросы выше?

Гришкевич Андрей Тадеушевич 8 месяцев 30 дней назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Может кому пригодится.
support ответил следующее:
Модуль управления ИСО "Орион" входит в состав ПО АРМ "Орион ПРО". По сути это тот же модуль Ядро опроса.
То есть стороннее ПО может обращаться к Ядру опроса данного АРМ "Орион ПРО" с помощью XML-RPC и параллельно работать с теми же приборами.
При наличии ПО АРМ "Орион ПРО" покупать Модуль управления ИСО "Орион" не нужно.

8 месяцев 29 дней назад

avatar
Добрый день!

А вот мне только сегодня ответили следующее:
Модуль управления, на который я очень расчитывал, позволяет согласно документации осуществлять сбор информации, управление, подписываться на события. Тоесть делать все, что нужно для работы своего срудства диспетчеризации, например.
Однако! Если установлен АРМ, то да, покупать этот модель не нужно, так как он не будет работать! Т.е. не будет никакой интерграции. Либо-либо.
Если нужно, чтобы был и АРМ и внешняя система, то нужен ТОЛЬКО OPC.
Лично я никогда с ним не работал и не представляю, как подружить OPC сервер с моим ПО, которое в кач-ве интерфейсов поддерживает TCP-UDP-HTTP запросы.

Масликов Виктор Юрьевич 7 месяцев 6 дней назад

Доброго Вам дня, Виктор Юрьевич.
 OPC (аббр. от англ. Open Platform Communications) является де-юро и дэ-факто стандартом для СКАДА систем - систем диспетчерского управления и сбора данных. То-есть если у вас ПО для сбора данных и диспетчерского управления - то оно в первую голову хочет собрать данных с разных систем.  А дэ-факто стандар на эти действия это ОРС. в том либо ином виде.
https://ru.wikipedia.org/wiki/OPC на всякий случай. 


TCP-UDP-HTTP запросы.-это, на всякий случай более сложные в реализации протоколы. Ибо разные производители чего только не напридумывают - как получать по UDP данные. или по тому же Http к примеру есть с десяток примеров разных реализаций интерфейсов передачи данных как post так и get запросами причём оба два в разные стороны (на приём с сервера и передачу на сервер), что само по себе требует программирования для каждой конкретной задачи. ОРС сервер/клиент позволяет сделать интеграцию один раз, и потом просто получать данные.

Горелый Юрий Алексеевич 7 месяцев 6 дней назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Здравствуйте! Я программу пишу не сам, это оболочка, в которой уже реализованы эти протоколы. А работы с OPC в чистом виде нет. Мне проще на ip порт создать соединение и подписываться на события, разбирать их, отправлять запросы в определенной форме. Конечно, было бы идеально иметь какой-то программный шлюз, позволяющий обращаться по TCP к данным на OPC, и также от OPC получать синхронные или асинхронные ответы. 
Например у того же болида есть Модуль управления, который позволил бы мне (но я сам еще не пробовал) посредством этих запросов, описанных в документации, получить как мне сказали все, что приходит в АРМ. То есть и события о сработки датчиков, и по запросу текущие состояния, давать команды управления. Я мог бы эти сведения привязать к своему визуальному интерфейсу. А вот сегодня как узнал, что с АРМ такая связка не заработает очень расстроился, т.к. теперь мне надо многое пересматривать. На объекте стоит АРМ, да и концепция моей работы подразумевает исключительно распределенную систему. Все мое поверх работающих систем.

7 месяцев 6 дней назад

avatar
День добрый, Виктор Юрьевич.
Я правильно понял, что у Вас система с какой-то оболочкой ( Весьма интересно какой)

которая по запрашиваемому функционалу Цитата:

 "...То есть и события о сработки датчиков, и по запросу текущие состояния, давать команды управления..."

То-есть, в том числе управлять системой, которой управляет АРМ Орион?
Да ещё и распределённо? что бы это не означало (а хотелось бы уточнить что это в Вашем понимании значит).

И при этом у неё (Вашей системы) нет встроенного ОРС сервера, а есть Только TCP, UDP и Http -протоколы, которые которые по своей сути не подразумевают на канальном уровне гарантированную доставку команд управления? Этот вопрос Очень Сильно смущает. Особенно если АРМ Орион стоит в части пожарки, а он может так стоять.

Или всё-таки что-то было понято не так, и всё совсем по-другому? Тогда хотелось бы узнать что за оболочка, чтобы попытаться Вам Помочь. Если всё рассказать более пОлно- то вполне возможно есть альтернативные пути. Особенно если ещё понимать Цель, Задачу и размер Системы. Программный шлюз ОРС в TCP и обратно - чтобы это не значило  - можно реализовать на многих скада системах. "чтобы это не значило" = придумать программисту СКАДА системы какой-нибудь простенький протокол поверх tcp и  Методы обмена по TCP (ну либо взять к примеру MODBUS over TCP - что вполне себе TCP, в некотором роде... какого бы вида доступ к хистрым регистрам не происходил и накрутить сверху на протокол методы общения с АРМ-ом)  Можно кстати взять и программный преобразователь ОРС в MODBUS over TCP но Методы передачи данных при этом придётся придумывать Вам самим .

Горелый Юрий Алексеевич 7 месяцев 5 дней назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Юрий Алексеевич, еще раз здравствуйте, и спасибо, что поддерживаете этот диалог.

Секрета что за оболочка нет, это iRidium mobile. Там есть возможность создать на базе MODBUS клиента OPC. Но я с ним еще не работал, и появление этого протокола в системе во-первых её удорожит, во вторых добавит мне проблем с унификацией в будущем. Для меня перспективнее TCP запросы. Мне не кажется развитие MODBUS перспективным в существующих реалиях продвижения iOt, хотя я отдаю себе отчет в его распространенности.

Я понимаю, что управление системой, которой управляет АРМ Орион не найдет отклика ни у одного создателя этой системы, и уж тем более у проверяющей стороны, так как потенциально несет в себе риски её работоспособности, однако этот аспект я выношу за скобки и оставляю на волю Заказчика. Если он хочет иметь родные панели управления в своем современном доме - это его право. Причем сразу же идентифицирующую эту систему. Если он хочет для всех других систем иметь одно приложение, а для ОПС отдельное (не знаю, правда, есть ли мобильная версия Орион) - опять же выбор Заказчика.

В термин "распределенная система" я вкладываю архитектуру, которая подразумевает наличие и независимую, самодостаточную работу всех её элементов. Однако при этом появляется новая оболочка, способная управлять этими системами, получать данные с них, обрабатывать, реализовывать алгоритмы, необходимые Заказчику, предоставляющая возможность обозревать интересующие аспекты в удобном именно ему виде, сопрягать разные системы.

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

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

Что касается гарантированной доставки, то UDP - да, не дает гарантии, TCP дает.
https://ru.wikipedia.org/wiki/Transmission_Control_Protocol
Кроме того, в более менее приличных системах, и даже не очень приличных, таких как WiFi реле китайских, куда шлются команды по UDP, реализован функционал ответа - реакции на команду. Например, отправив команду  "включить реле", получаешь тут же ответ о состоянии этого реле - реле включено. Если в этот момент еще от подобного устройства пришло сообщение, то оно тоже доходит и простым парсингом я могу разобраться о чем пришла информация, а о чем нет. И повторить свою команду, предварительно запросив текущее состояние..
Понимаете, все зависит от конкретной реализации, потому все в работу поступает через тесты, т.к. они выявляют косяки и недоделки в любых маркетиногово раскрасивых продуктах. Порой элементарные вещи не реализованы, задумки выполнены на "отвяжись" скажем так, только для буклета, нивелируя всю работу над функционалом интеграции. Тоже не хотелось бы вступать в дискуссию почему так, кто виноват и доколе этот бардак будет продолжаться. Он есть и это данность.

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

7 месяцев 5 дней назад

avatar
День добрый, Виктор Юрьевич.

По второй части Вашего вопроса-Ответа:
Цитата :
"Что касается гарантированной доставки, то UDP - да, не дает гарантии, TCP дает."


Мой ответ прост -
К сожалению TCP это " транспортный уровень сетевой модели ".
он не даёт Прикладной, сеансовый или представительский уровень.
(Это имеет значение в том, что сейчас у Вас нет понимания того для чего и как интегрироваться и это проблема)
Говоря развёрнутей:

То-есть гарантировать доставку он не может. он может гарантировать доставку пакетов.
Для примеров - в протоколах на базе сетей RS485 есть такой же подсчёт контрольной суммы, не боьлше не меньше. Иногда шифрованный иногда нет.
Вот в протоколах ОПС - он во-первых шифрован. а во-вторых имеет гарантию доставки сообщений, уже на Прикладном, сеансовом или представительском уровне. 
Дальнейшие рассуждения про китайские реле лучше оставить за скобками - здесь нет улыбающихся смайликов, чтобы посмеяться и пошутить. Даже оборудование Siemens не всегда сертифицированно для работы с ОРС, не то, чтобы даже думать о китайских реле. Если коротко - то Методы гарантированности доставки сообщений координально другие, развивать здесь теорию и обучение я не буду.
 

Горелый Юрий Алексеевич 7 месяцев 5 дней назад

День добрый,  Виктор Юрьевич!
отвечая на первую часть Вашего вопроса
"Секрета что за оболочка нет, это iRidium mobile. Там есть возможность создать на базе MODBUS клиента OPC. Но я с ним еще не работал, и появление этого протокола в системе во-первых её удорожит, во вторых добавит мне проблем с унификацией в будущем. Для меня перспективнее TCP запросы. Мне не кажется развитие MODBUS перспективным в существующих реалиях продвижения iOt, хотя я отдаю себе отчет в его распространенности.

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


Отвечаю по частям:

1) ""Секрета что за оболочка нет, это iRidium mobile." -
Ответ:  Это хорошо, эти ребята нам друзья и Болид с ними пытается наладить общение - оболочка хорошая. Что не отменяет проблем интеграции, просто констатация - для своих задач вполне себе Хороший продукт.

2) "Там есть возможность создать на базе MODBUS клиента OPC. Но я с ним еще не работал, и появление этого протокола в системе во-первых её удорожит, во вторых добавит мне проблем с унификацией в будущем. Для меня перспективнее TCP запросы. Мне не кажется развитие MODBUS перспективным в существующих реалиях продвижения iOt, хотя я отдаю себе отчет в его распространенности."

Ответ: 2.1 Откидываем в вопросе последнее предложение как не имеющее смысла к работе, это субъективное мнение. С которым можно поспорить, имея как исходные данные описываемые Вами понимание что такое есть протокол как смысл.
          2.2 Вопрос "Там есть возможность создать на базе MODBUS клиента OPC "
ответ - Её и стоит использовать - один из вариантов интеграции.
          2.3 Вопрос " я с ним еще не работал, и появление этого протокола в системе во-первых её удорожит, во вторых добавит мне проблем с унификацией в будущем"
          Ответ - Поддержка нами какого то стороннего протокола ещё более удорожит для вас решение и добавит дополнительных проблем. Более того, поддержка Болидом какого-то Доплнительного протокола накладывает на последний Большое количество ограничений в результате чего повышается сложность его обработки и снижается количество передаваемой информации.
Посему у Вас простой выбор и Вы его подтверждаете
- либо решение дороже и вы не углубляетесь в его изучение, (2.3.1)
- либо решение дешевое - но вы вынуждены в нём разбираться досканально.(2.3.2)

Мы же предоставляем Вам самим сделать выбор. У Болида Есть и первый и второй вариант решения Вашего вопроса ((2.3.1) и (2.3.2)).
Пытаться сделать третий вариант, когда Вы не попробовали не одного - по меньшей мере глупо.
  
             2.4 Вопрос "Для меня перспективнее TCP запросы""
Ответ :Перспектива ТСР запросов - это лишенное смысла предложение.

То-есть давайте допустим что есть какой-то абстрактный прибор. И в этом абстрактном приборе осуществляеться шифрование и через гарантированность доставки сообщений клиенту. и всё это происходит на транспортном кровне TCP. На пальцах это означает что один прибор шлёт другому в определённое время параметр. скажем @GHJHJGKH@ который зашифрован модулем шифрования. В другое время это значение будет другое. И допустим что для расшифровки данного параметра надо использовать Только модуль шифрования, потому как расшифровка методом обработки значения на ПК невозможна - то-есть расшифровка на ПК произойдёт за время, которое гарантированно больше времени жизни данного сообщения. и расшифровать и гарантировать связь можно только вторым таким блоком дешифрации.
Это я к чему-  к тому что и там возможет TCP. Только Вам от того, что канальный уровень - это TCP ни тепло не холодно, если Вы не можете реализовать Прокотол передачи данных на пришладном уровне.




Вопрос 2.5 "В термин "распределенная система" я вкладываю архитектуру, которая подразумевает наличие и независимую, самодостаточную работу всех её элементов. Однако при этом появляется новая оболочка, способная управлять этими системами, получать данные с них, обрабатывать, реализовывать алгоритмы, необходимые Заказчику, предоставляющая возможность обозревать интересующие аспекты в удобном именно ему виде, сопрягать разные системы." 
Ответ : Про Управление Пожарными системами на иридиуме это даже не смешно. Я их реализацию и в исходных кодах не видел - только со стороны наблюдал на выставке. Сделано хорошо, и может быть даже если они откроют все исходные коды - у меня будет мало возможностей придраться ко всей системе... Но это лирика. а факт один - отсутствие сертификатов. точка.
на красный свет машины не едут. точка. это простое правило, его сложно понять, но так устроен мир - переубеждать кого то в этом выходит за рамки этого форума.


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

Ответ: Вопрос лежит в простой плоскости. если кто-то хочет сделать аналог АРМ Орион Про со своим видинием интерфейса - то к этому нет никаких препятствий. Берется Модуль интеграции и делается работа. Но только вот Программисты Болида они не просто так зарплату получают. пока никто не дотянул до функицонала.
И смею Вас уверить - большинство программистов в Болиде могут сделать приложение и для Android и для iOs, в этом нет вообще никаких проблем. Проблемы начнутся только тогда, когда заказчик Один раз импользует приложение По назначению. То-есть посмотрит удаленно с вебкамеры что к примеру у него в доме курят а на дом горит. и отключит автоматику на сигнализации, с помощью телефона. И кто будет после этог отвечать за трупы - вопрос простой и очевидный - разработчик такой системы. или допустим возьмёт у него же ребенок телефон, разблокирует и запустит пожаротушение на серверную стойку. а газ стоит под пару миллионов. он придёт в Иридиум и тот скажет - Вы хотели получить управление - Вы получили, в чем проблемы? мы же так не работает. мы работаем по чётким Нормам и Правилам. которые написаны Кровью. как бы пафосно это не звучало - это факт. и посянять кому бы то нибыло почему нельзя чуть-чуть от них отойти - выходит за рамки разумного и этого форума.


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


 
           



 

Горелый Юрий Алексеевич 7 месяцев 5 дней назад

Юрий Алексеевич, здравствуйте, и еще раз спасибо за наполненные ответы.
Да, моих познаний в технологии передачи данных не достаточно, чтобы вести корректный (не то что равный!) диалог, я  могу рассуждать обывательски - отправил, пришел ответ? нет? отправил еще раз, проверил состояние. Я же не промышленную систему делаю с четкими таймингами, у меня нет производственных процессов, скорее события, алгоритмы, диагностика.

Что касается новых протоколов, так я и не расчитываю на них. Более того, слегка погрузившись в эту тему, я пришел к выводу, что OPC стал своего рода стандартом для систем диспетчеризации, а значит надо осваивать его применение. Надеюсь, Болид реализовал на своем уровне достаточный функционал для интеграции по этому протоколу. На днях соберу стенд и начну интегрироваться)

Вариант с Modbus server от иридия пока оставлю в стороне, хочу, все-таки использовать шлюз в MQTT. Расчитываю получить событийную модель и опыт работы с более перспективным инструментом в мире IoT решений. Поправлюсь, более перспективным на мой взгляд.

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

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

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

Масликов Виктор Юрьевич 7 месяцев 5 дней назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

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

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

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

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

7 месяцев 4 дня назад

avatar
Юрий Алексеевич, так а что мешает болиду зайти в "умный дом"? или не хотите, чтобы в случае чего это название ассоциировалось у покупателей с системой, которую отключил ребёнок со смартфона? так может открыть новое направление - умный дом метеор (by болид) и все свои самые смелые решения, которые упираются в пожарную науку, выпускать под новым не_пожарным брендом. Ну не будет у сенсорного С3000 пожарного сертификата, да и пофиг, главное удобно, красиво, обширная и знакомая экосистема (протоколы орион/про), а пожарка? так она централизованная, мне своим пультом в неё и не надо будет лезть.

Волков Андрей 7 месяцев 4 дня назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Юрий Алексеевич, добрый день!
Мне кажется я понимаю о чем вы. Да, мне тоже хочется, чтобы каждый занимался своим делом, чтобы электрик электрикой, дома чтобы строили строители, а не барыги.. и т.д.

Никуда не деться от прогресса. Хотя нет, если всех обобрать еще неск.раз и завалить их работой, чтоб голову поднять не смогли - тогда да, много направлений попритухнет, что, собственно, и происходит..

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

А про ребенка.. Ну как вам сказать, вот потому мы и общаемся, чтобы таких вещей не допускать. Все люди разные, я бы такой интерфейс сделал бы, что если б человек отключил пожарку, его бы так смартфон же одолел, что он скорее бы её включил. Верите нет? Могу себе позволить. И запаролить эти отключения.. Но на самом деле - никто еще не просил её "удобно отключать".. НО!
Если она, пожарка, сработает! То не только, еще раз - НЕ ТОЛЬКО штатно она должна отработать (что обязательно), но и т.н. умный дом должен сделать все что можно, для минимизации ущерба, локазизации, оповещения и т.д.
Интеграция в пожарку даст больше функционала ей, больше пользы от работы и снизит негативные последствия пожаров. Но только при грамотном подходе. А где он у нас грамотный, наверное, вот тут рядом? Ответит пусть каждый сам себе.

7 месяцев 4 дня назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Добавить ответ

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

ПОКАЗАН

1817 раз

ЗАДАН

9 месяцев назад

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