Сделали диспетчеризацию. А заказчик-то пользуется ? Опции

[VladimirVCH]

Из разговора с членом правления ТСЖ:

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

Никому ничего не надо.

Сообщение отредактировал VladimirVCH - 11.8.2011, 14:57

[VladimirVCH]

Из разговора с членом правления ТСЖ:

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

Никому ничего не надо.

Сообщение отредактировал VladimirVCH - 11.8.2011, 14:57

[and]

Сделали систему диспетчеризации коммунальных сетей района. Меньше 20-ти объектов - КНС, водозаборные скважины, станции 2-го подъёма и 3 котельные. Котельные включены в систему формально, на каждой круглосуточно сидит оператор, нет возможности дистанционного управления - только мониторинг. Под модернизацию шли только те объекты, укреплённость которых может обеспечить сохранность оборудования. Сразу меняли древние шкафы коммутации и управления на свои новые. Связь по GPRS.
Диспетчерская с круглосуточным дежурством.
Служба автоматизации, инженеры которой проводили пуско-наладку оборудования на объектах, они же должны выезжать на объект при неисправности автоматики.
Весь район территориально разбит на участки, на каждом из которых свои работники - электрики, сантехники, сварщики и т.д. Эти работники к шкафам не прикасаются (специально обучены).
Диспетчер может с АРМа только наблюдать основные технологические параметры, извещения об неисправностях/авариях и докладывать. Не бабушки, молодые мужики, но технологию пока только изучают. При неисправности электропитания объекта диспетчер звонит на участок электрику (в шкафах бесперебойники на 4 часа работы контроллера и связи), при других неисправностях - звонят инженерам службы автоматизации.
Инженер может остановить/запустить любой объект (кроме котельных), менять бОльшую часть настроек с АРМа или с любого компьютера с интернетом, некоторые - только на объекте при подключении к контроллеру.
Например, упало давление в магистрали от скважины на посёлок. Диспетчер звонит инженеру. Инженер смотрит параметры, всё в порядке, но давление ниже уставки, и насос ушёл на максимальную частоту. Проверяет графики параметров - расход резко подскочил. Звонит на участок: - У вас утечка.
Те ищут место утечки, найдут - звонят: - Остановите насос. Инженер дистанционно останавливает станцию. Те ремонтируют. И т.д.
По анализу графиков параметров можно кучу интереснейших данных получить, оптимизировать до упора работу системы, прогнозировать аварии и т.д. Но нужен длительный мониторинг.
Например по росту оборотов скважинного насоса изо дня в день без увеличения суточного расхода, инженер предупреждает начальника участка о приближении ремонта насоса. Но ничего не происходит, пока насос не перестанет обеспечивать пиковый вечерний расход. Тогда уже закажут кран, поднимут насос, воткнут другой и отрапортуют об успешном устранении аварии. Плановый ремонт - это не подвиг, никто не оценит.
О целях: Мечта заказчика - оставить специалистов каждой твари по паре, остальных уволить. И чтоб всё само работало. С объектов дежурных увольняли ещё до окончания пуско-наладки нового оборудования.
На главных КНС дежурных оставили. Так они с первого дня, не дожидаясь срабатывания автоматики по уровню, постоянно переключают шкаф в ручной режим и откачивают емкость до дна. Спрашиваешь - объясняют: так надёжнее. На самом деле - боятся увольнения.
Всех ремонтных специалистов уже наполовину сократили. Оставшиеся, включая инженеров, потенциально заинтересованы в поддержании некоторого разумного уровня аварийности по своей специальности. Диверсий не наблюдалось, но мотив у людей есть. С чего бы вдруг снижаться аварийности? Цель - не потерять работу.
Заказчик заинтересован в использовании по-полному всех возможностей системы, но работает он с ней руками специалистов. А их цели диаметрально противоположны целям заказчика. Всё как в басне Крылова, только щуки не хватает.
Сознательно упомянул оборотную сторону для балансировки впечатления от вечно победно-радостных статей про диспетчеризацию.
На самом деле не всё так плохо, есть чем похвастаться, но пост и так неприлично длинным получился.

[Usach]

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

Сообщение отредактировал Usach - 12.8.2011, 8:23

[Время-не-ждет]

Думаю ваши наработки будут интересны всем..
Ждем ваши варианты

Как обещал , делюсь нашими наработками.

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

Ключевые функции:

-автоматическое определение модели регулятора и используемого приложения (ключа), отображение интерфейса и стандартной схемы в соответствии с приложением;
-отображение текущих значений контролируемых параметров: температур, давлений, состояния насосов;
-отображение аварий и нештатных ситуаций;
-просмотр и изменение требуемой температуры;
-отображение температурного графика для контура отопления + графика теплосети для сравнения (в случае двух контуров отопления – для каждого контура отдельно);
- возможность изменить график регулятора (по 6-ти точкам);
- просмотр расписания комфортных периодов (для каждого контура отдельно);
- легкая возможность изменить расписание периодов;
- просмотр и изменение настроек PI регулятора (отдельно для каждого контура)

Больше информации и возможность поработать самостоятельно в демо-версии: ecl.t2system.ru

Демо-версия, в отличии от реально подключенного регулятора, позволит менять приложения (ключи), и пробовать работу с ними.
Кроме того, в демо-версии будет реализован эмулятор. Вы сможете вносить корректировки в настройки регулятора, и отслеживать изменения. Таким образом, получаем тренажер работы с регулятором, без риска и последствий.

Для пущей наглядности, примерно то же описание, но с картинками, вот здесь

чуть позже дам инфу как подключать свой регулятор. никакого софта у себя ставить не надо будет, всё из браузера. надо будет гсм-модем либо внешку (знать свой IP).

Сообщение отредактировал Время-не-ждет - 12.8.2011, 10:06

[Sergey_12345]

Честно говоря, мне АВОК давно не интересен. Но тут День строителя надвигается....
Итак, по пунктам
1. Danfoss ECL 310. Штука "хорошо известная в узких кругах (с)". ПОЛНОЕ ДЕРЬМО !!!! Обоснование - ИНСТРУКЦИЯ к этому девайсу. Всем понятно, что Тепловые пункты (ИТП, ЦТП) ДОЛЖНЫ работать , как говорится, "до последнего патрона". Отсюда неимоверная навороченность софта, и, как следствие, детальный учет особенностей используемой схемы и оборудования. Резервирование, авторестарты при малейшей возможности, вплоть до эвристического анализа ситуации. Пример последнего - "накрылся" датчик внешней температуры, переходим на Тподачи, этого нет - Тобратки,
учитываем характер климата и т.д. Пока будут ремонтировать, все должно РАБОТАТЬ !!!!
2. Посмотрев "картинки с выставки", тихо охренел - да за такие "фокусы" с ГВС (отклонение 4.5 С) меня бы "изнасиловали". 2 градуса - предел !!! Именно 2 градуса - это гарантия СТАБИЛЬНОЙ работы контура Отопления, ГВС.
Если на ТП "подвешена" вентиляция, то тут вообще все становится "жестью" - стабильность ИТП есть стабильность старта и работы приточек.
3. Интерфейс для браузера - отдельная тема. Искренне считаю - нехрен что-то менять, кроме УСТАВОК контуров, да и то должна присутствовать проверка валидности действия. Во избежание.... Остальные параметры даже незачем мониторить, а уж тем более менять. Если есть дырка, значит она кому-то понадобится.
Ну а насчет оформления - тут "2 балла и без стипендии". 80-е прошли, на дворе 21 век. Бедность оформления есть признак ДИЛЕТАНТИЗМА, и НИКАК не связан со стоимостью проекта.
4. Шесть точек графика - это круто, правда, может все поменялось. График УТВЕРЖДАЕТСЯ, значит - сколько точек УТВЕРЖДЕНО, столько и должно быть. Это - АКИСОМА автоматизации. Тобратки - это "головная боль" для ИТП, именно за это энергоснабжающие организации, по крайней мере - в Москве, "сильно имеют" Зака, а он - Подрядчика. Так что, как ни крути. а эту опцию надо поддерживать особенно тщательно. Чтобы потом не было мучительно БОЛЬНО.
Вот так, приблизительно.............

Сообщение отредактировал Sergey_12345 - 13.8.2011, 9:39

[Au-Fi]

Время-не-ждет, благодарю за информацию. Достаточно интересный проект, понравилось оформление интерфейса оператора из предложенной демо-версии, элегантно и не напряжно, как будто читаешь мануал к контроллеру, только сразу можно кликнуть на настройку и поменять.
Интересует техническая составляющая платформы T-One Platform. Насколько я понял, разработаны функциональные блоки для связи с оборудованием.
1. ФБ разработаны для контроллера индивидуально, или для протокола (на примере ECL310 и modbus)? Если для протокола, то как сложно ФБ настраивается на связь с любым контроллером с данным протоколом?
2. Какие ФБ еще есть (для каких контроллеров/протоколов уже реализованы или в процессе реализации)?
3. Так понимаю, любое устройство с браузером подходит для работы (Windows, iOS (iPhone/iPad), Android, т.д.)?

[Sergey_12345]

Началась "игра в три наперстка" Типа - подставные появились....
Какое оформление интерфейса? Если есть ГРАФИЧЕСКИЕ объекты, "крутите" эту тему дальше! Видно, "слаше морковки ничего не ели". Под современные телефоны надо делать АДЕКВАТНЫЕ вещи. А если под 90-е, то ЗАБУДТЕ про графику!
Да, манагеры ЖИЗНЕУСТОЙЧИВЫ - "ты их в дверь, они - в окно". Щас выползет кто-то еще, и скажет - "Данфосс - это брэнд, это - круто". Если он делает насосы, то остальное - это просто СУПЕР.
ДЕРЬМО получилось, как у всякой НЕПРОФИЛЬНОЙ лабуды. Одним словом, "беда, если сапоги начнет тачать пирожник".
Примеров - масса. НЕ БЫВАЕТ УНИВЕРСАЛЬНЫХ РЕШЕНИЙ, и погоня за баблом не оправдывает уважаемые в своей области бренды.

[Ernestas]

Не собираюсь никого защищать. Но Ваши излияния здесь вообще не в тему. Не нашли подходящей?

[Sergey_12345]

Если - мне. то еще раз повторюсь - МНЕ ЭТО ДО ФОНАРЯ. Просто надоело "разводилово" в разных вариантах. Купите эту хрень Danfoss ECL 310, и все поймете. "Ты все поймешь, ты все увидишь сам"- не мной придумано. Если бы сам не проходил бы через "дешево, надежно и сердито" - не писал бы. "Над пропастью во ржи" - великая книга.

[Время-не-ждет]

to Sergey_12345
Cпасибо за ваше мнение и критику. У вас, наверное, было хорошее настроение, иначе объяснить такое кол-во текста с включенным капслоком не могу
Единственное, насчет наперстков вы погорячились. Я не буду вас убеждать ни в чем, если Au Fi посчитает нужным, ответит за себя сам.

to Au Fi , по вашим вопросам

1. данный ФБ сугубо для контроллеров 210/310 . Над "протокольными" ФБ думаем, надо ли..
2. Это первый готовый ФБ, другие пока в разработке. До сих пор мы занимались подключением каждого объекта индивидуально, ограничиваясь драйверами к различной теплоавтоматике, и когда объем вырос, стало понятно, что это неправильно - нужен иной инструмент, блочная структура. Тем более, сейчас система в основном внедряется не нашими руками (это делают коллеги - монтажные организации и те кто обслуживают укуты), а значит надо дать партнерам максимум предустановленных функций, чтобы их задача ограничилась подключением железа.
Тот же ECL сейчас может подключить любой инженер, хотя бы отдаленно знакомый с понятием IP адрес, гсм-модем и тп.
Следующие ФБ будут основном для регуляторов, и для теплосчетчиков (что касается аппаратуры). Плюс, будут отдельные программные блоки - для аналитики и проч. Источниками данных для них будут фб конкретных устройств.
3. Да, верно.

[Sergey_12345]

Настроение было почти нормальное. Но с мнением автора очень уважаемой мной книги по АСУТП полностью согласен, т.к.
оно, мнение, полностью подтверждается моим многолетним (25 лет) личный опыт работы в АСУТП и АВОК.

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

 p0025_sel.png ( 121,21 килобайт ) Кол-во скачиваний: 136

 

[Mars]

Что за книга? Кто автор? В инете качнуть можно?

[Sergey_12345]

Книгу "качнуть" можно . Правда, она довольно специфична.

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

 OsnovyPostroeniyaASUTP_1.jpg ( 16,53 килобайт ) Кол-во скачиваний: 31

 

[Время-не-ждет]

Настроение было почти нормальное. Но с мнением автора очень уважаемой мной книги по АСУТП полностью согласен, т.к.
оно, мнение, полностью подтверждается моим многолетним (25 лет) личный опыт работы в АСУТП и АВОК.

В этой теме говорим о диспетчеризации в сфере ЖКХ.

[Sergey_12345]

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

[Usach]

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

Ну уж нет!!
Программистов к теплоузлам не пушечный выстрел подпускать нельзя. Обмен данными организовать - это и автоматчик делать должен уметь. По крайней мере "при помощи" того же программиста.
А квалификация обслуги всегда была пипец. Причем полный, потому что вечнопьяный. Это нормальные исходные данные для проектирования. Формально это прикрыто фразой "работа ИТП в автономном режиме без постоянного присутствия обслуживающего персонала" - но мы то с Вами понимаем. Обслуживающий персонал постоянно присутствующий (т.е. работающий в две смены за зарплату) предусмотрен только в ЦТП. Да и то не во всех.
Поэтому про защиту от дурака - это штатные сказочки для зака. В реалии "дурак" только один - тот кто запускает. Потому, что запустит, покурит - и домой. А через час маты от зака и пулей обратно - разбираться почему встало. Разберётся в чем косяк ("Ну я и дурак!!"), исправит. Покурит. И спокойно домой. Через два часа маты от зака - и по новой! И так пока всех блох не выловит. А потом уже все работает в режиме пуск/стоп. И никакие дураки "покруть" не лезут. От кого защищатся то...Это на производственных процессах - там да. Потому, что сами эти процессы и разработаны для того, чтоб операторы (дураки) их "крутили". А ИТП - система статичная. Запустили - сама топит. Пришли остановили. Всё.

[Sergey_12345]

Типа оффтопа.
"Программист в АСУТП" - это не просто дядька, рисующий таинственные значки на экране и вечно лохматый от постоянного чесания репы в поиске ответа на вопрос "Какого хрена это не работает и что этой падле еще надо?"
Это только ИТ-шники такие
Главный вопрос АСУшника-Прогаммиста "Почему ЭТО вдруг заработало, что я тут такого сделал. Записывать надо было.."
А если серьезно - программист должен отлично знать технику, с которой объект его автоматизации будет работать. подсказать проектировщику потенциально узкие места в проекте , типа "задолбаемся реализовывать", или "добавь чуть-чуть оборудования и получим конфетку". Слово Автоматчик мне как-то мало понятно. Если это тот гипотетический инженер, на которого все более ориентируются производители оборудования - это плохо для потребителя.
Идеология такова - мы за тебя все продумали, ты только все параметры правильно опиши, и будет тебе счастье. Не будет - будет "головняк" у всех. Ну и в том же духе можно продолжать дальше. Последний пример из роботехники - ориентированный на простого инженера мануал в 12 000 страниц. Программистская терминология - после 10 страницы,
причем с недетскими заворотами.
А манагеры руки потирают - как все просто: купил-поставил, что-то там за 10 мин ввел, и объект "на клюшке". Можно еще и на откате поживится. Ну а если не работает - руки у тех, кто параметризировал, кривые.
Далее, все просто. Конфигурирование - типовая схема проетирования - выдавливание специалистов и подсадка на свою продукцию. Пусть дрянь, зато никуда никто не денется. Короче, наше мнение - ваш выбор.

Сообщение отредактировал Sergey_12345 - 17.8.2011, 11:17

[Usach]

"Слово Автоматчик мне как-то мало понятно"

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

Сообщение отредактировал Usach - 17.8.2011, 12:12

[Sergey_12345]

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

[Usach]

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

[Sergey_12345]

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

[Время-не-ждет]

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

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

[Sergey_12345]

to Время-не-ждет
Уважаемый, это Вы судя по всему. плохо понимаете, что такое Диспетчеризация. Уж не серчайте
Диспетчеризация строится исходя из конкретных задач по автоматизации. Возьмем ЖКХ, пусть так.
1. Если все нормально, ио и ладно. Сижу, курю.
2. Никому нахрен не надо смотреть на всякие графики. Если отклонения от штатного режима не фатальны, то и пес с ними.
Можно просигнализировать желтым цветом, общепринятым для нефатальных аварий. С этими делами может, если захочет, разбираться соотвествующий персонал. Диспетчеру. как правило, эти графики до фонаря. Равно как и мелькание цифр на экране. Уставки надо прятать тоже подальше, чтобы искушения не было.
3. Аварийная ситуация. Вот тут-то и настало время показать, насколько грамотно построен софт. Скорость локализации аварии - вот что главное. Это потом можно разбираться, что случилось, и как до этого докатились. 90-95% софта на это направлены. И это всем интересно.
4. Отчетность. Это тоже интересная вещь, если Заку это надо.
Так что обсуждать надо пункт 2 и 3. Еще можно поговорить об эргономике. Все ж с "дружелюбной и современной" системой как-то удобнее.
Так вот, "живучесть" и "локализация аварий" в том же Данфоссе - твердую 2.
Задача у того же ИТП - работать по единожды утвержденному плану и алгоритму, давать воду и ВСЕ. Под эту задачу и строится диспетчеризация. Перед тем, как делать АРМ в производстве, я всегда начинал с опроса работяг : как им удобнее. И только потом что-то ваял. А не наоборот. Здесь же "телега вперед лошади ставится".

[Usach]

to Время-не-ждет
Уважаемый, это Вы судя по всему. плохо понимаете, что такое Диспетчеризация. Уж не серчайте
Диспетчеризация строится исходя из конкретных задач по автоматизации. Возьмем ЖКХ, пусть так.
1. Если все нормально, ио и ладно. Сижу, курю.
2. Никому нахрен не надо смотреть на всякие графики. Если отклонения от штатного режима не фатальны, то и пес с ними.
Можно просигнализировать желтым цветом, общепринятым для нефатальных аварий. С этими делами может, если захочет, разбираться соотвествующий персонал. Диспетчеру. как правило, эти графики до фонаря. Равно как и мелькание цифр на экране. Уставки надо прятать тоже подальше, чтобы искушения не было.
3. Аварийная ситуация. Вот тут-то и настало время показать, насколько грамотно построен софт. Скорость локализации аварии - вот что главное. Это потом можно разбираться, что случилось, и как до этого докатились. 90-95% софта на это направлены. И это всем интересно.
4. Отчетность. Это тоже интересная вещь, если Заку это надо.
Так что обсуждать надо пункт 2 и 3. Еще можно поговорить об эргономике. Все ж с "дружелюбной и современной" системой как-то удобнее.
Так вот, "живучесть" и "локализация аварий" в том же Данфоссе - твердую 2.
Задача у того же ИТП - работать по единожды утвержденному плану и алгоритму, давать воду и ВСЕ. Под эту задачу и строится диспетчеризация. Перед тем, как делать АРМ в производстве, я всегда начинал с опроса работяг : как им удобнее. И только потом что-то ваял. А не наоборот. Здесь же "телега вперед лошади ставится".

О чем и писалось - почему я и не люблю "программистов" в ЖКХ...
К Вашему удивлению (сведению) автоматика ставиться не только для того, чтобы регулировать технологический процесс на уровне "Если все нормально, ио и ладно", но и для того, чтоб в случае аварийной ситуации именно та же автоматика и отработала "грамотно" и либо "спасла" установку, либо перевела её в аварийный режим работы.
А то Вас почитать - то получается, что до изобретения компьютера всё ЖКХ работало по принципу: у каждой приточки, на каждом ИТП круглосуточно, в две смены, дежурили слесаря с отвёрткой и газовым ключом, чтоб в случае аварии отработать "грамотно".А теперь - всё! 21 век!! Теперь отрабатывает "грамотно построенный софт". Главное, чтоб компьютер не подвисал, софт просрочен не был, ,была устойчивая связь (ну и что, рвануло! Ну и что, что всё сварилось! Всё равно кабель ещё вчера порвали - когда трассу ремонтировали!!!) и да - конечно ещё электричество!! А то вдруг свэта нэт - а на объекте авария?!!

[Sergey_12345]

Друг мой, Вы удивительно догадливы! Я, собственно, об этом и говорю - все готовится к нештатным ситуациям. Внимательно читать - уже признак чего-то. Что было до изобретения компьютеров, я тоже могу рассказать - но это будет неинтересно. Мы говорим о том,что есть. Мудрее говорит о том, что будет. Но не получется.

[Inch]

Господа, давайте все-таки разделять Диспетчеризацию и Работу системы в аварийных случаях. Вроде спорить не о чем.

Система в общем случае должна отрабатывать все что можно, без вмешательства. Об остальном сигнализировать.
А вот самим, как инсталляторам и при обслуживании она, по-моему нужнее даже, чем заказчику.
Вроде как так:

про защиту от дурака - это штатные сказочки для зака. В реалии "дурак" только один - тот кто запускает. Потому, что запустит, покурит - и домой. А через час маты от зака и пулей обратно - разбираться почему встало. Разберётся в чем косяк ("Ну я и дурак!!"), исправит. Покурит. И спокойно домой. Через два часа маты от зака - и по новой! laugh.gif И так пока всех блох не выловит.

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

[Mars]

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

О, да!
Был как-то случай. В еще не сданном, но частично заселенном здании работала система вентиляции. Она уже контролировалась автоматикой и была подключена с системе диспетчеризации. Как всегда это бывает, случай произошел в пятницу поздним вечером. В ИТП сорвало какой-то манометр и начался потоп. Прибежал дежурный сантехник, перекрыл ввод теплосети и пошел забивать чопик в отверстие. После чего снова открыл ввод и пошел отдыхать. Естесственно, вентиляцию на это время он не выключал. Мороз был около -20. Естесственно, приточка успела замерзнуть и отработать по угрозе заморозки. Но, как говорится, поздно пить боржоми. Калорифер замерз крепко. И, конечно, вода не сразу побежала, а только когда калорифер потихоньку оттаял. О том, что случилась катастрофа узнали по сработке пожарной сигнализации. Когда дежурные снова прибежали в подвал, то там было по колено воды.
Зак первым делом хотел нахлобучить нас - автоматчиков. Конечно! Это же всемогущая автоматика не смогла уберечь приточку от замерзания. Благо, что все писалось в тренды. Нашли падение давления на вводе (перекрытие после прорыва), снижение температуры, отработку угрозы заморозки, открытие клапана, останов вентилятора, закрытие заслонок и т.д. Все это распечатали и показали. Зак призадумался, стал допрашивать дежурного сантехника, но тот, партизан, не сознавался. Тогда пошли обследовать ИТП и там обнаружили чопик и следы фонтана. Под неопровержимыми уликами сантехник сознался, а нас отпустили с миром.
Вот такая история. :-)

[Lex]

To Mars

Что-то мне кажется, зря вас отпустили с миром....
И падение давления вы отследили, и падение температуры....
И защита ОТ заморозки отработала....
А приточка все-равно замерзла....
Не сходится что-то.
ИМХО, защита от для того и делается, чтобы защитить от, а не допустить.

[alsz]

To Mars

Что-то мне кажется, зря вас отпустили с миром....
И падение давления вы отследили, и падение температуры....
И защита ОТ заморозки отработала....
А приточка все-равно замерзла....
Не сходится что-то.
ИМХО, защита от для того и делается, чтобы защитить от, а не допустить.

Все сходиться.
Автоматика правильно отработала, ну если тепла взять не откуда, то автоматика в этом уже ни чем не поможет.
Чем в -20 сантехник мог обогреть калорифер? Если в ИТП давление упало.

[Mars]

To Mars

Что-то мне кажется, зря вас отпустили с миром....
И падение давления вы отследили, и падение температуры....
И защита ОТ заморозки отработала....
А приточка все-равно замерзла....
Не сходится что-то.
ИМХО, защита от для того и делается, чтобы защитить от, а не допустить.

Ээээ.... Простите, если теплоносителя нет, то чем греть-то? Автоматика сама по себе калорифер греть не может. Теплоносителя просто нет.
У Вас когда дома горячую воду оключают, а Вы кран на всю громкость открываете - начинает течь горячая вода?
И закрытие заслонок в моем случае не помогло, т.к. от заслонки до улицы 50 см воздухозаборной камеры. Заслонка не может закрыть на 100% поступление холодного воздуха (но это уже к изготовителям заслонок или приточки).