Доброго дня, Андрей Тадеушевич.
Пока спциалисты по п.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 из моих вопросов выше по тексту) .  А уж организвовать у диспетчера два/четыре/восемь монитора/ов с разными окошками в разы дешевле чем писать свой собственный АРМ. Но это уже ответят коллеги. 

 

Спасибо за комментарий.. Поясню, нам важно архивировать сигналы (неисправности-все, сработка датчиков- все, неготовность АПТ, пожар) с метками времени от С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) Спасибо, за предложение, почитаем подумаем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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