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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

потому и

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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



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





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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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