Comments 25
Таки да-а-а… поучительно. Вопрос: у этого проекта государственная аккредитация?
P.S.: А нас ещё в 2000-м на мех-мате «убивали» за скриншоты с красными подчёркиваниями из Word.
P.S.: А нас ещё в 2000-м на мех-мате «убивали» за скриншоты с красными подчёркиваниями из Word.
Довольно сложная реализация защиты.
Можно поставить после насоса ресивер с датчиком давления, а наверху клапан, управляемый с контроллера расходной станции.
Контроллер расходной станции видит переполнение, и закрывает клапан.
Контроллер насосной станции видит повышение давления и отключает насос.
И связи никакой не нужно, получается.
Можно поставить после насоса ресивер с датчиком давления, а наверху клапан, управляемый с контроллера расходной станции.
Контроллер расходной станции видит переполнение, и закрывает клапан.
Контроллер насосной станции видит повышение давления и отключает насос.
И связи никакой не нужно, получается.
Защита, как раз, простейшая. Была ещё мысль сделать таймер, который отсчитывает, сколько времени прошло с падения связи при работающем насосе и по тайм-ауту (если связь не вернулась) отключать. Но остановились на первом варианте. На самом деле, даже такой вариант работает вполне приемлемо.
А поставить клапан и ресивер… Это значительный объём работ, один клапан чего стоит: там труба четырёхсотка минимум. Кроме того, к клапану привод нужен, а туда только недавно полноценное электричество провели: до этого там стояла солнечная панелька и 2 аккумулятора и ночью контроллер иногда терялся. А тут ещё такой кран крутить :) А без ресивера можно и вовсе обойтись, линия достаточно длинная, сама сойдёт за ресивер.
Короче — возможно, они дозреют и захотят сделать что-то подобное, но это не наша головная боль, мы только автоматикой занимаемся.
На самом деле, на другой такой расходной ёмкости, которую мы ещё не успели обасучить, я видел подобное решение. Только там клапан стоит гидростатический, т.е. прямого действия.
А связь нужна в любом случае, т.к. в конторе желают иметь возможность видеть уровень дистанционно, в архивы его писать… Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.
А поставить клапан и ресивер… Это значительный объём работ, один клапан чего стоит: там труба четырёхсотка минимум. Кроме того, к клапану привод нужен, а туда только недавно полноценное электричество провели: до этого там стояла солнечная панелька и 2 аккумулятора и ночью контроллер иногда терялся. А тут ещё такой кран крутить :) А без ресивера можно и вовсе обойтись, линия достаточно длинная, сама сойдёт за ресивер.
Короче — возможно, они дозреют и захотят сделать что-то подобное, но это не наша головная боль, мы только автоматикой занимаемся.
На самом деле, на другой такой расходной ёмкости, которую мы ещё не успели обасучить, я видел подобное решение. Только там клапан стоит гидростатический, т.е. прямого действия.
А связь нужна в любом случае, т.к. в конторе желают иметь возможность видеть уровень дистанционно, в архивы его писать… Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.
Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.
хинт!
1. можно еще считать электроэнергию на насосах скважин и их производительность (по расходомерам). На основании этих данных определять эффективность каждой скважины и запускать в работу лучшие из них. Если местные технологи позволят, конечно.
2. можно еще вывести насосы скважин на оптимальные режимы по реально измеренным напорно-расходным характеристикам.
3. можно еще много всяких штук наделать — если интересно, в личку пишите )
Там не скважины, а водопровод на входе. Просто давления не хватает.
Сделать можно много, даже в космос запустить, но основная идея — чередовать насосы, чтобы их наработка была более-менее равномерна.
Для электроэнергии там есть мультиметр с Modbus, но контроллер с него данные не читает. Мастер на Modbus — сотовый терминал, контроллер и мультиметр ведомые. Все интересующие параметры отправляются на сервер и архивируются. Кроме того, мультиметр общий на всю станцию и если, например, в работе 2 насоса, то неизвестно, который сколько потребил. Есть только общие данные, на вводе.
Сделать можно много, даже в космос запустить, но основная идея — чередовать насосы, чтобы их наработка была более-менее равномерна.
Для электроэнергии там есть мультиметр с Modbus, но контроллер с него данные не читает. Мастер на Modbus — сотовый терминал, контроллер и мультиметр ведомые. Все интересующие параметры отправляются на сервер и архивируются. Кроме того, мультиметр общий на всю станцию и если, например, в работе 2 насоса, то неизвестно, который сколько потребил. Есть только общие данные, на вводе.
Странно видеть слово «таймаут» на Иврите :)
Сбор данных посредством некой железяки, отдающей их на не принадлежащий ни заказчику, ни Вам, сервер мне кажется потенциально ненадежным звеном. Раз уж на всех объектах есть интернет, не оказалось ли бы дешевле и прозрачнее поднять VPN-сервер и пусть ваши полевые точки сбора данных к нему коннектятся? Ну или роутер там какой-нибудь глупый перед ними поставить, если сами точки не умеют VPN?
Алгоритм обнаружения обрыва связи между ПЛК я реализовывал чуть иначе: заводил булевую переменную, в которую раз в несколько секунд с удаленного ПЛК записывал true, при этом раз в тот же интервал времени локально сбрасывая ее по таймеру в false. Если переменная сохраняет значение false более двух интервалов времени, то минимум один пакет данных был потерян.
Алгоритм обнаружения обрыва связи между ПЛК я реализовывал чуть иначе: заводил булевую переменную, в которую раз в несколько секунд с удаленного ПЛК записывал true, при этом раз в тот же интервал времени локально сбрасывая ее по таймеру в false. Если переменная сохраняет значение false более двух интервалов времени, то минимум один пакет данных был потерян.
Этот сервер принадлежит конторе, которая обслуживает много таких проектов. У них резервированный канал в инет, хороший сервер, специальные люди занимаются его поддержкой. И зачем это делать самим? Данные не настолько секретные. Я бы сказал, что для третьей стороны они вообще ценности не представляют. А ставить другие железки/VPN… Так опять, если свалится — кто поедет поднимать? Да и контроллеры стоят разные, Ethernet есть, пожалуй, только в сименсовских. И 232 порт не во всех есть — большей частью 485. Общего — только Modbus. Т.е. придётся практически, полноценный компьютер ставить, поднимать на нём Modbus/интернет шлюз, и упихивать его в обычный электрошкаф по соседству не только с контроллером, но и с пускателями, частотными приводами и софт-стартерами. На эту железку, опять же, надо что-то намазать. А ещё там напряжение может внезапно пропасть и внезапно возникнуть. И что со всем этим делать?
А если вернуться к нашему объекту и вспомнить, что это просто сеть говнокачек и водокачек в арабских деревнях, постоянно на станциях никто не сидит и дежурный заглядывает раз в день. А дежурный этот — араб из этой же деревеньки. Они далеко не все достаточно толковые. Но кофе варят вкусный :)
Короче, совершенно ни к чему на этом проекте городить такой огород и разрабатывать такое, почти уникальное, решение — звезду говнокачки просто. Надо, наоборот, максимально простое, надёжное и тиражируемое решение.
А что до обнаружения пропажи связи — опрос идёт по умолчанию раз в минуту, для важных параметров можно цикл опроса уменьшить. Но даже в этом нет необходимости. Это не мирный советский трактор, который за минуту успеет вертикально взлететь и сделать 10 залпов :)
Соответственно, счётчик опрашивается раз в минуту. Увеличивается на 1, для надёжности, раз в полминуты. На другой стороне полученное значение обновляется тоже раз в минуту. Насколько синхронно всё это делается — не критично. Сравнивать 2 соседних цикла опроса тоже недостаточно надёжно. И смысла в булевой переменной тоже особо нет. Конечно, Modbus позволяет адресовать и передавать отдельные биты («катушки») — т.е. булевые переменные. Но эта промежуточная система под «катушки» не очень заточена, а заточена под обычные регистры Modbus. А это слово, т.е. 2 байта. Соответственно, все дискретные, булевские сигналы тоже передаются упакованными в слова.
А если вернуться к нашему объекту и вспомнить, что это просто сеть говнокачек и водокачек в арабских деревнях, постоянно на станциях никто не сидит и дежурный заглядывает раз в день. А дежурный этот — араб из этой же деревеньки. Они далеко не все достаточно толковые. Но кофе варят вкусный :)
Короче, совершенно ни к чему на этом проекте городить такой огород и разрабатывать такое, почти уникальное, решение — звезду говнокачки просто. Надо, наоборот, максимально простое, надёжное и тиражируемое решение.
А что до обнаружения пропажи связи — опрос идёт по умолчанию раз в минуту, для важных параметров можно цикл опроса уменьшить. Но даже в этом нет необходимости. Это не мирный советский трактор, который за минуту успеет вертикально взлететь и сделать 10 залпов :)
Соответственно, счётчик опрашивается раз в минуту. Увеличивается на 1, для надёжности, раз в полминуты. На другой стороне полученное значение обновляется тоже раз в минуту. Насколько синхронно всё это делается — не критично. Сравнивать 2 соседних цикла опроса тоже недостаточно надёжно. И смысла в булевой переменной тоже особо нет. Конечно, Modbus позволяет адресовать и передавать отдельные биты («катушки») — т.е. булевые переменные. Но эта промежуточная система под «катушки» не очень заточена, а заточена под обычные регистры Modbus. А это слово, т.е. 2 байта. Соответственно, все дискретные, булевские сигналы тоже передаются упакованными в слова.
Ну в обычном регистре ModBus можно передать 16 битов. Тут же проблема не в ModBus. а в возможностях вашего OPC-сервера. Вот он и не умеет вынимать биты из битовой маски.
Вопрос такой. А почему вся логика сделана на SCADA, а не работает прямо с ModBus? Надежнее было бы защиты написать прямой обработкой ModBus. Потому что комп со SCADA могут обесточить, там может сломаться винчестер, забиться пылью вентилятор и много чего.
Как вообще у вас сделано резервирование на случай отказа компа со SCADA?
Вопрос такой. А почему вся логика сделана на SCADA, а не работает прямо с ModBus? Надежнее было бы защиты написать прямой обработкой ModBus. Потому что комп со SCADA могут обесточить, там может сломаться винчестер, забиться пылью вентилятор и много чего.
Как вообще у вас сделано резервирование на случай отказа компа со SCADA?
Почему не умеет? Спокойно вытаскивает нужный бит из слова.
Станции работают на местных контроллерах. Если связь отвалится, то просто диспетчер не будет видеть актуальные данные. Сервер (который обслуживает связь) стоит в стойке даже не знаю где. Местный компьютер стоит у диспетчера. Короче, работа станций почти не зависит от всего этого хозяйства.
Единственное место, где логика зависит от связи — это бустер (промежуточная насосная) и бочка наверху. Поэтому весьма вероятная ошибка такая: уровень опустился до включения насоса, пропала связь, насосная не видит, что уровень уже вырос и продолжает качать, пока бочка не переполнится. Защиту сделал так. В контролере на бочке есть счётчик, он считывается по связи и передаётся в насосную. Если связь пропадает и не восстанавливается в течение 5 минут, то насосы отключаются.
Станции работают на местных контроллерах. Если связь отвалится, то просто диспетчер не будет видеть актуальные данные. Сервер (который обслуживает связь) стоит в стойке даже не знаю где. Местный компьютер стоит у диспетчера. Короче, работа станций почти не зависит от всего этого хозяйства.
Единственное место, где логика зависит от связи — это бустер (промежуточная насосная) и бочка наверху. Поэтому весьма вероятная ошибка такая: уровень опустился до включения насоса, пропала связь, насосная не видит, что уровень уже вырос и продолжает качать, пока бочка не переполнится. Защиту сделал так. В контролере на бочке есть счётчик, он считывается по связи и передаётся в насосную. Если связь пропадает и не восстанавливается в течение 5 минут, то насосы отключаются.
Интересный опыт.
Делали аналогичный проект на скважинах в Чегдомыне (сами из Хабаровска). Каждая насосная со своим контроллером. Возле насосной — вышка, на вышке — направленный WIFI на «базовую».
ПЛК Siemens S7-300, общаются по ethernet'у. Сделали сценарии, определяющие что делать насосной при пропадании связи с головой: работать\выключиться, работать по расписанию и тд.
Реализовали еще что-то вроде следующего: при понижении уровня вкл одна насосная, если уровень продолжает падать — включается еще одна и тд.
Плюс сделали сортировку по моточасам: каждый раз запускается насос, который меньше всего отработал.
Делали аналогичный проект на скважинах в Чегдомыне (сами из Хабаровска). Каждая насосная со своим контроллером. Возле насосной — вышка, на вышке — направленный WIFI на «базовую».
ПЛК Siemens S7-300, общаются по ethernet'у. Сделали сценарии, определяющие что делать насосной при пропадании связи с головой: работать\выключиться, работать по расписанию и тд.
Реализовали еще что-то вроде следующего: при понижении уровня вкл одна насосная, если уровень продолжает падать — включается еще одна и тд.
Плюс сделали сортировку по моточасам: каждый раз запускается насос, который меньше всего отработал.
А я вот думаю хорошо ли это «сортировка по моточасам». Просто из расчета что насосы стоят однотипные и при одинаковой наработке вероятность отказа у них тоже получается довольно одинаковая. В итоге такой алгоритм может привести к тому что несколько насосов выйдут из строя примерно в одно и тоже время. С одной стороны это может привести к тому что оставшиеся в работе насосы не справятся с нагрузкой, а с другой к тому что затраты на их ремонт будут тоже одновременными, что при текущих методиках планирования затрат на ремонт тоже не очень удобно.
Ваша точка зрения имеет место быть. Ведь все равно — от перестановки слагаемых сумма не меняется)
Однако, при равномерном износе всех насосов — возможно более проще осуществлять техобслуживание — раз в год или с другим периодом группа выезжает по всем скважинам.
А если одни стоит другой работает — приезжают — у одного крыльчатку совсем съело, а другой заржавел от простаивания)))
Однако, при равномерном износе всех насосов — возможно более проще осуществлять техобслуживание — раз в год или с другим периодом группа выезжает по всем скважинам.
А если одни стоит другой работает — приезжают — у одного крыльчатку совсем съело, а другой заржавел от простаивания)))
Одинаковая наработка оборудования — это фантастика, сферический конь в вакууме.
Потому, что один насос — это не просто насос, а вся нитка от входного до напорного коллектора (сам насос, задвижки, обратный клапан, трубы) плюс часть электрической схемы (частотный привод/софтстартер, выключатель, датчики). Если хоть где-то есть неисправность, то насос выводится из работы, работают другие. А если объект ещё время от времени работает в ручном режиме — то тем более, персонал наработкой не грузится совсем.
Потому, что один насос — это не просто насос, а вся нитка от входного до напорного коллектора (сам насос, задвижки, обратный клапан, трубы) плюс часть электрической схемы (частотный привод/софтстартер, выключатель, датчики). Если хоть где-то есть неисправность, то насос выводится из работы, работают другие. А если объект ещё время от времени работает в ручном режиме — то тем более, персонал наработкой не грузится совсем.
Это определило выбор SCADA для диспетчерской (Vijeo Citect).
Кто-нибудь пробовал использовать свободные SCADA, например OpenScada?
Поделитесь впечатлениями.
На текущий момент на разных станциях работают контроллеры Siemens, Twido (Schneider), Koyo, GE Fanuc.… формально этот проект реализует Schneider Electric
Фирменные контроллеры достаточно дорогие.
Я думал о том, чтобы датчики и исполнительные механизмы подключать через недорогие согласующие устройства прямиком к Raspberry Pi. Это было бы как миниум на порядок дешевле. Тогда можно было бы автоматизировать котельные и насосные от масштаба дома до котельной города.
Для надежности тупо дублировать автоматику: 1) на армейский манер делать в стендах двойные схемы; 2) или держать в ящиках стола дополнительный RPi и обвязку.
Кто-нибудь пробовал использовать свободные SCADA, например OpenScada?
Иногда используем MasterSCADA в режиме на 32 точки, т.е. бесплатно.
Впечатления: «Это ужасно, Хаммонд!» (с)
Пробовал Rapid Scada. Аккуратный сайт, понятный программисту процесс настройки, есть структурированная и понятная документация, её не на все случаи хватает. Все мои попытки отредактировать учебный проект потерпели неудачу, дело было в том, что в SQL-БД активировались триггеры, это блокировало практически весь стандартный CRUD-интерфейс. Я сделал вывод, что надо «как-то не так делать», но желание экспериментировать дальше пропало. Это было пол-года назад, сейчас может всё поменялось.
Фирменные контроллеры относительно дороги, да. Однако, рабочее время (и спокойный сон) довольно большого количества специалистов тоже чего-то стоит ;)
Отказ от готовых, проверенных и надёжных контроллеров в пользу самоделок, во-первых, увеличит (пропорционально, а то и экспоненциально масштабам проекта) геморрой (и затраченное время) у разработчиков, монтажников, наладчиков и эксплуатантов.
Резервирование «в ящике стола» недостаточно надёжного оборудования годится только для совершенно не ответственных объектов автоматизации. Только не ответственные объекты никто не автоматизирует :)
Отказ от готовых, проверенных и надёжных контроллеров в пользу самоделок, во-первых, увеличит (пропорционально, а то и экспоненциально масштабам проекта) геморрой (и затраченное время) у разработчиков, монтажников, наладчиков и эксплуатантов.
Резервирование «в ящике стола» недостаточно надёжного оборудования годится только для совершенно не ответственных объектов автоматизации. Только не ответственные объекты никто не автоматизирует :)
Срок наработки на отказ хороших промышленных контролеров — больше 20 лет Это работа при +60, под прямыми солнечными лучами, работа в условиях, когда из воздуха за месяц выпадает миллиметр токопроводящей металлической окалины, работа при 100% влажности, работа, когда в 40 см от платы хлещет дождь…
Возьмите партию Raspberry Pie и проверьте, сколько из них проработает при +60 пару суток без единого сбоя. Один из 100? Ну вот отсюда и разница в цене.
А сколько MTBF у малинки? Год? А цена ремонта? Ах равна цене покупки нового? Ну так получается, что на 20 лет вам нужно иметь 20 малинок в ЗиПе. И это ещё один фактор разницы в цене.
В итоге получается, что дешевле ставить промышленные контроллеры. С их 100% входным контролем деталей перед установкой в плату, с сильно уменьшенными частотами, с копеечным тепловыделением…
А для понимания, что дорого — сравните цену сбоя. Вот сломался контроллер и вода из напорной емкости залила деревню. Что под напряжением — коротнуло, пошли пожары. Сколько будет стоить восстановление деревни? Ну вот и стоит заплатить 0.1% от цены восстановления за контроллер, который не ломается.
Возьмите партию Raspberry Pie и проверьте, сколько из них проработает при +60 пару суток без единого сбоя. Один из 100? Ну вот отсюда и разница в цене.
А сколько MTBF у малинки? Год? А цена ремонта? Ах равна цене покупки нового? Ну так получается, что на 20 лет вам нужно иметь 20 малинок в ЗиПе. И это ещё один фактор разницы в цене.
В итоге получается, что дешевле ставить промышленные контроллеры. С их 100% входным контролем деталей перед установкой в плату, с сильно уменьшенными частотами, с копеечным тепловыделением…
А для понимания, что дорого — сравните цену сбоя. Вот сломался контроллер и вода из напорной емкости залила деревню. Что под напряжением — коротнуло, пошли пожары. Сколько будет стоить восстановление деревни? Ну вот и стоит заплатить 0.1% от цены восстановления за контроллер, который не ломается.
Насколько я знаю, OPC серверов не так много, и все известные мне завязаны на Windows, из-за COM-технологии. Буду рад узнать о том что это не так. Может у кого-то есть опыт с OPC-серверами на других ОС.
Sign up to leave a comment.
Малая автоматизация, или как два байта переслать