Уважаемый, мне не исходники нужны, а эксплуатационная документация на драйвера, которые Вы разработали, хотя бы на один-два. В курсе, что это?

kosmos440o простите что вам надо? перепечатать страниц 200 документации протокола обмена производителя прибора? может вам его у производителя прибора попросить все же ?

Или как подключить драйвер к Scada системе и настроить получение данных в нее ? Так тут документация на Scada нужна опять же, я и ее должен перепечатать ?

Как-то точнее можно ставить вопросы?

Драйвера работают только с одной Scada так как они используют механизмы кода, которые использует разработчик Scada.
Работать с другой Scada не будут. Для этого надо, чтобы производители Scada давали такую возможность, а как правило ее нет.
Взять например OPC Инсат, в котором можно было бы написать опрос самому (языки С++ и LUA) и то, за деньги, то есть самостоятельно для себя и полностью бесплатно я этого сделать не могу.

Других Scada систем, в которых можно было бы самостоятельно писать драйвера устройств даже не знаю.
OPC Инсат работает только на Windows, так что его я отмел за ненадобностью.

У вас на OPC ИНСАТ есть такая документация? именно экплуатационная а не руководство пользователя по настройке ?

Понятно, значит не в курсе. Я сильно подозревал и не ошибся. Или это программная шняга, которая не подлежит оценке и о правильности её работы мы узнаём в процессе настройки и эксплуатации.
Как я понял, эти так называемые драйвера не переносятся из одной скады в другую. Какие есть драйвера для скад, а также какие скады работают с драйверами, и как хорошо, Вы не знаете. Но тем не менее рекомендуете отказаться от OPC и работать с драйверами. Это откровение какое-то божественное?

Ну, Вам, наверно, стоит уже ознакомиться с возможным составом эксплуатационной документации на ПО. Что, дать ссылку? На ОРС Инсат она есть.

kosmos440o мы просто говорим о несколько разных вещах. OPC сервер используется тогда, когда Scada не может, не умеет, не имеет нативных драйверов.

Нативные драйвера не могут работать с любой Scada в принципе, так как они интегрируются в код самой Scada, например используют определенные процедуры кода, API и так далее. Тем более важен язык программирования. То, что написано на C++ не будет работать на C# и так далее.

Что касается настройки, есть механизмы самой Scada системы как настраивать приборы, каналы, теги и так далее. Здесь нет необходимости изобретать велосипед. Если есть какие-то нюансы по настройке, ессно я их описываю, но назвать это документацией у меня язык не поворачивается файл настроек например представляет из себя xml файл с некоторым набором переменных - они описаны. Все остальное есть в документации на Scada....


Если бы драйвера переносились из Scada в Scada то все бы пользовались наработками Инсат или Адастры и никто бы не парился.

А чтобы понять, что OPC DA устарел, вам просто надо сравнить как работают Scada через OPC и как через нативные драйвера.
Есть с Modbus из коробки несколько Scada систем, та же SimpLight энетрпрайз вроде, какое-то количество времени она же проработает. Да наверняка еще ряд других найдется. Вот и сравнили бы...

Не, спасибо, скачивать доки на продукты Инсат мне нет необходимости в принципе, так как она вылетела из списка предполагаемых в работе очень давно. Когда мне эти товарищи на 500 счетчиков предложили купить целых ДВА сервера, потому что один, по их словам не справится с таким потоком информации... Речь была о версии 3 тогда. Что касается 4D, то такого откровенного тормоза я уже давно не встречал, наверное только в эпоху процессоров Pentium и использованию первых версий .NET Framework.
Сперва пусть научатся программировать, без обид...

Уважаемые : Kosmos440o и Manjey73, я не выпал из диалога, я тихонечко присел в сторонке, т.к. честно говоря боюсь попасть под раздачу..

Кто-нибудь может спокойно изложить обсуждаемую Вами проблему обывательским языком, типа: при использовании ОРС сервера, по мнению ХХХ возникает проблема совмещения...., что плохо "потому, что", а оппонент YYY утверждает, что данная проблема легко решается "таким-то способом"?




Пытаюсь накидать цифры для ТЗ, т.е. определить объем параметров которые хотелось-бы контролировать и управленческие функции, для того, что-бы понимать насколько глобальна или неглобальна задача. Телеметрия на пороговых сигналах (норма/авария) сейчас меня не интересует, такую уже реализовал. Как вид контроля (норма/авария) и управления (пуск/стоп)-подходит, но хочется залезть глубже..

1. OPC требуют больших ресурсов ПК. Переписываете все свои приборы - счетчики, модули ввода-вывода и смотрите сколько вам потребуется OPC серверов и каких, заходите на производителя и смотрите требования к ОС для них
2. Так как у вас ЖКХ оптимально строить распределенную систему, например вместо ПЛК на дом устанавливать промПК и накидывать на него отдельную Scada нижнего уровня так сказать. В данном случае вы можете даже не передавать данные куда-то выше, просто у УК будет 3 дома, 3 Scada на каждый дом, это в самом простом исполнении. Так вот при использовании OPC DA (если нет UA версии у производителя проборов, а даже если есть, то может быть только на Windows) вы попадаете к стоимости промПК еще на лицензию ОС.

В решении для домов каждый рупь на счету... Лицензия ОС, стоимость OPC (например можете посмотреть стоимость на счетчики Меркурий у компании Инсат, там от количества счетчиков от 400-от рублей и меньше. Сколько в МКД счетчиков ?
А счетчики тепла с M-Bus (наиболее распространенные как по выбору так и по цене), а воды с протоколом Пульсар ? или воды с импульсным выходом и регистраторами с другими протоколами, даже если Modbus ? Ну или все счетчики с импульсным выходом, но тогда вы не знаете пиковых цифр, только сумму потребления.
Так вот в борьбе за рупь на один дом вы потеряете в деньгах.

Ок, решили собирать в центральном узле а на МКД ПЛК с модемом или роутеры/модемы, а опрос одной Scada из центра.
Стоимость ОС из расчета на дом минус, стоимость OPC суммируем. Как рулить отношениями между вами и УК ?
Какую вам потребуется иметь мощность серверов в центре ?
В случае сбора данных на МКД при помощи ПЛК - оплата программисту ПЛК, на доме повторюсь много счетчиков разных, ПЛК с несколькими портами - куча разных счетчиков.


з.ы. для вас специально повторюсь, ВАЖНО вам самим понять, что вы хотите в КОНЕЧНОМ итоге. Вот просто посылаете конечное ТЗ потом разным производителям Scada систем с расчетом железа в том числе (кто под ключ у нас реализовывает) - удивляетесь цифрам и потом думаете

Понятно, значит, шняга 2-го типа. Но вот уж что не хотелось бы делать при ПНР систем автоматики - это писать на С++ или шарпе. Профессионалов этого занятия у меня нет, а наколеночное творчество не интересует. Хотя иногда приходится, но это не оплачивается никем никому и долго продолжаться не может.


А в чём проблема, у Вас же много счётчиков? Я ставил безлимитку, на 200 она нормально работала. Заказчик оплатил. Оплатил бы и 2, там не такие большие деньги в масштабе системы.

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

Я говорю о другом, особенно в сфере ЖКХ, где все упирается в деньги в первую очередь, и только во вторую в архитектуру решения.

И дальше уже ваш выбор, оплатить скажем 300 штук непосредственно разработчику Scada или скажем 150 штук фрилансеру.
Даже при цене разработчика это выгоднее по отношению к стоимости OPC сервера если речь о сфере ЖКХ в конечном итоге.

В ЖКХ много счетчиков, если речь идет о МКД и большом их количестве и в случае с тем же OPC Инсат придется наращивать железо по мере того, как один сервер перестанет справляться с опросом, хранением и так далее.
В ЖКХ вообще надо продумывать иную архитектуру решения, нежели привычную вам, работающему с одной Scada системой. Вот я о чем больше говорю. А при использовании Scada систем, которые не умеют работать иначе, как через OPC сервер гибкую архитектуру не построить.

Со слов Инсат, когда количество счетчиков перевалит за 300 начнутся проблемы с тормозами железа, что потребует приобретать новый сервер - опять деньги, при чем как на ПО так и на железо. а ЖКХ это бедное направление, они готовы заплатить за интеграцию, но не очень радуются тратам денег на расширение. Как-то так.

Так при ПНР именно вас никто не заставляет писать ПО вообще. Вы зная состав оборудования просто заказываете разработку ПО соответствующим людям точно так же, как покупаете ОРС... ваша задача настраивать, а не писать

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

Максимум 5% ЦП. Если конечно, не ставить миникомп Распберри с ресурсами телефона 2011 года, что Вы как раз любите.



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

Ну, вообще Ваши решения имеют место быть, наверно, это же как-то работает. Дай Бог клиентов Вам, всё же лучше, чем ничего. Но это всего лишь один из вариантов, не более того.

Если основное дело упирается в коммерческий учёт, то есть АСКУЭ, то здесь лучшее решение как раз не SCADA, а спец. ПО типа "Меркурий - энергоучёт" и т.п. И по факту это единственное разрешённое решение, так как они сертифицированы. СКАДу для коммерческого учёта придётся сертифицировать на месте, это куча проблем. Претензии к энергоснабжающим организациям по показаниям несертифицированных систем не рассматриваются судом. Часто такие системы позволяют подключить к ним и инженерное оборудование для мониторинга.
Плюс там всё заточено на снятие показаний, отчёты и выставление счетов, интеграцию с БД, 1С и т.п. Есть локальные УСПД, они могут по месту резервировать данные.

Господа, а если отбросить проблемы учета?
да, говорим о том, что считываением он-лайн параметров счетчиков воды и электричества ЭТА АСУЗ не занимается.
Фактически я данные ИПУ считываю 1 раз в месяц. Производители счетчиков сами разрабатывают программы их опроса, они достаточно стабильно работают. Более того, производители сами заинтересованы в продвижении своих счетчиков, поэтому они будут максимально подстраиваться под спрос на счетчики с заранее необходимым встроенным протоколом. Что касается информации ОДПУ, то тут, как я уже говорил проблема становится головной болью ресурсников, пускай они и думают...

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

я, так и не понял суть Вашего спора про драйвера и сервер ОРС, Плиз. объясните мне так, что-бы я понял.

да ладно, в ваших масштабах или на один МКД ? требования к ОС на OPC внимательнее почитайте


да ладно, на один МКД 25-30 тысяч, что сравнимо с ПЛК, но функционал будет куда выше, трудозатраты ниже, Админ никуда не будет бегать, а сидеть в теплом кресле. Бежать придется, только на замену если сгорит раз в надцать лет.

не поверите, но ЖКХ настолько бедные у нас, что даже тратиться на оборудование не хотят - стоимость счетчиков с интерфейсом им уже не "по карману", а тут еще ПЛК или промПК или OPC

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

Но при этом никто не мешает интегрировать все это и с 1C в том числе, чтобы меньше бегать.

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

1. OPC в рамках больших и распределенных объектов стоит денег больше, чем включенные в состав Scada драйвера. (тут уже от производителя Scada зависит, берут они за это деньги и какие, лицензия на Scada может зашкаливать, а кто за это будет платить?)

2. OPC требует установки Windows - стоимость лицензии ОС, в рамках проектов ЖКХ это тоже деньги, если делать распределенную систему.

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

4. OPC в распределенном и большом проекте будет работать медленнее.


остальное думаю вторично...

Самое простое - собрать всё по RS-485, вывести на коммутатор Ethernet через шлюзы, а дальше делать что хочешь. При необходимости добавить Wifi или GPRS, либо GSM, Lora. Можно подключаться либо из дома председателя ТСЖ даже программами для моб. телефона, либо откуда-то ещё. Либо не значит И. Если И, то там идёт усложнение, по разным вариантам. Оптимальные варианты лучше уже расмматривать по факту, в зависимости от наличия ресурсов, возможностей и структуры вашей организанизации. В начале темы я что-то писал.

P.S. А как ваши алгоритмы для тепловых узлов, работают, испытания делали?

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

цена вопроса была 1000 рублей

Да, при чем перешли на нативный драйвер с OPC Инсат.

Нет, это я не Вам, а Николаеву. Я хотел попробовать включить его энергосберегающие алгоритмы в свой контроллер отопления.


3. В ОРС можно посмотреть протокол обмена онлайн, остальное, я думаю, вторично

То есть в Scada нельзя посмотреть протокол обмена онлайн ? я правильно понял вашу мысль в качестве противоположного агрумента ?

и что это у вас на Modbus демка OPC, вы же кричали что купили ?

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

Господа, берем примерно дом: точек измерения температуры -100 (ну взял по максимуму, если мерить температуру по каждому стояку отопления), давления -20, напряжения -10, релейных сигналов -20.



Спасибо. как это выглядит в деньгах? примерно? под ключ? СРАЗУ ГОВОРЮ, Я НЕ ИЩУ ПОДРЯДЧИКА, Я ПЫТАЮСЬ ПОНЯТЬ Э О ВООБЩЕ КАК И СКОЛЬКО???



что "все" собрать-то? ну, есть датчики температуры с характеристикой Pt1000 и ДД 0-10В (например) и к чему я их? к ПЛК? мне сколько ПЛК понадобится (примерно на каждый дом?)

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


какие алгоритмы и какие испытания Вы имеете в виду?

Это зависит от Scada системы, которую вы выберите - от нуля за какой-то прибор, до суммы на один прибор учета или канал (тег), даже с одного прибора. Цена в целом от 0 рублей до овер дофига рублей.

Ну например лицензия на ту же SimpLigth Entrprise (поддержка Modbus и OPC различных производителей) без ограничений по тегам
от 77,5 тысяч рублей. далее добавляете стоимость OPC для приборов, которые вам нужны.
И так по каждой Scada делаете сравнение и во сколько вам это обойдется.



нужны не ПЛК а модули ввода/вывода для соответствующих датчиков, резервирование питания не забудьте, а далее канал связи
Модемы GSM или роутеры с 485-м интерфейсом, либо сетевые модули В/В и так далее и так далее, будет зависеть от выбранной архитектуры. А там либо центральная Scada собирает данные, стучась по каналам связи в каждый дом, либо ПЛК собирает все а у него забирают только важное, либо ПромПК и так далее...

Поймите, тут нет общего рецепта, все зависит от того, ЧТО ВЫ ХОТИТЕ в качестве данных и куда, от этого будет строиться архитектура, модули В/В, ПЛК, датчики, требуемые интерфейсы и так далее. + ваш выбор ПО, а там нет однозначного ценника.

Мастер скада 500 точек 30 тыс. рублей на одного клиента,
ОРС сервер 500 точек 4000 руб.
контроллеры например, VC1 Elstars 100 датчиков/5 =20 штук 200 тыс. рублей, релюхи и контроль давления в комплекте
шкаф диспетчеризации до 50 тыс. рублей в зависимости от расположения.
Разработка СКАДы там будет достаточно лёгкая, до 50 тыс.руб.
Шкафы автоматики лучше распределить по месту, штук 10 по 20 тыс. рублей. Если есть контроллеры ИТП или вентиляции, то их точки можно не учитывать, а просто подключить к СКАДе.
Кабель предварительно 50 руб х 150 точек х20 метров, 150 тыс. руб.
Плюс монтаж, ПНР, думаю, тыщ 400.
Проектирование систем автоматики судя по объёму будет средней сложности, до 100 тыс. руб. Но на типовых объектах можно сэкономить.
Ну, какая-то маржа для страховки рисков и чтоб интересно было работать, я обычно ставлю 50 процентов.
Итого, от 1785 т. р. Можете считать официальным предварительным КП))) При серъёзном желании могу посчитать более уже точно и где-то будет дешевле..
Как видите, считаем быстро, работаем также))) Ну и цена ОРС составляет 0,25 процента от стоимости капитальных затрат.

Ждём предложения конкурентов)))

Да, датчики температуры по 1500 и давления по 5000, где-то, если что добавьте. То есть возможно, уже за 2 миллиона перевалило. Есть такие ресурсы?

kosmos440o вы в Москве ? просто конкуренты не всегда оттудава, чтобы был даже смысл ценники озвучивать



Есть вариант вложиться в стоимость 0 рублей на сбор данных с любого количества МКД на 65 тысяч каналов при условии протокола Modbus.
Разработка Scada 49999 рублей 99 копеек

монтаж, подключение приборов, модемов и прочая местными силами, предоставить только удаленный доступ к приборам и ПК для установки Scada

Космос: спасибо, осмысляю "продуктовую корзину".



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

По большому счёту всё можно заменить на всё.
Я не в Москве, но можно что-то решить, если будет интересно. Я там жил несколько лет, люди вроде есть. В основном там по месту нужен монтаж и ПНР, остальное делается удалённо.

l-nikolaev я не рассматриваю оборудование - датчики, модули в/в, интерфейсы, каналообразующее, его стоимость будет ессно какой-то, которое тоже зависит от различных факторов. Я говорю о стоимости ПО.

MasterScada + OPC на те же 500 точек (предположу что Modbus и только) можно заменить на другую Scada до 65 ТЫСЯЧ точек абсолютно бесплатно.

Далее уже думать что делать для диспетчерских, это либо подключение к бесплатной SCada либо для каждого объекта диспетчеризации покупать Scada системы какие кому нравятся.
И тут два пути.
1. Бесплатный, при использовании БД (mySQL, Postgre что там еще есть?) - соответственно Scada или что еще должно уметь работать с БД
2. платный, 10 т.р. на каждые 65 тысяч тегов (ну вот такое ограничение есть) на драйвер Modbus slave и по Modbus гнать данные в Scada диспетчерской конкретной УК


То есть если речь идет о сборе данных по Modbus и известным протоколам тут можно не слабо так сэкономить.

Например у УК есть 1C и те, кто ее обслуживают и настраивают. Можно собирать данные и складывать их в БД, а УК данные смотрит через 1С. Все лучше, чем таскаться по этажам.

Вам спросили систему с конкретными параметрами, что Вы юлите?

kosmos440o меня не спрашивали состав оборудования и ПО, на котором бы я строил систему мониторинга в МКД.



человек не ищет подрядчика. А выше я написал, что система может стоить от не очень больших денег, до овер дофига....

Еще раз, тут нет жесткого ценника, даже если вы примените оборудование только с протоколом Modbus так как неизвестна куча вводных. И самая главная вводная это БЮДЖЕТ и ХОТЕЛКИ.

Еще фокус в том, что счетчики воды могут и как правило стоят в квартирах, да еще и не по одному экземпляру. Что часто не дает возможности прокладывать провода. Так что однозначных решений тут нет, если хочется все опрашивать.

Ну, столько шумели, спорили, а выхлопа 0. Не буду даже указывать на вещи типа, что ТС не говорил в конкретном вопросе про счётчики, а привёл конкретную систему с датчиками. Неужели в голове кирпичи не складываются? Блин, с кем я спорил, с каким-то интернет-балаболом... Пора бы уже держать себя в руках...

kosmos440o вы читать разучились ? Или в который раз вам и автору объяснить, что датчик может стоить как 1000 рублей так и 5000 рублей. Модуль Ввода может стоить 3000 тысячи, а может и 15000. ПО может стоить как вы написали 34 тысячи, кстати почему вы не указали что сервер хранения у MasterScada стоит больше 50 тысяч рублей ? Сама MasterScada способна хранить данные 10 лет или только показывать текущие данные ?

Нужно оповещение на Email, SMS, Telegram или нет, резервирование системы или нет и так далее и так далее и так далее...


Кстати автор ни слова не писал, что нужны щиты автоматики ИТП а только контроль температур и давления... Это так, к слову.

А так же не было указано какие каналы связи будут использоваться GSM (GPRS, 3G, 4G), Ethernet.

От многих факторов будет зависеть построение архитектуры и от этого цена. А уж какие датчики и по какой цене думаю автор вполне способен определиться на рынке. Этого добра как грязи. Это только вы втюхиваете MasterScada направо и налево, хотя есть решения как минимум в 2 раза дешевле, та же SimpLight Scada с поддержкой Modbus на 500 точек всего 23 тысячи, против ваших 34-х а без ограничений 77,5 - сколько ваша MasterScada будет стоить без ограничений ? 200 штук минимум.

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

Вот делал на Smartstruxure от Шнайдер Электрик мониторинг наших объектов, которые на гарантии, с офиса, вообще цветочек. Но там цена от 400 тыщ за скаду, безлимитка, но до 5 внешних клиентов. Можно онлайн писать программы FBD для ПЛК и наблюдать работу этих программ также онлайн (для сложных систем типа хладоцентров незаменимая вещь). Работа программы на 2-й картинке. Рядом стоят ещё два монитора с 2-х больших объектов, СКАДы на объектах, плюс мы подключаемся с такими же, как на объекте, возможностями. А на этом мониторе 3 маленьких объекта с нашими контроллерами VC1, это главная, плюс можно зайти на каждый объект, каждую установку, настройки и графики каждой установки.
Поэтому если есть деньги и не нужны счётчики или их можно подключить отдельной СКАДой, то рекомендую её. На больших объектах она будет даже дешевле, чем МС. Хотя у них в этом году политика ценообразования ужесточилась и там безлимитка не такая халявная получается, как раньше.

Эта система, кстати, без поддержки ОРС, есть встроенный Lon, Bacnet и Modbus. Работает прекрасно, вообще без проблем, но шаг вправо-влево, когда нужен сторонний протокол, приходится писать ересь всякую.

С мастер-скадой в этом проще, подключил ОРС и всё.

На третьей картинке поста выше новый объект с нашими контроллерами Elstars, Мастер-скадой и подключенными электросчётчиками. Теплосчётчик благодаря Болиту пока не подключили, так же пока разбираемся с ИБП, ДГУ, ПЛК на М172 от сторонних разработчиков, чиллером с какой-то своей программой от Филлиппс. Идёт мощная переписка между нами, генподрядчиком, заказчиком и другими субподрядчиками))) Почему я и не люблю ПЛК и закрытые системы.

ИБП - SNMP скорее всего, от производителя получить файл для их ИБП. Там есть нюансы, есть штатные OID для ИБП (не помню точный номер) в котором есть напряжение, токи, мощность и так далее. Производители могут отступать от этой версии и использовать свою.

ДГУ - может с LON оказаться

Теплосчетчик, если не дорого, то в России есть представительство USR-IOT, думаю что преобразователь Ethernet-RS485/RS232 будет стоить не намного дороже Болидовского и таки будет работать через Ethernet. Ну или Овен АС4 (могу ошибиться в номере, который 232-485)

M172 не помню, это свободный или параметрируемый ? ну и чиллер - тут надо с производителями оборудования в целом а не с производителями контроллеров переписку вести.

Вообще я изначально предложил Scada, которая будет заниматься сбором данных и обойдется в рамках каждого МКД либо ноль, либо копейки.
А чем визуализировать - дело десятое.

Ну например общедомовой счетчик взять - порядка 40 каналов с 3-х фазника Меркурий 230 - но ведь в визуализации столько не нужно, сумма мощности, напряжение и ток по фазам и потребленная энергия. Все.
А теперь считаем сколько приборов можно подключить на платную Scada на 500 точек, если использовать все 40 каналов
500/40=12,5 - то есть всего 12 домов МКД - а простите температуры, давление, еще что-то куда ?

То есть при необходимости можно зайти на другую Scada или в БД и посмотреть все данные, а оператору с некой платной Scada показать только то, что нужно в обыденности.

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

Примерный дом и ХОТЕЛКИ я описал ранее. бюджет -ну сами понимаете- разумный, ценовой диапазон -средний, (по надежности -максимальный),
ИТП специально не рассматривал, т.к. НЕТ СМЫСЛА, т.к. в ИТП будут контролироваться те-же параметры (давление и температура), так, что ГЛОБАЛЬНО -нет отличий, т.е. просто к АСУЗ добавятся +20 тех-же самых датчиков, а вопрос управления ИТП будет решаться в каждом конкретном случае по своему, в зависимости от типа контроллера ИТП.

учет потребления ИПУ (это счетчики воды) -пока выносим за скобки, потому, что как Вы правильно отметили тут -"для каждой избушки -свои погремушки", поэтому нужно понять как собрать систему к которой с наименьшими проблемами можно подключить наиболее распространенные АСКУресурсов.




Если говорить о двухуровневой системе, то указанные Вами параметры интересны на уровне дома, на уровне районной (корпоративной) диспетчеризации) кроме объема потребленной электроэнергии и сигнала о том, что пропало напряжение - ничего и не надо.

Господа, давайте идти "от прсотого к сложному", вектор в приниципе я обозначил и надеюсь все его понимают, давайте пйомем какие варианты есть что-бы автоматизировать это хозяйство, а позже подумаем, а способны-ли эти конструкции развиваться до управления более сложным и многочисленным оборудованием. Все-же знают что такое "средний" МКД, вот и давайте подумаем как сделать так, что-бы внедрить на него АСУЗ, что-бы это было вменяемо по деньгам а результат работ стоил вложенных денег.

l-nikolaev так читайте между строк .

1. Электроэнергия:
а)Меркурий 230, 236 PQRS для 3-х фазников (свой протокол, при использовании всяких OPC только съем показаний, при использовании RapidScada и ее драйвера синхронизация времени счетчика, фиксация показаний на всех счетчиках в одну точку времени и потом чтение)
б) Меркурий 206 однофазные (обязательно с внутренним питанием интерфейса, завод выпускает) - тут хуже, последовательное чтение только показаний
в) Всякие Энергомера 3-х и 1-но фазные с интерфейсом (внимательно, чтобы было питание интерфейса) - протокол почти МЭК 61107, почти, потому что что-то у них там не заладилось
Остальное думаю в топку, так как опять же проблемы с протоколами в виде отсебятины

2. Вода:
Тут чистое имхо, лучше счетчики с импульсным выходом - дешевые. Плюс регистраторы импульсов Пульсар (2, 6, 10, 16 каналов), вроде завод выпускает по запросу с протоколом Modbus, но даже если с протоколом Пульсар не проблема для RapidScada. Насчет наличия всяких OPC для других не в курсе. Имеют встроенную батарею, считают даже если отключили питание, что для воды важно. Хотя если вода в МКД зависит от наличия напряжения, то может не так принципиально.
Общедомовые есть, но протокол только Пульсар. Ультразвуковые и еще какие-то. Ну либо сторонние с Modbus искать
Если нет возможности тянуть провода, есть кажется у того же Пульсар нашлепки радиоканальные на счетчик, в коридоре Регистратор по радиоканалу. Протокол кажется только Пульсар.

3. Газ:
Расходомеры, счетчики Логика, Ельстар, всякие ВКТ-5, 7 - что-то со своими протоколами и есть OPC, что-то с Modbus

4. Тепло квартирное.
а) есть Пульсар со своим протоколом и кажется с Modbus (по последнему могу ошибаться), так же как для воды, не знаю, есть ли OPC, но RapidScada может прочитать и передать дальше.
б) очень большой выбор квартирных счетчиков с протоколом M-Bus, причем дешевле, чем всякие там Пульсары, но - это своя физика, свой протокол, свои преобразователи, недорогие Etrhernet-MBus только у китайцев на 100, 180, 250 устройств, сейчас цен не помню, если надо, найду.
Мой драйвер для RapidScada платный, но не ради заработка, а ради допиливания, так как в наличии есть всего два устройства из большого многообразия, а протокол там всем протоколам протокол (убил бы таких разработчиков )

5. Датчики давления, воды и т.д.
Любые, на самом деле оптимально с нормирующими преобразователями в 4-20 мА + модули ввода вывода.
Почему так? - У вас модули ввода-вывода всегда одна номенклатура, никаких тебе для Pt100, Pt1000 и т.д.
Меньше погрешностей на разной длине кабеля, никаких коэффициентов на это можно не закладывать.
Модули ну например Овен МК110-8А (могут и просто датчики температуры подключать, можно поиграться, ставить датчики с НПТ или нет.
з.ы. я сейчас удаленно готовлю проект, где в качестве давления люди выбрали датчики китайские с выходом 0-5В. То же экономят по бюджету видимо.

В качестве сборщика данных, опять же имхо, ни ПЛК, ни модемы с интерфейсами, ни роутеры, а именно промПК, желательно с 2-мя RS485 портами и сетевым интерфейсом (тут тоже 2 лучше). Для простоты на x86 архитектуре.
По факту для чтения одного МКД достаточно мощности Raspberry Pi Zero (2, 3) и аналогичных. Если нужна именно промка, я находил недорогие в серии ICO
https://ipc2u.ru/catalog/vstraivaemye-siste...-din-reyku/ico/
Смотреть с впаянным процом, + стоимость памяти, винта в самой минималке. Цена будет в районе 25-35 тясяч.

6. Архитектура:
Ну тут все не однозначно. Идея глобальная. Один МКД - одна Scada на него, доступ жильцов к данным своих приборов учета, типа личного кабинета. Тут нужны WEB программисты, если делать красиво. Но можно бесплатно, просто доступ к данным должен делать ручками администратор. Например Пупкину из 8-й квартиры прописать логин и пароль в БД Scada и перезапустить соответствующий ПК для вступления в силу.
Передача в Scada верхнего уровня.
а) по Modbus бесплатно в любую Scada (должна уметь Modbus slave, сколько это стоит для других Scada не знаю)
б) в какую-нибудь БД бесплатно
в) через платный шлюз (на каждый дом) в верхнюю же RapidScada, там уже отдавайте в другие для УК по одному из вариантов выше.

Другой варинат это промПК только собирают данные с приборов и сразу передают в одну RapidScada. в таком варианте промПК на МКД является своеобразным удаленным сборщиком как бы без Scada а только с ее частью.
Если нет прямого доступа к удаленному ПК на МКД - серые IP например, настройку придется делать заранее под четкий список приборов, ну и настройка по месту. В таком случае промПК может быть еще дешевле, например на ARM архитектуре, винт вообще минималка, лишь бы хватило на систему.

Третий вариант, без ПК на МКД. Модемы, роутеры с портами RS485 а сборкой всех данных занимается только Scada в одном месте.
У RapidScada есть ограничение в 65 тысяч тегов, далее надо запускать второй и т.д. экземпляры.
Вся нагрузка по каналам ляжет на один ПК, а это мощность, емкость дисков и т.д.

Вот мое видение для МКД. А уж какое оборудование выбирать, это не ко мне, тут чисто мнение оптимального соотношения цена/ресурсы.

Описанная мной архитектура с промПК на один МКД способна развиваться в разных направлениях. Поменяли объем винта на МКД и у жильцов данные за последние 5 лет например... Надо подключить новые приборы, закончились порты RS485, поставили коммутатор + преобразователь интерфейсов - пожалуйста, добавляйте новый прибор. Надо управление чем-то? поставили модуль вывода, написали алгоритм + платный модуль управления от разработчика, пожалте управляйте. Надо обслуживающему персоналу отправить почту, да не вопрос, добавили в алгоритм и будет работать.
з.ы. вот тут, чтобы не бегать, надо организовать канал связи между центром и удаленным ПК, либо договор с провайдером в доме о наличии выделенного IP либо просто VPN канал - администрируйте не выползая из кресла.

с этим у меня сложно, т.к. -туповат



пожалуй это единственное, что реализуется на раз-два, т.к. нагнуть провайдера на ЛЮБОЙ канал для общедомовых целей - это не то, что не проблема, это ситуация, когда от их предложений (Вам позолоченый или в кисло-сладком соусе) -придется отбиваться...

Спасибо, осмысляю.

l-nikolaev



Не совсем так, я за выделенный IP дома плачу 250р в месяц. Вот и посчитайте затраты на один МКД в год. А домов много.
Провайдеру жирненько станет, а вам бедненько, так что VPN тут самое то, что надо.
Хотя если делать доступ к данным для жильцов, то это лучший вариант конечно.

разрешите вставлю свои 5 копеек.
У шнайдера есть поддержка OPC, просто она не очень широко освещается, хотя на последних обучениях говорят о ней.
+ есть возможость написать свой драйвер под 485 интерфейс.

Ну и вообще , если порассуждать, то возможно ставить один AS-P на дом, на нем вся графика и логика. а потом все дома просто добавляются в ES (или EC)-сервер. Красота.

Я от ЖКХ далек (слава богу), и вот не понимаю одного - а что, дома сдаются без диспетчеризации? Если нет, то о чем спор? о том, как данные из одной SCADA в другую передать? так это в каждом доме разные системы могут стоять и все равно придется что-то выдумывать.

У меня в микрорайоне от одного застройщика 4 дома вместе строились, так в каждом доме разные домофоны Про автоматику даже думать страшно)

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

Диспетчеризация по Московски выглядит как двусторонняя связь с диспетчерской (причем из ИТП, электрощитовой и лифтов) и прием аварийных сигналов от лифтов. Об остальном пока -не слыхал.

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

Вы правы, но мы сейчас обсуждаем совсем другую диспетчеризацию .

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

я например покупал счетчик Энергомера 102 с интерфейсом за 1,5 тысячи, чтобы разобраться с его протоколом, на 3-х фазный денег стало жалко, но там отличий по идее с гулькин нос. А застройщик зажмет и эти 1,5 тысячи и купит что-нибудь за 400-500.

При МКД на пару сотен квартир можете посчитать разницу. И так везде, где только возможно.
Но самое смешное, что взять теплосчетчики квартирные. У них срок поверки 3 или 4 года (не помню), так вот когда придет время, владелец купит опять же самый дешевый, если его не обязать, либо если УК будет за свои покупать. Кстати есть смысл, так как всю партию снятых можно отправить на завод на поверку, замену элементов питания и ставить на другой дом поверенные. Стоимость поверки теплосчетчиков дороже его стоимости, это блин нонсенс....

Как вариант, можно совместить последнюю милю связи для экономии, лифты и остальное. Я кстати, проектировал в Иркутске полностью диспетчеризированный по АСУ квартал жилых домов, с оптикой на наружных сетях и всеми делами. Не знаю, как там с реализацией пошло дело, но оптику проектировали в аврале. Коллега-смежник там же делал сеть для пожарки с выводом в диспетчерскую в одном из домов. Другое дело, что в жилых домах автоматики как таковой нет, кроме ИТП, изредка вентиляции и лифтов. Ну если в подпоре МГН стоит контроллер, можно его подключить по отдельному от пожарки каналу. Станцию ХВС можно подключить, если есть. Пожарную станцию по Модбас можно подключить. Что ещё? Отопление воронок, освещение, контроль приямков, контроль ВРУ обычно не автоматизируют. Загазованность обычно бюджетная, дискретку если только вывести. Хладоснабжение йок, фанкойлы йок, тепловые завесы и тепловентиояторы йок. Скучно.

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

Несколько лет назад был сформулирован временный подход о том, что СКАДа -это прерогатива торговых и бизнес центров, в т.ч. и как имиджевая составляющая. Сейчас можно говорить о том, что оно подешевело, а требования -возросли. Сейчас житель уже не тот. сейчас все умные, берут градусник и телефон, засовывают градусник под струю воды и говорят: господа, должно быть 60гр. а у меня-55.... и включают сирену.... Или начинают строчить жалобы о том, что "несколько дней назад в доме было холодно" -и УК месяц будет отписываться в ГЖИ на тему, что все было в порядке.

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

Тем более, принимая во внимание грядущую реновацию на основе комплексной застройки, и тот факт, что новые дома вероятно доживут до 22 века - диспетчеризация такого уровня выглядит как само-собой разумеющееся. Внедрение такой АСУЗ (с возможностью переинтегрироваться от диспетерской одной УК к другой УК) повысит уровень контролля за параметрами систем и позволит значительно сократить человеко ресурсы на обходы и контроль параметров), Говоря по русски: сейчас мало кто ходит и контролирует, а так -циферьки будут на экране...

Да, конечно.

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


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

Иерархически видимо правильно, если будет 2 уровня: 1-й уровень -дом (много параметров темп, давл, возможность управления ИС , АСКУЭ,) , 2-й уровень диспетчерская (или территориальная, или корпоративная) -меньше возможности управления, контроль ключевых параметров, ну, или многих параметров.

IT сейчас так развивается, что все-то, что казалось 5 лет невозможно невозможно контролировать или передавать -сейчас плевое дело.

Соглашусь с Вами, что пром ПК на каждый МКД со своей СКАДой 1-го уровня, и возможностью подключаться или переподключаться (в случае необходимости) к СКАДе2-го уровня (районной или корпроративной) -наиболее вариабельно.

Допустим, непосредственно АСУЗ может быть 3-х типов (Минималка, средняя, максималка)
Минималка, например это контроль параметров на входе и выходе из дома 10-15 шт... с учетом датчиков это 100-120 тр на дом (д.давления дорогие, заразы..) китай не рассматриваю, а Данфосс -5тр.. Что касается статичного адреса, то просто провайдерам ставить условием захода на дом -обязательное предоставление статичного IP адреса на общедомовые нужды, для них -это ноль затрат, а на доме будет наличие каналов равное числу работающих провайдеров.

Более, того, ИМХО, для застройщика должно быть вменено в обязанность строить дом с системой в минималке.

Проблема в том. что в ЖКХ как в отрасли комплексная проблема - нет денег (или желания их тратить), специалистов и понимания, зачем это нужно. Так-то это всё можно было и 20 лет назад делать.

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

Не, 20 лет назад это был признак крутизны...ХАНИВЕЛЛ, как много этом слове....ОВЕН, опять-же ничего такого не выпускал...сейчас боле-менее стало доступно.

Про баланс УК. вот тут-главная ошибка. Для УК такая АСУЗ -с одной стороны -снижение затрат на контроль, но с другой стороны -головняк, который будет служить доказательством, что параметры были не в норме, а УК ничего не делала...

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

kosmos440o, вроде как сейчас начали обязывать ставить общедомовые счетчики тепла. Про квартирные молчу, это личные инициативы владельцев.

Что касается минималки и расширяемости, то в минималке может быть достаточно модема(роутера) с портами RS485. до 10 т.р. Если дом решил развиваться, тогда промПК.

ПЛК там точнолишний, трудозатраты потом все сожрут. А при варианте модем(роутер) или промПК при разности приборов трудозатраты минимальны.

А кто на балансе дома всё это будет обслуживать? Жильцы? Вы эти морды видели?)))

Жильцы за это все будут платить, как за обслуживание лифта или домофона.

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

система Попроще, железо: муниципальный дом, многоэтажка, квартир на 50 и более...
пром ПК-30тр
ИБП+БИРП=10тр
ДТ -10 шт х2тр=20тр
ДД-5шт х 5 тр =25тр
кабель 2х2х0,75 (RS485) (с гофрой) =200пм х 50р/пм=10тр
щиток +расходники =10тр
телевизор или монитор=20тр
ИТОГО железо=125 тр.
монтаж+ наладка=полторы цены от железа =180тр.
Визуализация (т.е. сама СКАДа +ее конфирурирование) -тут Вы мне скажите...

Средняя, (например дом с ИТП + больше точек контроля), дом бизнесс- класса, железо:
пром ПК-30тр
ИБП+БИРП=10тр
ДТ -60 шт х2тр=120тр
ДД-20шт х 5 тр =100тр
кабель 2х2х0,75 (RS485) (с гофрой) =400пм х 50р/пм=20тр
щиток +расходники =10тр
телевизор или монитор=20тр
ИТОГО железо=310 тр.
монтаж+ наладка=полторы цены от железа =230тр.
Визуализация (т.е. сама СКАДа +ее конфирурирование) -тут Вы мне скажите...

+ ежемесячное обслуживавние: как вы это видите в деньгах? Вам виднее..

Квартирные счетчики тепла у нас видимо отходят, и это правильно. страна у нас холодная, многие хитрованы отключают свои батареи и прекрасно живут с температурой 20 градусов в квартире, которые им нагревают соседи, А соседи не могут понять, почему им приходится регуляторы на батареях выкручивать по максимуму.

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

ОДПУ тепла могут и не быть, тут -по разному. вся ситуация в том, что все ОДПУ (ЭЭ или тепла) -на балансе и обслуживании РСО (тепло и электро сети или сбыты) и софты на них пишут они.. и то, что они не пустят к своим датчикам потребителей -это 100% факт. т.е. возможно они дадут доступ к "смотреть в онлайн" сколько ты им денег должен, но смотреть цифры температуры, давления или напряжения в сети (тем более их архивы) -не дадут, т.к. в этом случае придется отвечать за свои косяки.

Поправьте меня, если я ошибаюсь: если у АСУЗ будет доступ к ОДПУ, то в каждом конкретном случае придется "женить" ОДПУ со СКАДой, а это головная боль для каждого конкретного случая, а если у АСУЗ будет получать сигналы от датчиков, то все становится более унифицированным, т.к. тачики все боле-менее стандартные.

Но повторюсь, РСО не даст подключить АСУЗ к своему учету, т.к. им оно не надо, тем более онр не поймут смогут-ли они защититься от вмешательства хакеров.

если модем или роутер, то визуализации это как выглядит? где стоит комп, который сигналы от него выводит на монитор? в районной диспетчерской? (т.е. уже на СКАДЕ 2-го уровня)?



Улыбнуло. видел конечно, каждое утро -в зеркале...я -ж тоже жилец. На работе еще -регулярно .