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

[l-nikolaev]

Добрый день.
Хотелось бы пообщаться со специалистами в области автоматизации ИС зданий. Уровень компетенции –средний инженер с 30-ти летним опытом, опыт эксплуатации инженерных систем здания от нуля до ГИ. Имею небольшой опыт эксплуатации Ханивелла. О том, что такое АСУЗ (в принципе) и зачем это нужно –пропускаем.

Примерный круг вопросов:

1. Как это структурированно? Т.е. есть контроллеры к которым подключаются датчики, контроллеры обвязаны проводом (или беспроводным каналом), где-то к проводу или каналу подключен комп. На котором работает программа управления (с возм. Ручного управления) программа привязана к производителю контроллера или протоколу обмена по каналу и т.п.?
2. Какие типы в основном распространены в мире: Производители, Контроллеры, линии связи, протоколы передачи, пользовательское ПО.
3. То-же самое в РФ.
4. Ваше видение перспективных направлений развития систем.

В интернете в основном имеются краткие обзорные статейки, которые плавно переходят в «Наша компания занимается ….» и понеслось..

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

[l-nikolaev]

Добрый день.
Хотелось бы пообщаться со специалистами в области автоматизации ИС зданий. Уровень компетенции –средний инженер с 30-ти летним опытом, опыт эксплуатации инженерных систем здания от нуля до ГИ. Имею небольшой опыт эксплуатации Ханивелла. О том, что такое АСУЗ (в принципе) и зачем это нужно –пропускаем.

Примерный круг вопросов:

1. Как это структурированно? Т.е. есть контроллеры к которым подключаются датчики, контроллеры обвязаны проводом (или беспроводным каналом), где-то к проводу или каналу подключен комп. На котором работает программа управления (с возм. Ручного управления) программа привязана к производителю контроллера или протоколу обмена по каналу и т.п.?
2. Какие типы в основном распространены в мире: Производители, Контроллеры, линии связи, протоколы передачи, пользовательское ПО.
3. То-же самое в РФ.
4. Ваше видение перспективных направлений развития систем.

В интернете в основном имеются краткие обзорные статейки, которые плавно переходят в «Наша компания занимается ….» и понеслось..

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

[yozik]

Даже не знаю.
С одной стороны ваш вопрос достоин Песочницы. Т.к. диспечеризация для современного инженера АСУ
это как ходить. Вы же не задумываетесь как Вы ходите?
Это ответ на ваш 1 вопрос.
ответ на 2 и 3 вопрос все "пляшут" от оборудования (кто на чем "сидит", какие скидки на что имеет).
4 вопрос..хм..
технология IoT интернет вещей
думаю толпа программистов недоучек (вся молодеж хочет быть программистами) таки залелет в область АСУЗ

Конкретезируйте вопрос пожалуйста.
А то он странный в контексте тем на форуме.
В закрепленном даже тема про книгу по АСУЗ есть.
Или вот Вам ответ из соседней темы

Не, ни одного.
мы тут так... плюшками балуемся...

[Lex]

Конкретезируйте вопрос пожалуйста.

Поддержу коллегу -
что конкретно интересует?

P.S.
если найдете подшивку бюллетеня "Автоматизация зданий" Головина - почитайте
(нашел - http://www.golovin.info/articles/novosti_rinka/all_az/).
Для первой информации очень информативно.
Можете почитать статьи здесь
http://www.bacnet.ru/knowledge-base/
(возможен уклон в сторону одного протокола Бакнет, но в целом- полезно)
и здесь
http://bms-journal.golovin.info/

Статьи не новые, но с тех пор именно в АСУЗ не многое изменилось.

Сообщение отредактировал Lex - 19.11.2020, 14:25

[kosmos440o]

вот хорошая статья, хоть там некоторых нюансов нет:
http://rina.pro/napravleniya-deyatelnosti/...ovannye-sistemy
что-то ещё тут:
http://rina.pro/napravleniya-deyatelnosti/...rizaciya-zdanij

Даже не знаю.
С одной стороны ваш вопрос достоин Песочницы. Т.к. диспечеризация для современного инженера АСУ
это как ходить. Вы же не задумываетесь как Вы ходите?

Ну, всё же теорию нужно знать, чтоб не мумукать перед начальством и подчинёнными.

Сообщение отредактировал kosmos440o - 19.11.2020, 19:46

[yozik]

Ну, всё же теорию нужно знать, чтоб не мумукать перед начальством и подчинёнными.

А еще думать, и анализировать.
У ТС больше 1к сообщений.
+

. Уровень компетенции –средний инженер с 30-ти летним опытом, опыт эксплуатации инженерных систем здания от нуля до ГИ. Имею небольшой опыт эксплуатации Ханивелла. О том, что такое АСУЗ (в принципе) и зачем это нужно –пропускаем.

В интернете в основном имеются краткие обзорные статейки, которые плавно переходят в «Наша компания занимается ….» и понеслось..

А теперь посмотри на свой ответ...
Не кажется ли тебе он "странным" в свете выделенного?
ТС же не просил обзорные статейки, и просил пропустить "что такое АСУЗ"

Меня формулировка вопроса смутила. Не зря про песочницу упомянул.
Тем более что

Статьи не новые, но с тех пор именно в АСУЗ не многое изменилось.

потому и

что конкретно интересует?

Сообщение отредактировал yozik - 19.11.2020, 21:03

[Banned]

Добрый день.
Хотелось бы пообщаться со специалистами в области автоматизации ИС зданий. Уровень компетенции –средний инженер с 30-ти летним опытом

Судя по счетчику коментов на форуме, все не так плохо. С другой стороны, 30 лет в автоматизации и задавать вопрос с которыми инженеры с 3-х летним стажем работы справляются, не корректно. У меня 40 лет стажа. давно, практически ничего не рисую, все разложено по полкам, полный копи-паст. Меняются только названия приборов и их УГО. Да, конечно, приходится решать проблемы на тему "как сделать", но это как вишенка на торте.

[kosmos440o]

А еще думать, и анализировать.
У ТС больше 1к сообщений.
+

А теперь посмотри на свой ответ...
Не кажется ли тебе он "странным" в свете выделенного?
ТС же не просил обзорные статейки, и просил пропустить "что такое АСУЗ"

Меня формулировка вопроса смутила. Не зря про песочницу упомянул.
Тем более что

потому и

Есть разница - инженер по икс-плуатации и инженер, мучающий осу. Первые могут по 30 лет бегать вокруг второго и даже не знать, что, блин, нельзя. Как недавно в одной недвижимой компании один главный эксплуататор заявил на совещании "у нас же автоматика сама работает, давайте уволим автоматчика". И все засмеялись.

Но чтобы автоматчик не мог формулировать в одном абзаце, что такое АСУ-икс, задачи и структуру, а заявлял "я ей тут дышу, не мешайте мне", то это вообще-то наглость уже)))

Сообщение отредактировал kosmos440o - 20.11.2020, 10:28

[l-nikolaev]

Господа, приветствую. Спасибо всем откликнувшимся, спасибо что хоть тапки и полетели в мою сторону , но" опИсанные тряпки -нет" .

Не могу понять, с чего Вы решили, что я 30 лет в АСУ? Я указал: " Уровень компетенции –средний инженер с 30-ти летним опытом, опыт эксплуатации инженерных систем здания от нуля до ГИ. Имею небольшой опыт эксплуатации Ханивелла. ...Вот сейчас прочитал еще раз, -нигде не наврал, 30 лет, юзаю вводы, распределительные сети, ИТП, канализацию, вентиляцию, слаботочку, ну, и все что входит в понятие "инженерные системы зданий".


Второй день усиленно читаю..в т.ч. и рекомендованное. скоро вопросы начну задавать...

[manjey73]

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

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

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

[l-nikolaev]

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

Да. Но, скорее обращаться не с вопросом о разрешенных протоколах и интерфейсах, а подключать автоматчика к разработке ТУ на разработку проектов внутренних сетей.

Вот мне и интересно, как в настоящее время выглядит АСУЗ в мире и в России, что мы будем иметь через 10 лет?

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

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

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

Ну, и второй вопрос: самому просто интересно.

[Banned]

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

[kosmos440o]

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

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

[manjey73]

l-nikolaev в ЖКХ и не только все упирается в коммерческие узлы учета и их протоколы, и мало того, с возможностью их читать из двух мест. Непосредственно со стороны поставщика (первостепенно) и со стороны потребителя для контроля.

Так что не все так однозначно.

[l-nikolaev]

l-nikolaev в ЖКХ и не только все упирается в коммерческие узлы учета и их протоколы, и мало того, с возможностью их читать из двух мест. Непосредственно со стороны поставщика (первостепенно) и со стороны потребителя для контроля.

Так что не все так однозначно.

По поводу "читать узлы учета" сейчас и в будущем все упростилась. Теперь это ПОЛНОСТЬЮ головная боль РСО. Т.к. РСО как правило монополист в определенном регионе (или населенном пункте), то они сами придумают как и на какой системе организовать интеллектуальный учет, и деньги у них есть (они- небедные) что-бы реализовать свои хотелки на любом оборудовании. У РСО как раз и будет все в порядке, т.к. они на определенном куске территории сформируют свою систему на своем оборудовании (и ни каких проблем с совместимостью не получат).

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

Не совсем понял Вашу фразу "не все так однозначно".

[l-nikolaev]

А в чём проблема с контроллерами? Тьма их, хороших и разных. Лишь бы поддерживали какой-то открытый и доступный протокол. Чаще всего либо заказчик выбирает полюбившиеся ему, либо ты ставишь полюбившиеся тебе, если сам будешь делать, это естественно. По протоколу сейчас не так важно, так как всё все равно кончается Ethernetом. ...

Да, в том-то все и дело, что интернетом не кончается, а продолжается, а кончается -диспетчерской, которая расположена где-то очень далеко, и к которой подключены (или будут подключены через 10-15 лет) дома с разными контроллерами и разными протоколами, причем переход дома от одной диспетчерской к другой возможен и реально бывает -1 раз в год.

И, чего, получается 1 раз в год при подключении дома к другой диспетчерской надо каждый раз придется нанимать специалистов, которые будут "женить" оборудование и софт диспетчерской с оборудованием и протоколом здания?

Не, ну может я преувеличиваю проблему, но унификация технической и технологической части всегда дает только плюс.
Был у меня американский автомобиль с дюймовыми гайками и болтами .. -очень неудобно в средней полосе России.

[manjey73]

Вы не совсем поняли суть. Вот есть завод например, все узлы учета читают РСО, точнее узлы сами отправляют данные в какие-то моменты времени. При этом завод желает эту информацию тоже получать, с той же периодичностью, что и РСО.

Тут два варианта (даже больше может быть), поставить второй узел технического учета, что дорого, либо считывать те же самые узлы учета, которые коммерческие.

В ЖКХ в принципе это тоже актуально.

Я бы на облачном сервере строил систему и при необходимости передать в другую УО просто менял бы пароли доступа к конкретному дому другой УО. Это в принципе возможно.

Сообщение отредактировал manjey73 - 22.11.2020, 10:45

[l-nikolaev]

Вы не совсем поняли суть. Вот есть завод например, все узлы учета читают РСО, точнее узлы сами отправляют данные в какие-то моменты времени. При этом завод желает эту информацию тоже получать, с той же периодичностью, что и РСО.

Тут два варианта (даже больше может быть), поставить второй узел технического учета, что дорого, либо считывать те же самые узлы учета, которые коммерческие.

В ЖКХ в принципе это тоже актуально.

Я бы на облачном сервере строил систему и при необходимости передать в другую УО просто менял бы пароли доступа к конкретному дому другой УО. Это в принципе возможно.

Если Вы не возражете разделю ВАше сообщение на 2 части.
1. -касаемое учета ресурсов ОДПУ и предоставления возможности потребителю получать он-лайн данные о потреблении.
2. о облачном сервере, на который выведен АСУЗ, и доступ УО распределяется правами администратора.

по 1- вопросу, да, конечно это нужно. сейчас ведь как: потребитель передает данные об объеме потребления (показания ОДПУ) РСО рассчитывает объем и стоимость и выставляет счет с указанием объемов (за расчетный период т.е. месяц). если у потребителя будет он-лайн картинка о потреблении это конечно +.

по 2-му вопросу. Диспетчерская -это затраты. ОУ поневоле участвуют в конкурентной борьбе за дома, в том числе пытаясь предоставить лучший сервис (больше услуг) за меньшие деньги. Поддержание облачного сервера кто-то должен брать на себя. кто? ОМСУ? -ему не надо, одна из УО? ей это надо только до тех пор, пока дом обслуживается у нее, как только дом уйдет, она будет заинтересована в том, чтобы у новой УО получилось хуже чем у нее... пока мне кажется, что облачный сервер это наиболее просто, но по-жизни -нереализуемо. Вы даже не представляете, как УО тормозят переход домов, суды по передаче технической документации длятся до года, а, Вы говорите "пароли"...Явки и пароли будут "утрачены" первыми .

[manjey73]

по 2, а почему бы не застройщик ? а с УО пропорционально брать плату за VPS сервер ?

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

[kosmos440o]

Да, в том-то все и дело, что интернетом не кончается, а продолжается, а кончается -диспетчерской, которая расположена где-то очень далеко, и к которой подключены (или будут подключены через 10-15 лет) дома с разными контроллерами и разными протоколами, причем переход дома от одной диспетчерской к другой возможен и реально бывает -1 раз в год.

И, чего, получается 1 раз в год при подключении дома к другой диспетчерской надо каждый раз придется нанимать специалистов, которые будут "женить" оборудование и софт диспетчерской с оборудованием и протоколом здания?

Не, ну может я преувеличиваю проблему, но унификация технической и технологической части всегда дает только плюс.
Был у меня американский автомобиль с дюймовыми гайками и болтами .. -очень неудобно в средней полосе России.

Уважаемый, мне кажется ваши проблемы в другом - в жадности или духовной бедности организации. Если у вас есть диспетчеризация и подшефная автоматика, то должен быть и соответствующий персонал. Если Вы, допустим, купили в компанию кран, вы же не будете его осваивать и разбираться в нём? Просто возьмёте на работу крановщика. То же самое и с автоматикой. Любой спец уровня начальника отдела давно прошёл эти проблемы и имеет варианты их решений.
Соответственно, затраты на персонал по автоматике и диспетчеризации должны быть включены в расходы и как-то окупаться. Наилучшее решение - это группа специалистов каждый своего уровня - проектировщики, программисты, наладчики, монтажники. Плюс отдельно или по совместительству админы по сетям. Нюансы зависят от того, чем конкретно вы занимаетесь и от объёма. Часто это делают на аутсорсе или миксуют аутсорс и контрольную группу, есть свои плюсы и минусы. Но если ваша организация занимается тем, что берёт с домов по 15 тысяч за уборку, и платит дворнику по тысяче, то автоматика не про вас.

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

[kosmos440o]

Из общих рекомендаци скажу так - для ЖКХ lonworks, Profinet, EtherCAT и прочая хрень идут далеко лесом. Bacnet может быть, но только при небходимости. Модбас RTU и ТСР есть почти в каждой железяке. Для всяких счётчиков свои протоколы, они модбасоподобны и передаются по таким же шлюзам и сетям. (У меня щас ТЭМ-104 работает по своему протоколу вместе с модбасовским оборудованием на одной линии). Поэтому Модбас предпочтительней всего, при нём унификация максимальна. Соответственно и выбирается контроллеры с Модбасом.

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

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

Сообщение отредактировал kosmos440o - 23.11.2020, 5:44

[Banned]

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

От себя чуток добавлю, правда уже об этом писал, также не развернуто:
Учитывать надо следующее, применение простого контроллера на каждый узел управления. Чтобы не получился "восьмикрылый семиног", а наладчик "восьмирукий семихер". Это в случае когда с одного контроллера управлять всем. Особенно это относится к распределенным системам. Все исправно, а не работает - проблема с сетью. Чтоб работало, Модбас RTU и ТСР в помощь и никак иначе. Вот почему подбор контроллеров у меня занимает много времени.
Начинающим хочу посоветовать LOGO!. Можете смело на нем стартовать, но имея полное представление что такое логические элементы.Получится, сидя за столом в комфортных условиях сделать программы, протестировать их, вплоть до каждой функциональной группы вначале. Хоть и не сразу, но получится. Это вместо того, чтобы заниматься этим на объекте в потемках и антисанитарии. Использовать LOGO! как переходник I/O при проблемах с интерфейсами некоторых агрегатов и как самостоятельное, но подчиненное устройство при отказе головного контроллера.

[yozik]

Начинающим хочу посоветовать LOGO!.

Не соглашусь. частично.

1. Logo это программируемое реле общепромышленное. Т.е. не специализированное.
2. Для начинающих лучше Овен. Там документация в свободном доступе и форум многочисленный. Освоив язык, переучится на другую среду не проблема.
3. Для отрасли АВОК лучше все таки начать с специализированных для АВОК ПЛК.
а) EVCO (бесплатная среда разработки, рускоязычная документация, видеопримеры)
б) Carel (дружелюбнее Евко, но среда платная, и документация на английском)
в) Сегнетикс (может даже первее)

[Banned]

Не соглашусь. частично.

Иосик, оставь свои игрушки при себе. Здесь обсуждают интерфейсы, а не проблемы начинающих.

[yozik]

Начинающим хочу посоветовать LOGO!.

После обеденного перерыва сменился пользователь?

Здесь обсуждают интерфейсы, а не проблемы начинающих.

А то как то слишком быстро забыли о чем писали

[kosmos440o]

От себя чуток добавлю, правда уже об этом писал, также не развернуто:
Учитывать надо следующее, применение простого контроллера на каждый узел управления. Чтобы не получился "восьмикрылый семиног", а наладчик "восьмирукий семихер". Это в случае когда с одного контроллера управлять всем. Особенно это относится к распределенным системам. Все исправно, а не работает - проблема с сетью. Чтоб работало, Модбас RTU и ТСР в помощь и никак иначе. Вот почему подбор контроллеров у меня занимает много времени.
Начинающим хочу посоветовать LOGO!. Можете смело на нем стартовать, но имея полное представление что такое логические элементы.Получится, сидя за столом в комфортных условиях сделать программы, протестировать их, вплоть до каждой функциональной группы вначале. Хоть и не сразу, но получится. Это вместо того, чтобы заниматься этим на объекте в потемках и антисанитарии. Использовать LOGO! как переходник I/O при проблемах с интерфейсами некоторых агрегатов и как самостоятельное, но подчиненное устройство при отказе головного контроллера.

Половину текста не понял, причём здесь антисанитария и потёмки. И зачем всякие Логи изучать. Это же не инсталляторы. Я вообще первые 5 лет в автоматике ничего не программировал, хватало обычных конфигурируемых контроллеров. Siemens Synco, Corrigo, ECL310 - что ещё нужно для счастья? Первый раз программировал, когда пришлось чужую кривую программу переписывать. И зачем такое счастье? И со сколькими системами на ПЛК эксплуататоры мучаются, потому что переписать часто дороже, чем новую написать. Я навскидку могу пяток таких объектов назвать при необходимости. Сейчас вот делал СКАДу - с конф. контроллерами просто настроил адрес и всё. Всё, Карл! С ПЛК и всякой нестандартной хренью запарился запросы слать производителям, половина не ответили толком. Так и не удалось подключить чиллер на ПЛК, мед. вентустановки на ПЛК, ДГУ. Щас, чую, зак ещё заартачится и начнёт поджимать по бабкам. А мне оно надо, эти проблемы, если кто-то не понимает критериев выбора оборудования или производитель. жмёт информацию? То же самое относится к ПЛК ЕVCO, Carel, и т.п. Если кто-то инсталлирует и имеет с этого, то понятно, или программист боится остаться без работы, а наладчику и конечнику зачем эти проблемы?

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

[yozik]

Половину текста не понял,

Вобще то вы оба об одном и том же пишите (одинаково думаете)
Про контроллеры

Есть конфигурируемые контроллеры для

применение простого контроллера на каждый узел управления. .....

Про интерфейс

Модбас RTU и ТСР есть почти в каждой железяке........ Поэтому Модбас предпочтительней всего, при нём унификация максимальна.

Чтоб работало, Модбас RTU и ТСР в помощь и никак иначе.

[Banned]

Половину текста не понял, причём здесь антисанитария и потёмки. И зачем всякие Логи изучать. Это же не инсталляторы. Я вообще первые 5 лет в автоматике ничего не программировал, хватало обычных конфигурируемых контроллеров. Siemens Synco, Corrigo, ECL310 - что ещё нужно для счастья?

Вы безусловно правы. Зачем сервиснику или электрику прогаммирование? Только в теме о другом речь. Потому как новые инсталяции без СКАДА не принимают, да еще СМС оповещение им подавай.

[alsz]

технология IoT
думаю толпа программистов недоучек (вся молодеж хочет быть программистами) таки залелет в область АСУЗ

Года 3 назад на этом форуме я утверждал, что следущий этап автоматизации не за контроллерами программируемыми на языках МЭК, а за современными системами на Jawa. Заканчивается 2020 год большинство производителей из линейки автоматизации перешли на модули ввода вывода. Голова с языками МЭК уже не нужна.

Рынок диктует свои законы, что дешевле и массовее, то и применяется.

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

если найдете подшивку бюллетеня "Автоматизация зданий" Головина - почитайте

Статьи не новые, но с тех пор именно в АСУЗ не многое изменилось.

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

Да, в том-то все и дело, что интернетом не кончается, а продолжается, а кончается -диспетчерской, которая расположена где-то очень далеко, и к которой подключены (или будут подключены через 10-15 лет) дома с разными контроллерами и разными протоколами, причем переход дома от одной диспетчерской к другой возможен и реально бывает -1 раз в год.

И, чего, получается 1 раз в год при подключении дома к другой диспетчерской надо каждый раз придется нанимать специалистов, которые будут "женить" оборудование и софт диспетчерской с оборудованием и протоколом здания?

Так и дороги у нас ремонтируют каждый год, Вася то платит, очередная тема увода денег. Это для Вас проблема, а для кого-то доход.
Решается грамотным ТЗ.

[kosmos440o]

Вы безусловно правы. Зачем сервиснику или электрику прогаммирование? Только в теме о другом речь. Потому как новые инсталяции без СКАДА не принимают, да еще СМС оповещение им подавай.

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

[Banned]

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

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

[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 раз в месяц. Производители счетчиков сами разрабатывают программы их опроса, они достаточно стабильно работают. Более того, производители сами заинтересованы в продвижении своих счетчиков, поэтому они будут максимально подстраиваться под спрос на счетчики с заранее необходимым встроенным протоколом. Что касается информации ОДПУ, то тут, как я уже говорил проблема становится головной болью ресурсников, пускай они и думают...

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

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

[manjey73]

Максимум 5% ЦП

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

Нормальный-то пром ПК по цене от сотки идёт...

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

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

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

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

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

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

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

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

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

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


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

[kosmos440o]

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

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

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

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

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

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

[manjey73]

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

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

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

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

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

[kosmos440o]

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

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

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

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

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

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

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

Прикрепленные файлы

 Безымянный222.jpg ( 435,6 килобайт ) Кол-во скачиваний: 14

 

[manjey73]

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

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

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

[l-nikolaev]

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

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

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

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

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

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

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

Самое простое - собрать всё по RS-485, вывести на коммутатор Ethernet через шлюзы, а дальше делать что хочешь. ....Оптимальные варианты лучше уже расмматривать по факту, в зависимости от наличия ресурсов, возможностей и структуры вашей организанизации. В начале темы я что-то писал.

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

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

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


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

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

[manjey73]

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

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

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

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

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

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

[kosmos440o]

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

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

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

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

[kosmos440o]

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

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

[manjey73]

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

Мастер скада 500 точек 30 тыс. рублей на одного клиента,
ОРС сервер 500 точек 4000 руб.

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

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

[l-nikolaev]

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

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



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

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

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

[kosmos440o]

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



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

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

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

[manjey73]

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

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

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


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

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

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

[kosmos440o]

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

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

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


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

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

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

[manjey73]

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

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

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

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

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

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

[kosmos440o]

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

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

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

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

[manjey73]

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 штук минимум.

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

[kosmos440o]

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

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

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

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

Сообщение отредактировал kosmos440o - 29.11.2020, 0:31

Прикрепленные файлы

 Приточки_при__33.jpg ( 417,82 килобайт ) Кол-во скачиваний: 12
 ScreenHunter_20_May._24_20.15.jpg ( 308,03 килобайт ) Кол-во скачиваний: 15
 IMG20201119204026.jpg ( 5,21 мегабайт ) Кол-во скачиваний: 14

 

[kosmos440o]

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

Сообщение отредактировал kosmos440o - 29.11.2020, 0:48

[manjey73]

ИБП - 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 показать только то, что нужно в обыденности.

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

[l-nikolaev]

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



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

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

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

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

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

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

..

Ну например общедомовой счетчик взять - порядка 40 каналов с 3-х фазника Меркурий 230 - но ведь в визуализации столько не нужно, сумма мощности, напряжение и ток по фазам и потребленная энергия. Все.
...

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

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

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

[manjey73]

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 канал - администрируйте не выползая из кресла.

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

[l-nikolaev]

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

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

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

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

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

[manjey73]

l-nikolaev

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

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

[mr.trololo]

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

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

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

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

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

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

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

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

[manjey73]

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

[l-nikolaev]

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

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

[Slava_sl]

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

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

[l-nikolaev]

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

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

[manjey73]

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

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

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

Сообщение отредактировал manjey73 - 1.12.2020, 12:54

[kosmos440o]

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

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

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

[l-nikolaev]

....Скучно.

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

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

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

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

[l-nikolaev]

Как вариант, можно совместить последнюю милю связи для экономии, лифты и остальное. ...

Да, конечно.

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


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

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

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

[l-nikolaev]

..
Описанная мной архитектура с промПК на один МКД способна развиваться в разных направлениях. ..

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

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

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

[kosmos440o]

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

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

Сообщение отредактировал kosmos440o - 2.12.2020, 23:17

[l-nikolaev]

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

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

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

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

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

[manjey73]

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

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

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

[kosmos440o]

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

[l-nikolaev]

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

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

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

система Попроще, железо: муниципальный дом, многоэтажка, квартир на 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тр.
Визуализация (т.е. сама СКАДа +ее конфирурирование) -тут Вы мне скажите...

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

Сообщение отредактировал l-nikolaev - 3.12.2020, 8:28

[l-nikolaev]

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

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

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

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

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

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

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

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

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

... Жильцы? Вы эти морды видели?)))

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