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

[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 аналоговые. Даже установка ХВО и ХВС без СКАДЫ у нас не обходится, не говоря о котельных и подстанциях. А про автоматические линии по производству, так ваще молчу.