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

Т.е. если 5-7 лет назад очень малый процент заказчиков в ЖКХ готов был дослушать до конца предложение о внедрении таких систем, затем, с течением времени, ситуация перешла в разряд "Диспетчеризация ? удаленный контроль и управление ? - да ! нужно ! но нет денег ", то теперь появилась тенденция "всё есть, ничего не надо, . и тем что есть - не пользуемся".

Поделитесь, пож-та, своими наблюдениями на сей счет. После внедрения диспетчерских систем различного функционала - какая обратная связь от заказчика ?
Работает ли заказчик с вашей системой или она просто "есть" ?

Ну кстати, из последнего - сделали диспетчеризацию складского комплекса, включая близстоящие объекты инженерного обеспечения. Заказчик пользуется, результатом доволен. Диспетчерская служба заказчика состоит из пяти человек, работают посменно уже полгода.
Это, конечно, не сфера ЖКХ, но системы, по сути, те же самые: Г(Х)ВС, отопление, электроэнергия и т. п.

Змей едите!?
Нет!
Да вы просто, их не умеете готовить!

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

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

Появляются, конечно в жилом секторе УК "нового образца", а вернее с руководителями новой закваски, которые хотят контролировать, считать, экономить. В конце концов, им просто интересно делать всё качественно, для людей. Но в процентном соотношении, таких меньше 5%.

Может это у нас в провинциальном Екатеринбурге, в столицах иначе, не знаю.

По сути, многие внедряемые системы - только для галочки, для отчета расходования бюджетных средств, для "выполнения программ энергосбережения". В кавычках, потому что все программы и всё энергосбережение - на бумаге.

Было бы очень интересно мнение коллег из Москвы, Спб, других городов - увидели вы за последние годы положительную динамику в плане образованности, желания применить действительно стоящие решения у заказчиков ЖКХ, или это бесконечное болото, и заниматься продвижением инноваций - борьба с ветряными мельницами ?

Вот казалось бы , простейший пример - удаленный сбор данных и формирование отчетов потребленного тепла. Более половины заказчиков до сих пор отвечает, что проще постоянно нанимать/менять/искать новых студентов, нежели подключить УКУТы в сеть, и получать не только готовые отчеты, но и в любой момент видеть текущие параметры. Да что там текущие параметры, видеть хотя бы - на месте ваш теплосчетчик , или его уже "срезали" и несут на барахолку - реальный пример из жизни )))


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

Понимаете-ли в чем дело.

УК в ЖКХ не будет вкладывать деньги в развитие технологий, ППР, и пр. Причина банальна. Многие УК живут на объекте от 1 до 3-х лет. Избрали нового председателя ТСЖ, или на Собрании ТСЖ решили сменить УК -и все, привет, вложенные деньги пропали.

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

У нас в городе сложилась ситуация, что структуры бывших ЖЭКов, переименовавшись в ООО УК, РЭМПы и тп, оставили под собой огромные районы. Видимо активность населения низка, и менять такие "совковые" УК никто не собирается/не хочет . Это в большей степени присуще старому жилому фонду.

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

Все зависит от службы эксплуатации. Делал 4 года назад диспетчеризацию вентиляции в одном ТРЦ. Так вот там был грамотный киповец в службе эксплаутации - так он пользовался системой по полной. Его все устраивало (арендаторы постоянно просили сделать по теплее/по холоднее, включить - включить и т.д.). Бегать по большому техэтажу и по другим этажам для изменеия режимов работы и для проверки работоспособности не приходилось. Через 2 года он уволился, за компом стали работать все кому не лень, подключили интернет, накачали порно, засорили комп вирусами, все умерло. Гарантия закончилась, оплачивать наши работы толи не захотели, толи по политическим причинам к нам не обратилися, эксплуатация на диспетчерскую забила и сейчас там обслуживающий персонал бегает по этажам, у них теперь ежедневные обходы и постоянный бег по полосе препятствий через воздуховоды Бывает и такое.

да. но ведь бывает еще хуже.
Например я сделал диспетчеризацию котельной, но за системой следят диспетчеры слабо представляющие себе процессы в котельной. В случае аварийных или предупредительных сигналов начинают сразу звонит, Вот и получается, что звонит диспетчер в 3 часа ночи и орет бодрым голосом - "у меня авария" (а проблема в низком давлении на Т3, которую система автоматизации решает за 5-10 минут после ее появления). Чувствую скоро они меня до инфаркта доведут. Вот думайте теперь кому делать систему диспетчеризации а кому нет. Лично я уже пожалел.

загадочная русская душа

Все чаще прихожу к выводу, что диспетчеризация для множества заказчиков остается модной игрушкой, не воспринимается как инструмент повышения эффективности работы. Какие нужны условия , чтобы стали не только внедрять, но и пользоваться ? Показываешь примеры, делишься наработками с других объектов, обучаешь персонал и руководство - с большим трудом перестраиваются. Упрощаешь интерфейсы, делаешь "дружелюбные конфигурации", облегчаешь возможность работы с системой - "народ безмолвствует".
Работая с ЖКХ, отказались от лицензирования рабочих мест пользователей, то бишь от классических SCADA. Чтобы не заморачивались с установкой программ, со сменой/настройкой компьютеров, операционных систем и т.п. Дали возможность любому количеству пользователей получать доступ к объекту с любого компа, подключенного к Интернет - воспринимается порой как нечто фантастическое, хотя уже 21 век на дворе. Ждать смены поколений ?

Конечно, ждать! Только вот беда, когда вымрет всё старое поколение, некому будет учить, тем самым тонкостям, о которых не пишут в учебниках и не учат в институтах!

Обратная связь от заказчика бывает, если что-то не работает. Наша система похоже работает! Потому как заложена возможность расширения и время от времени докупаются модули сбора информации.
Так что ждать не приходится.

диспетчеризируете какие типы объектов ?

Газовые котельные.

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

Я бы сказал, более финансово обоснованный подход.
На главной котельной круглосуточно дежурит человек, остальные "не обслуживаемые" передают информацию на главную. Если где то проблема - выезжает спец.
6 ... 14 объектов обслуживает 3 человека.

По структуре обЪектов в этом году в нашей компании жилье вынырнуло на 1 место по объемам и грандиозности ( и по напичканности) скажу так 4 жилых комплекса 400 , 150, 130, 65 тыс кв. метров.
Все более менее приличное оснащено вениляцией, пожаркой, охранкой, видеонабл. И проектируем сейчас так же. Торговые комплексы и офисные центры отдыхают, хотя и их немало.

Или странное выполнение тех программ, бегает вся администрация свет выключает, при том что это не основной потребитель, но самый наглядный



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



У нас обычно не котельная, а диспетчерская в удобном месте, 1 комната.

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

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

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

Дык грамотному инженеру платить надо... А сколько надо заплатить той бабушке - да в разы меньше.

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

А какая альтернатива? Сажать оператора в котельную на 500 кВт?

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

Я говорю что это ИМХО. По гостам\снипам в котельной должен быть диспетчер. Либо в котельной либо в диспетчерской с удаленым управлением. Да еще и в диспетчерской должно быть дублирование основных аварийных сигналов лампами. ПОжалуй про 2-3 котельных я погорячился, но в любом случае при организации работы с подходами описанными выше толку от таких вот диспетчерских не будет.

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

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

на xenta 511 делали? если нет - просветите пож-та?

Тоже интересно. Что за железо, софт иль их комбинацию используете?

Софт пишем сами: обеспечиваем драйверы с устройствами нижнего уровня (теплосчетчики, регуляторы, и проч. автоматика) + web-сервер. клиенту нужен только браузер.
Железо, которе обеспечивает связь с зоопарком на нижнем уровне, - мы постоянно ищем какие-то новые варманты, тестируем, с целью снижения себестоимости решения. Хотя, это более подходит к беспроводным каналам (GSM). В проводном варианте мы уже довольно давно работаем на конвертерах moxa (232/485 в Ethernet). Цена невелика , да и надежные получаются железки + канал защищен. Будет интересно услышать о бюджетных аналогах, если есть личный опыт - поделитесь.
Кстати, спасибо форуму AВОК, о gsm-варианте MT9 узнали именно здесь, сейчас тестируем, надеюсь станет основым решением по каналу GSM, и сможем отказаться от более дорогих собратьев-роутеров.

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

Сейчас свое развитие видим в создании некой платформы, состоящей из набора готовых фунциональных блоков. Использование таких ФБ позволит инженерам-теплотехникам легко связаться с автоматикой на своем объекте, получить все данные, при необходимости - дистанционно управлять.
Основной "цимус" - сделать это можно будет без нашего непосредственного участия, и без привлечения сторонних программистов/киповцев.

Готовим релиз первого ФБ под регулятор данфос ecl. Если кому-то будет интересно, расскажу подробнее, и вскоре смогу поделиться наработкой.

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

тогда в ближайшие дни поделюсь информацией. сейчас завершаем тестирование первого блока.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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