|
Стоит задача передавать данные с системы пожаротушения в БД сторонней SCADA. Для себя видим два варианта:
Уважаемая тех поддержка подскажите по 2 варианту. с использованием модуля управления. 6 лет 2 месяца назад Гришкевич Андрей Тадеушевич 10Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Доброго дня, Андрей Тадеушевич. 6 лет 2 месяца назад Горелый Юрий Алексеевич 581Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Спасибо за комментарий.. Поясню, нам важно архивировать сигналы (неисправности-все, сработка датчиков- все, неготовность АПТ, пожар) с метками времени от С200М (он же это делает или ПО Орион Про?). В случае с применением С2000ПП, предполагаю, что время будет проставляться либо конвертером RTU в TCP IP, либо самим сервером SCADA, что не есть хорошо. Такая же проблемма при применении OPC (или всё-таки есть возможность передавать события через ОРС с метками времнеи С2000М?). Для точной увязки времени и рассматриваем вариант с вариантом 2 . (установить Орион Про (или только её модуль управления) на сервер, где крутится SCADA и передавать данные с помощью XML-RPC). Орион Про все равно будем покупать для эксплуатации, но как подключать (вместо или вместе с "модулем управления")пока не понимаем. Узнали по XML- RPC отсюда стр.5 https://bolid.ru/files/373/566/pak_upr.pdf 6 лет 2 месяца назад Гришкевич Андрей Тадеушевич 10Знатоки, кто-нибудь ответит на мои вопросы выше?
– Гришкевич Андрей Тадеушевич 6 лет 2 месяца назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Может кому пригодится. 6 лет 2 месяца назад Гришкевич Андрей Тадеушевич 10Добрый день!
А вот мне только сегодня ответили следующее: Модуль управления, на который я очень расчитывал, позволяет согласно документации осуществлять сбор информации, управление, подписываться на события. Тоесть делать все, что нужно для работы своего срудства диспетчеризации, например. Однако! Если установлен АРМ, то да, покупать этот модель не нужно, так как он не будет работать! Т.е. не будет никакой интерграции. Либо-либо. Если нужно, чтобы был и АРМ и внешняя система, то нужен ТОЛЬКО OPC. Лично я никогда с ним не работал и не представляю, как подружить OPC сервер с моим ПО, которое в кач-ве интерфейсов поддерживает TCP-UDP-HTTP запросы. – Масликов Виктор Юрьевич 6 лет назад Доброго Вам дня, Виктор Юрьевич.
OPC (аббр. от англ. Open Platform Communications) является де-юро и дэ-факто стандартом для СКАДА систем - систем диспетчерского управления и сбора данных. То-есть если у вас ПО для сбора данных и диспетчерского управления - то оно в первую голову хочет собрать данных с разных систем. А дэ-факто стандар на эти действия это ОРС. в том либо ином виде. https://ru.wikipedia.org/wiki/OPC на всякий случай. TCP-UDP-HTTP запросы.-это, на всякий случай более сложные в реализации протоколы. Ибо разные производители чего только не напридумывают - как получать по UDP данные. или по тому же Http к примеру есть с десяток примеров разных реализаций интерфейсов передачи данных как post так и get запросами причём оба два в разные стороны (на приём с сервера и передачу на сервер), что само по себе требует программирования для каждой конкретной задачи. ОРС сервер/клиент позволяет сделать интеграцию один раз, и потом просто получать данные. – Горелый Юрий Алексеевич 6 лет назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Здравствуйте! Я программу пишу не сам, это оболочка, в которой уже реализованы эти протоколы. А работы с OPC в чистом виде нет. Мне проще на ip порт создать соединение и подписываться на события, разбирать их, отправлять запросы в определенной форме. Конечно, было бы идеально иметь какой-то программный шлюз, позволяющий обращаться по TCP к данным на OPC, и также от OPC получать синхронные или асинхронные ответы. 6 лет назад Масликов Виктор Юрьевич 13День добрый, Виктор Юрьевич.
Я правильно понял, что у Вас система с какой-то оболочкой ( Весьма интересно какой) которая по запрашиваемому функционалу Цитата: "...То есть и события о сработки датчиков, и по запросу текущие состояния, давать команды управления..." То-есть, в том числе управлять системой, которой управляет АРМ Орион? Да ещё и распределённо? что бы это не означало (а хотелось бы уточнить что это в Вашем понимании значит). И при этом у неё (Вашей системы) нет встроенного ОРС сервера, а есть Только TCP, UDP и Http -протоколы, которые которые по своей сути не подразумевают на канальном уровне гарантированную доставку команд управления? Этот вопрос Очень Сильно смущает. Особенно если АРМ Орион стоит в части пожарки, а он может так стоять. Или всё-таки что-то было понято не так, и всё совсем по-другому? Тогда хотелось бы узнать что за оболочка, чтобы попытаться Вам Помочь. Если всё рассказать более пОлно- то вполне возможно есть альтернативные пути. Особенно если ещё понимать Цель, Задачу и размер Системы. Программный шлюз ОРС в TCP и обратно - чтобы это не значило - можно реализовать на многих скада системах. "чтобы это не значило" = придумать программисту СКАДА системы какой-нибудь простенький протокол поверх tcp и Методы обмена по TCP (ну либо взять к примеру MODBUS over TCP - что вполне себе TCP, в некотором роде... какого бы вида доступ к хистрым регистрам не происходил и накрутить сверху на протокол методы общения с АРМ-ом) Можно кстати взять и программный преобразователь ОРС в MODBUS over TCP но Методы передачи данных при этом придётся придумывать Вам самим . – Горелый Юрий Алексеевич 6 лет назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Юрий Алексеевич, еще раз здравствуйте, и спасибо, что поддерживаете этот диалог. 6 лет назад Масликов Виктор Юрьевич 13День добрый, Виктор Юрьевич.
По второй части Вашего вопроса-Ответа: Цитата : "Что касается гарантированной доставки, то UDP - да, не дает гарантии, TCP дает." Мой ответ прост - К сожалению TCP это " транспортный уровень сетевой модели ". он не даёт Прикладной, сеансовый или представительский уровень. (Это имеет значение в том, что сейчас у Вас нет понимания того для чего и как интегрироваться и это проблема) Говоря развёрнутей: То-есть гарантировать доставку он не может. он может гарантировать доставку пакетов. Для примеров - в протоколах на базе сетей RS485 есть такой же подсчёт контрольной суммы, не боьлше не меньше. Иногда шифрованный иногда нет. Вот в протоколах ОПС - он во-первых шифрован. а во-вторых имеет гарантию доставки сообщений, уже на Прикладном, сеансовом или представительском уровне. Дальнейшие рассуждения про китайские реле лучше оставить за скобками - здесь нет улыбающихся смайликов, чтобы посмеяться и пошутить. Даже оборудование Siemens не всегда сертифицированно для работы с ОРС, не то, чтобы даже думать о китайских реле. Если коротко - то Методы гарантированности доставки сообщений координально другие, развивать здесь теорию и обучение я не буду. – Горелый Юрий Алексеевич 6 лет назад День добрый, Виктор Юрьевич!
отвечая на первую часть Вашего вопроса "Секрета что за оболочка нет, это 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, в этом нет вообще никаких проблем. Проблемы начнутся только тогда, когда заказчик Один раз импользует приложение По назначению. То-есть посмотрит удаленно с вебкамеры что к примеру у него в доме курят а на дом горит. и отключит автоматику на сигнализации, с помощью телефона. И кто будет после этог отвечать за трупы - вопрос простой и очевидный - разработчик такой системы. или допустим возьмёт у него же ребенок телефон, разблокирует и запустит пожаротушение на серверную стойку. а газ стоит под пару миллионов. он придёт в Иридиум и тот скажет - Вы хотели получить управление - Вы получили, в чем проблемы? мы же так не работает. мы работаем по чётким Нормам и Правилам. которые написаны Кровью. как бы пафосно это не звучало - это факт. и посянять кому бы то нибыло почему нельзя чуть-чуть от них отойти - выходит за рамки разумного и этого форума. Надеюсь на понимание, я постарался разделить Ваш вопрос на отдельные части с тем, чтобы Вы задавали более конкретные вопросы, и получали конкретные ответы, которые помогут Вам в работе с оборудование компании Болид. – Горелый Юрий Алексеевич 6 лет назад Юрий Алексеевич, здравствуйте, и еще раз спасибо за наполненные ответы.
Да, моих познаний в технологии передачи данных не достаточно, чтобы вести корректный (не то что равный!) диалог, я могу рассуждать обывательски - отправил, пришел ответ? нет? отправил еще раз, проверил состояние. Я же не промышленную систему делаю с четкими таймингами, у меня нет производственных процессов, скорее события, алгоритмы, диагностика. Что касается новых протоколов, так я и не расчитываю на них. Более того, слегка погрузившись в эту тему, я пришел к выводу, что OPC стал своего рода стандартом для систем диспетчеризации, а значит надо осваивать его применение. Надеюсь, Болид реализовал на своем уровне достаточный функционал для интеграции по этому протоколу. На днях соберу стенд и начну интегрироваться) Вариант с Modbus server от иридия пока оставлю в стороне, хочу, все-таки использовать шлюз в MQTT. Расчитываю получить событийную модель и опыт работы с более перспективным инструментом в мире IoT решений. Поправлюсь, более перспективным на мой взгляд. Под перспективностью TCP-UDP-HTTP запросов я не сам транспорт понимаю, ясно, что Modbus может быть и вообще что угодно обернуто в TCP, я имел в виду, что для меня перспективнее использовать текстовые команды, интегрируемые в браузер и вообще между компьютерами. Кроме того безопасность, шифрование и т.д. в таком случае можно возложить на инструменты сетевой безопасности, которые, как мне кажется, развиваются не медленнее, чем продукты безопасности шинной в отдельно взятых системах. Опят же, это укладывается в парадигму "распределенной системы", в которой каждый элемент делает то, что он делает лучше всего, а я это увязываю во едино. К вопросу о сертификатах и возможных трагедиях... Но я опять же, обыватель, надеюсь, здравого смысла мне хватит, чтобы заложить алгоритмы, не позволяющие создать предпосылки для подобного рода происшествий. Как мне кажется, я порой, даже черезчур перестраховываюсь и стараюсь думать наперед, не редко во вред себе по времени деньгам и лояльности ко мне Заказчика, однако отсутствие сертификата для меня не повод отказываться от применений. Есть тому ряд причин, это долгая дискуссия, скажу лишь что я с уважением и пониманием отношусь к озвученной Вами позиции. Надеюсь, что возможности интеграции в связи с озвученной Вами позицией не будут урезаны, запреты не всегда полезны в конкурентном мире. Думаю, только рубль и заставляет такие вещи реализовывать. Дай волю - все бы запретили всем. Сам очень часто очень многое хочу запретить) Думаю, практическое применение того, чего мы коснулись прояснит многе вопросы. На этой неделе планирую начать. Еще раз спасибо за участие в решении моего вопроса. Надеюсь, информация окажется полезной не только для меня. – Масликов Виктор Юрьевич 6 лет назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Доброго времени дня, Виктор Юрьевич. 6 лет назад Горелый Юрий Алексеевич 581Юрий Алексеевич, так а что мешает болиду зайти в "умный дом"? или не хотите, чтобы в случае чего это название ассоциировалось у покупателей с системой, которую отключил ребёнок со смартфона? так может открыть новое направление - умный дом метеор (by болид) и все свои самые смелые решения, которые упираются в пожарную науку, выпускать под новым не_пожарным брендом. Ну не будет у сенсорного С3000 пожарного сертификата, да и пофиг, главное удобно, красиво, обширная и знакомая экосистема (протоколы орион/про), а пожарка? так она централизованная, мне своим пультом в неё и не надо будет лезть.
– Волков Андрей 6 лет назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
Юрий Алексеевич, добрый день! 6 лет назад Масликов Виктор Юрьевич 13Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
7876 раз
6 лет 2 месяца назад
По каждому вопросу/ответу можно добавлять комментарии. Комментарии предназначены для уточнения вопроса/ответа.
добавить комментарий