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

[kosmos440o]

Кучеряво живете. А мне пришлось автоматизировать автономную установку для водоканала с СМСками в диспетчерскую по 18 параметрам, из которых 4 аналоговые. Даже установка ХВО и ХВС без СКАДЫ у нас не обходится, не говоря о котельных и подстанциях. А про автоматические линии по производству, так ваще молчу.

Это вы извращенцы))) Аналоговые сигналы СМСками передавать. Про жопорез не слышали? А по СКАДе какие проблемы? И зачем приплетать автоматические линии по производству?

Сообщение отредактировал kosmos440o - 24.11.2020, 21:22

[kosmos440o]

Кучеряво живете. А мне пришлось автоматизировать автономную установку для водоканала с СМСками в диспетчерскую по 18 параметрам, из которых 4 аналоговые. Даже установка ХВО и ХВС без СКАДЫ у нас не обходится, не говоря о котельных и подстанциях. А про автоматические линии по производству, так ваще молчу.

Это вы извращенцы))) Аналоговые сигналы СМСками передавать. Про жопорез не слышали? А по СКАДе какие проблемы? И зачем приплетать автоматические линии по производству?

Сообщение отредактировал kosmos440o - 24.11.2020, 21:22

[l-nikolaev]

Мужики... Во, Вы жжете...

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

Сразу оговорюсь, что рассматриваю автоматизацию именно в ЖКХ (причем не небоскребного уровня).

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

Применять желательно контроллеры использующие модбас, т.к. оно хоть и древнее (как г..мо мамонта, но надежное и известное как автомат Калашникова)

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

Также как мне кажется вопрос о УПРАВЛЕНИИ АСУ каждого здания -похоже не возникает. т.к. что может сделать диспетчер, если он видит, что встал насос ГВС или сработал датчик защиты шахты лифта и лифт встал в аварию? Насос перезапустится автоматически, а если не запустится -то все-равно надо ехать смотреть, с лифтом: та-же картина.

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

Если меня не туда заносит, прошу поправить. Кстати, кто нибудь может просто и понятно сказать, что такое ОРС сервер, и нахрена он нужен?

[Banned]

Мужики... Во, Вы жжете...
А, вот тут-то ничего кроме ПЛК на ум не приходит, т.к. телеметрия в ЖКХном варианте это как правило температура и давление, причем точек измерения -куча (от 10 и до бесконечности)....и соответственно возникает вопрос, как эти вероятно разные ПЛК унифицировать с шаблонной скадой в диспетчерской.

Если меня не туда заносит, прошу поправить. Кстати, кто нибудь может просто и понятно сказать, что такое ОРС сервер, и нахрена он нужен?

Самая хохма в том, что дома могут быть не кабелированы с диспетчерской. Не знаю как у вас, но у нас применяется только волокно. Если у ранее отписавшихся с этим нет проблем и не предвидится, то в других местах больно бьют ключом.
ОРС сервер чтобы предоставить разработчикам систем диспетчеризации некоторую независимость от конкретного типа контроллеров. Разные драйвера необходимые для приборов, на рабочем компе создают проблемы сети. А чтоб этого избежать, придумали ОРС сервер. По очереди опрашавает приборы по сети.

Это вы извращенцы))) Аналоговые сигналы СМСками передавать. Про жопорез не слышали? А по СКАДе какие проблемы? И зачем приплетать автоматические линии по производству?

Кто чего слышал, это не важно. Важно, есть ТЗ и будь любезен исполнить. А затем приплетать автоматические линии по производству, что за автоматизацию их больше платят. Потому что АОВ, это для начинающих, с конфигурируемыми контроллерами.

[manjey73]

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

Что касается вашей темы ЖКХ - список приборов в студию.

з.ы. ПЛК тут лишний, если не требуется управления, а если даже управление есть, но какое-то простое, то можно использовать алгоритмы Scada системы.

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

Ну и можно сделать даже так, что жильцы дома будут подключаться к домовой Scada и смотреть показания своих приборов.
И даже с 1С интегрировать для УО...

Оповещение персонала по SMS, Telegram, Email
Весь вопрос в том, какие ваши хотелки и список оборудования, чего не хватает, можно добавить

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

Сообщение отредактировал manjey73 - 24.11.2020, 23:39

[kosmos440o]

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

Топикстартеру бросать ЖКХ и переходить на заводы?

[kosmos440o]

Также как мне кажется вопрос о УПРАВЛЕНИИ АСУ каждого здания -похоже не возникает. т.к. что может сделать диспетчер, если он видит, что встал насос ГВС или сработал датчик защиты шахты лифта и лифт встал в аварию? Насос перезапустится автоматически, а если не запустится -то все-равно надо ехать смотреть, с лифтом: та-же картина.

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

Если меня не туда заносит, прошу поправить. Кстати, кто нибудь может просто и понятно сказать, что такое ОРС сервер, и нахрена он нужен?

В целом праильно мыслите, по остальному прокомментирую:
Диспетчер должен доложить инженеру, и по его команде сбросить аварию, когда это возможно. Устранением аварии занимаются автоматчики. (По факту обычно тупо пытаются сбросить аварию, если это просто сбой. А если нет воды, то едут сантехники. Если нет питания, едут электрики. По лифтам лифтёры. Уже приятно, что не надо ехать всем по очереди или вместе.). Телеметрией (в вашем понимании) занимается компьютер или сервер диспетчеризации, нет необходимости в простых системах грузить контроллеры. Унификация происходит там же в компе, т к температура и давление - стандартные сигналы. В сложных системах, где хороший сервер-ПЛК, можно и поархивировать, но я в последнее время против этого, т.к. память на ПЛК быстрее убивается.

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

Сообщение отредактировал kosmos440o - 25.11.2020, 1:54

[nick2]

Если меня не туда заносит, прошу поправить. Кстати, кто нибудь может просто и понятно сказать, что такое ОРС сервер, и нахрена он нужен?

ОРС сервер от Овена

l-nikolaev, нам бы список желаемого при автоматизации здания - в студию получить.
можно :
1. просто собирать информацию о наличии напряжения и температуре.
2. собирать текущие показания счетчиков, давления, и т.п.
3. архивировать расходы, данные температуры и прочее.
4. управлять задвижками и счетчиками, отключая/закрывая и в обратную.
5. иметь возможность "легким движением руки" - погасить весь дом.

Что хотите от автоматизации получить?

У меня ЖКХ одного из районов на каждую водокачку/водоочистку/котельную ставит стандартный набор из ТЭКОНа, блока питания, GSM-модема, датчик температуры, датчик давления.
собирают инфо о текущем состоянии (расход воды, давление воды, температура в блок-боксе), в случае тревоги - передает инфо на телефон мастеру через СМС-ку. по запросу с телефона - присылает ответ.
то есть простой мониторинг. схема отлажена , программа корректируется под конкретные приборы.

Сообщение отредактировал nick2 - 25.11.2020, 6:48

[manjey73]

В СКАДе, где не поддерживается ОРС, возникают нерешённые проблемы с интеграцией. Например, достаточно трудно создать драйвер для электросчётчика Меркурий, СЭТ, датчика газа СТГ, водосчётчиков Пульсар (пипец просто), Взлёт, теплосчётчика ТЭМ и т.п.

Ничего трудного там нет, Меркурий, Пульсар вообще без проблем. Чего не хватает можно использовать и ОРС, но он как правило стоит денег и по мере увеличения количества приборов в конечном итоге проще написать драйвер непосредственно для Scada системы (но тут извините, не все Scada это позволяют). Момент №2 - используя OPC DA будьте любезны потратиться на лицензию Windows, даже самой захудалой, в то время как использование Linux беЗплатно

А драйвера - это путь подсаживания на кол, то есть на какую-то определённую систему.

Если Scada умеет и OPC, в том числе и UA, но при этом может работать с нативными драйверами устройств то где игла простите? Не хотите нативный драйвер, тратьте деньги на OPC и лицуху ОС. Вперед и с пестней как говорится.

з.ы. с удовольствием бы поучаствовал в каком-нибудь проекте диспетчеризации ЖКХ на бесплатной основе на базе RapidScada.
Да вот желающих не так много почему-то.... Могу читать приборы учета с M-Bus протоколом, Меркурий, приборы Пульсар, Логика, Энергомера да и хрен знает еще каких, если предоставят удаленку для написания драйвера....

Сообщение отредактировал manjey73 - 25.11.2020, 9:50

[yozik]

ОРС-сервер это программа-прокладка между СКАДой и оборудованием,

Как насчет расмотреть вариант ОРС-сервер это программа-прокладка между СКАДой и еще одной СКАДой

Как раз создается унификация для

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

[manjey73]

yozik опять же зачем OPC ? Modbus slave не?, MQTT не? БД не? зачем лепить горбатые OPC там, где про них давно пора забыть как страшный сон?

Ха, знаю, потому что люди в наше время выбирают Scada системы, которые просто не умеют работать никак иначе, как через OPC даже с Modbus. Потому что я на ней сижу, я ее знаю и я ее буду тулить везде..... отчасти это всегда так, но надо от этого уходить...

Сообщение отредактировал manjey73 - 25.11.2020, 14:13

[yozik]

yozik опять же зачем OPC ? Modbus slave не?, MQTT не? БД не? зачем лепить горбатые OPC там, где про них давно пора забыть как страшный сон?

Потому как на сегодняшний день ОРС единственно стандартный и есть у всех(??) СКАД
БД разные даже на разных платформах, кроме того не все СКАДы умеют получать с БД.
так же как и не все СКАДы умеют отдавать/быть Modbus slave

yozik
Ха, знаю, потому что люди в наше время выбирают Scada системы, которые просто не умеют работать никак иначе, как через OPC даже с Modbus. Потому что я на ней сижу, я ее знаю и я ее буду тулить везде..... отчасти это всегда так, но надо от этого уходить...

сами же написали почему ОРС..
да и с тем что надо отказываться согласен.

Интеграция СКАДы застройщика (дома) в СКАДу УК или еще чью
через ОРС вполне реально уже сейчас
без особых затрат (по сравнению с другими способами)

Сообщение отредактировал yozik - 25.11.2020, 14:49

[manjey73]

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

[yozik]

если не упираться в MasterScada,

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

Модбас тоже древний и "убогий", но живет, т.к. его понимают все.

[manjey73]

yozik когда писал драйвера на другие протоколы (Меркурий, M-Bus, Пульсар, DF1, Логика, МЭК61107) понял что протокол Modbus, при всей своей убогости, отымел всех по логике и правильности решения. Так что не надо тут на Modbus гнать

Сообщение отредактировал manjey73 - 25.11.2020, 16:16

[kosmos440o]

yozik опять же зачем OPC ? Modbus slave не?, MQTT не? БД не? зачем лепить горбатые OPC там, где про них давно пора забыть как страшный сон?

Ха, знаю, потому что люди в наше время выбирают Scada системы, которые просто не умеют работать никак иначе, как через OPC даже с Modbus. Потому что я на ней сижу, я ее знаю и я ее буду тулить везде..... отчасти это всегда так, но надо от этого уходить...

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

Сообщение отредактировал kosmos440o - 25.11.2020, 18:51

[manjey73]

kosmos440o ересь будете гнать вы, когда Microsoft свернет все, что связано с DCOM и перестанет его поддерживать и будет впаривать старые ОС за большие деньги.

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

ну ок, в рамках ЖКХ, OPC сервер на Меркурий от ИНСАТ стоит около 400р за ОДИН счетчик...
нативный драйвер от разработчика будет стоить денег, но в рамках множества домов дещевле, чем OPC в итоге. И это не считая мощность ПК для этого OPC чтобы переварить хотя бы 300 счетчиков. можете узнать характеристики ПК в техподдержке

хотя кому я это все говорю ? шабашнику, который больше 3-5 приборов на объекте не подключал в Scada ?

Это вы еще иностранцам не писали в поддержку, там оперативность может растянуться на лета.
И если что их OPC стоят совсем не 5 рублей, а например 1000 причем в евро.

Сообщение отредактировал manjey73 - 26.11.2020, 0:27

[kosmos440o]

kosmos440o ересь будете гнать вы, когда Microsoft свернет все, что связано с DCOM и перестанет его поддерживать и будет впаривать старые ОС за большие деньги.

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

ну ок, в рамках ЖКХ, OPC сервер на Меркурий от ИНСАТ стоит около 400р за ОДИН счетчик...
нативный драйвер от разработчика будет стоить денег, но в рамках множества домов дещевле, чем OPC в итоге. И это не считая мощность ПК для этого OPC чтобы переварить хотя бы 300 счетчиков. можете узнать характеристики ПК в техподдержке

хотя кому я это все говорю ? шабашнику, который больше 3-5 приборов на объекте не подключал в Scada ?

Это вы еще иностранцам не писали в поддержку, там оперативность может растянуться на лета.
И если что их OPC стоят совсем не 5 рублей, а например 1000 причем в евро.

Опять какие-то сказки рассказываете. Ну в 11-й винде отключат DCOM (вроде как с него слезли уже), ОРС будет на чём-нибудь другом, либо пока будем сидеть на 10-ке или 7-ке. Всяко лучше, чем sudo-шничать в командной строке с записной книжкой линуксовых команд)))
А бесплатный сыр от неизвестных разработчиков, из которых кто-то что-то гипотетически может дописать, может не дописать, насколько это криво опять ещё будет? - спасибо, не надо. Мне ещё процесс приёмки и тестирования организовывать? Я обычно первая мышь в пищевой цепочке, а не вторая, да и клиентов своих уважаю. Заказал как-то скрипт на VBA одному спецу по рекомендации, 10 раз пришлось возвращать. У Вас как-то не возникло мысли, почему никто не хочет ваши наработки?
По дороговизне - открою Вам страшную тайну - есть бесплатные ОРС - сервера и бесплатные версии платных. Что касается счётчиков, да, больше 200 на одном объекте не подключал. Я надеюсь, ваш драйвер не загнётся от такого количества. А шабашником как раз чувствую Вас - такие же подходы, приехать, что-то где-то накрутить, резисторов напаять на клеммы, изолентой синей замотать, без документации без инструкции, и свалить, да ещё и какую-то шнягу на линухе и на скриптах наварганить. Потом ещё и придётся подсесть на Ваши услуги, пока с позором всех не выгонят с объектов. Выложите хотя бы документацию на один свой драйвер и реализованную скаду, посмотрим. Пока вижу, что просто свой маленький опыт транслируете на всю отрасль.

Сообщение отредактировал kosmos440o - 26.11.2020, 2:14

[manjey73]

kosmos440o так зайдите на сайт разработчика Scada (RapidScada) и почитайте что она могёт...

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

И вас никто не заставляет использовать Linux, привыкли к Windows? да ради бога. Но вот когда речь идет о распределенной системе в той же ЖКХ, на каждый узел покупать ОС тоже накладно. И кстати, командная строка не особо нужна на отстроенной системе, все делается со своего ПК средствами администрирования Scada системы а не в командной строке удаленного ПК.

з.ы. в общем сидите дальше на MasterScada и продолжайте кушать кактус....

[kosmos440o]

kosmos440o так зайдите на сайт разработчика Scada (RapidScada) и почитайте что она могёт...
з.ы. в общем сидите дальше на MasterScada и продолжайте кушать кактус....

Спасибо, у меня есть более интересные и серьёзные варианты. Для Home Porno может и подойдёт ваш. А Вы молитесь за здоровье разработчика RapidScada, это нужно. Я её пробовал, с первого раза не зашло. Да и оказалась не нужна бесплатная СКАДа, если у людей есть деньги на оплату моей работы, то и на нормальную СКАДу с поддержкой найдётся. А бесплатное хотят только халявщики, я пока с такими не работаю.
Я Вам задал вопросы по Вашим наработкам, Вы соскользнули. Вот и всё, что требовалось доказать. Поэтому, если сами не в состоянии работать на высоком уровне по нормативам, не надо учить тут других людей плохим подходам. А если в душе наболело, заведите бложик. Без обид, ничего личного, только профессиональный подход.

[manjey73]

kosmos440o где я соскользнул ? исходники лежат на GitHub, берите и пилите, Шура...

Ядро Scada бесплатное, а не вся Scada. И поддержка есть, если вы ее интегрируете на объекте от разработчика, а не от вас лично.
Вы в таком случае только связующее звено.

Ну, если не зашло, то не зашло. И я не призываю пользоваться именно этой Scada, можно и другими. Весь сыр бор из-за OPC больше. Если есть возможность обойтись без них, то лучше это делать.

OPC DA на другом не будет. OPC UA уже другая история, но к сожалению не под все есть OPC UA (это и на Linux работает в том числе, в отличии от DA)

Сообщение отредактировал manjey73 - 26.11.2020, 13:53

[kosmos440o]

kosmos440o где я соскользнул ? исходники лежат на GitHub, берите и пилите, Шура...

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

Сообщение отредактировал kosmos440o - 26.11.2020, 18:52

[manjey73]

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

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

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

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

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

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

Сообщение отредактировал manjey73 - 26.11.2020, 20:40

[kosmos440o]

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

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

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

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

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

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

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

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

[manjey73]

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.
Сперва пусть научатся программировать, без обид...

Сообщение отредактировал manjey73 - 27.11.2020, 14:21

[l-nikolaev]

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

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

ОРС сервер от Овена

l-nikolaev, нам бы список желаемого при автоматизации здания - в студию получить.
можно :
1. просто собирать информацию о наличии напряжения и температуре.
2. собирать текущие показания счетчиков, давления, и т.п.
3. архивировать расходы, данные температуры и прочее.
4. управлять задвижками и счетчиками, отключая/закрывая и в обратную.
5. иметь возможность "легким движением руки" - погасить весь дом.

Что хотите от автоматизации получить?

У меня ЖКХ одного из районов на каждую водокачку/водоочистку/котельную ставит стандартный набор из ТЭКОНа, блока питания, GSM-модема, датчик температуры, датчик давления.
собирают инфо о текущем состоянии (расход воды, давление воды, температура в блок-боксе), в случае тревоги - передает инфо на телефон мастеру через СМС-ку. по запросу с телефона - присылает ответ.
то есть простой мониторинг. схема отлажена , программа корректируется под конкретные приборы.

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

Сообщение отредактировал l-nikolaev - 28.11.2020, 9:39

[manjey73]

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

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

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


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

[kosmos440o]

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

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

Когда мне эти товарищи на 500 счетчиков предложили купить целых ДВА сервера, потому что один, по их словам не справится с таким потоком информации...

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

[manjey73]

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

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

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

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

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

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

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

Сообщение отредактировал manjey73 - 28.11.2020, 11:05

[kosmos440o]

1. OPC требуют больших ресурсов ПК. Переписываете все свои приборы - счетчики, модули ввода-вывода и смотрите сколько вам потребуется OPC серверов и каких, заходите на производителя и смотрите требования к ОС для них

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

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

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

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

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

Сообщение отредактировал kosmos440o - 28.11.2020, 11:14

[l-nikolaev]

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

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

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