А теперь, если отойти от уровня понимания реальности десктопными программистами.
Все алгоритмы крутятся не на скаде, а в контроллере. Залезть в который значительно сложнее. И если по условиям работы какой-то конкретный кран нельзя открыть (либо закрыть), контроллер и не даст этого сделать. Просто я достаточно натрахался повозился с наладкой, чтобы представлять это…
А если кто-то почему-то часть логики вынес из контроллера в скаду — тому следует умереть в муках.
Варианты «перепрошить контроллер», да ещё и скриптом удалённо — любопытно. Про Stuxnet я тоже слышал. И не только я. Вот только никто его не видел, почему-то :)
А я вот категорически не дружу с безопасностью. Мне проще (в самом крайнем случае) снести и переставить к чёрту винду на компе с нуля, намазать офис и VMware и вернуться к работе.
Просто, помимо серьёзного железа приходится иметь дело со всяким дешёвым говном, авторы которого знают толк в извращениях хитрых коммуникациях через любопытный порт, который чем-то не нравится антивиру. А ты сиди и ломай башку полдня, почему ж никак не получается до этой чёртовой железки достучаться…
Представил я себе, как автор вопроса внедрится в S7-400H, и подменит там программу в обоих контроллерах (3 раза ха) :))
На всякий случай, разверну мысль. S7-400H — это физически дублированный контроллер. Две половинки, связанные оптической пуповиной. Обновление программы происходит следующим образом: останавливаем один контроллер (пожалуйста, у нас уже без палева в логах есть информация о том, что один контроллер встал), загружаем в него новую программу и просим (именно, никак иначе) систему перейти с одного контроллера на другой. И никогда на 100% заранее не знаешь, что система ответит. А есть 2 варианта: переход возможен (и он выполняется) либо переход невозможен: контроллер, по своим соображениям, считает, что изменения слишком большие и требуется полная остановка, загрузка обеих половинок и рестарт.
Или внедриться на Profibus (закрытый протокол) и слать левые данные… Конечно, если это получится, я сниму (и, возможно, даже съем) свою шляпу. Но я искренне не понимаю, зачем такие сложности. Есть уйма более простых, надёжных, дешёвых и быстрых способов поставить производство раком. В большинстве случаев это называют человеческим фактором :))))
Есть у них такая штука — IRT (isichronous realtime) на профинете. Но как мне когда-то объяснила поддержка, оно заточено для синхронизированного управления приводами.
Он сам по себе несколько странный, а вот за графический редактор его авторам точно гореть в аду. Там не предусмотрено возможности задать координаты и размеры элемента в его свойствах, введя конкретные цифры. Только мышкой.
А если, при этом, требуется сделать какие-то косметические поправки удалённо, через TeamViewer, например… Шоб этим австралийцам в аду гореть :)
не свалится. Надо только вставить в программу (и загрузить в контроллер) OB80.
Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.
Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
Одинаковая наработка оборудования — это фантастика, сферический конь в вакууме.
Потому, что один насос — это не просто насос, а вся нитка от входного до напорного коллектора (сам насос, задвижки, обратный клапан, трубы) плюс часть электрической схемы (частотный привод/софтстартер, выключатель, датчики). Если хоть где-то есть неисправность, то насос выводится из работы, работают другие. А если объект ещё время от времени работает в ручном режиме — то тем более, персонал наработкой не грузится совсем.
Фирменные контроллеры относительно дороги, да. Однако, рабочее время (и спокойный сон) довольно большого количества специалистов тоже чего-то стоит ;)
Отказ от готовых, проверенных и надёжных контроллеров в пользу самоделок, во-первых, увеличит (пропорционально, а то и экспоненциально масштабам проекта) геморрой (и затраченное время) у разработчиков, монтажников, наладчиков и эксплуатантов.
Резервирование «в ящике стола» недостаточно надёжного оборудования годится только для совершенно не ответственных объектов автоматизации. Только не ответственные объекты никто не автоматизирует :)
Там не скважины, а водопровод на входе. Просто давления не хватает.
Сделать можно много, даже в космос запустить, но основная идея — чередовать насосы, чтобы их наработка была более-менее равномерна.
Для электроэнергии там есть мультиметр с Modbus, но контроллер с него данные не читает. Мастер на Modbus — сотовый терминал, контроллер и мультиметр ведомые. Все интересующие параметры отправляются на сервер и архивируются. Кроме того, мультиметр общий на всю станцию и если, например, в работе 2 насоса, то неизвестно, который сколько потребил. Есть только общие данные, на вводе.
По-хорошему, так сильно паковать и не стоило: плюшкинизм какой-то :)
Отдельный регистр под статусы, отдельный — под уставку таймера, отдельный — под текущее значение таймера.
Или бились за уменьшение объёма данных с целью сэкономить на лицензии для SCADA? ;)
За что люблю Siemens — ему не надо каждый раз объяснять алгоритм «как почесать левую пятку», он это на уровне операционки делает. Но вот Modbus и Siemens в моей практике до недавнего был тяжело совместимым. Но с относительно новым их модулем для ET-200S (он ещё и недорогой, кстати) стало полегче :) До этого всегда старались использовать шлюзы AnyBus.
PS а кроме геморроя со связью есть ещё фильтрация аналоговых значений + диагностика каналов, фильтрация дребезга дискретных входов… В общем, даже на мелочёвку иногда руки чешутся PCS намазать :)
Этот сервер принадлежит конторе, которая обслуживает много таких проектов. У них резервированный канал в инет, хороший сервер, специальные люди занимаются его поддержкой. И зачем это делать самим? Данные не настолько секретные. Я бы сказал, что для третьей стороны они вообще ценности не представляют. А ставить другие железки/VPN… Так опять, если свалится — кто поедет поднимать? Да и контроллеры стоят разные, Ethernet есть, пожалуй, только в сименсовских. И 232 порт не во всех есть — большей частью 485. Общего — только Modbus. Т.е. придётся практически, полноценный компьютер ставить, поднимать на нём Modbus/интернет шлюз, и упихивать его в обычный электрошкаф по соседству не только с контроллером, но и с пускателями, частотными приводами и софт-стартерами. На эту железку, опять же, надо что-то намазать. А ещё там напряжение может внезапно пропасть и внезапно возникнуть. И что со всем этим делать?
А если вернуться к нашему объекту и вспомнить, что это просто сеть говнокачек и водокачек в арабских деревнях, постоянно на станциях никто не сидит и дежурный заглядывает раз в день. А дежурный этот — араб из этой же деревеньки. Они далеко не все достаточно толковые. Но кофе варят вкусный :)
Короче, совершенно ни к чему на этом проекте городить такой огород и разрабатывать такое, почти уникальное, решение — звезду говнокачки просто. Надо, наоборот, максимально простое, надёжное и тиражируемое решение.
А что до обнаружения пропажи связи — опрос идёт по умолчанию раз в минуту, для важных параметров можно цикл опроса уменьшить. Но даже в этом нет необходимости. Это не мирный советский трактор, который за минуту успеет вертикально взлететь и сделать 10 залпов :)
Соответственно, счётчик опрашивается раз в минуту. Увеличивается на 1, для надёжности, раз в полминуты. На другой стороне полученное значение обновляется тоже раз в минуту. Насколько синхронно всё это делается — не критично. Сравнивать 2 соседних цикла опроса тоже недостаточно надёжно. И смысла в булевой переменной тоже особо нет. Конечно, Modbus позволяет адресовать и передавать отдельные биты («катушки») — т.е. булевые переменные. Но эта промежуточная система под «катушки» не очень заточена, а заточена под обычные регистры Modbus. А это слово, т.е. 2 байта. Соответственно, все дискретные, булевские сигналы тоже передаются упакованными в слова.
Защита, как раз, простейшая. Была ещё мысль сделать таймер, который отсчитывает, сколько времени прошло с падения связи при работающем насосе и по тайм-ауту (если связь не вернулась) отключать. Но остановились на первом варианте. На самом деле, даже такой вариант работает вполне приемлемо.
А поставить клапан и ресивер… Это значительный объём работ, один клапан чего стоит: там труба четырёхсотка минимум. Кроме того, к клапану привод нужен, а туда только недавно полноценное электричество провели: до этого там стояла солнечная панелька и 2 аккумулятора и ночью контроллер иногда терялся. А тут ещё такой кран крутить :) А без ресивера можно и вовсе обойтись, линия достаточно длинная, сама сойдёт за ресивер.
Короче — возможно, они дозреют и захотят сделать что-то подобное, но это не наша головная боль, мы только автоматикой занимаемся.
На самом деле, на другой такой расходной ёмкости, которую мы ещё не успели обасучить, я видел подобное решение. Только там клапан стоит гидростатический, т.е. прямого действия.
А связь нужна в любом случае, т.к. в конторе желают иметь возможность видеть уровень дистанционно, в архивы его писать… Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.
А теперь, если отойти от уровня понимания реальности десктопными программистами.
Все алгоритмы крутятся не на скаде, а в контроллере. Залезть в который значительно сложнее. И если по условиям работы какой-то конкретный кран нельзя открыть (либо закрыть), контроллер и не даст этого сделать. Просто я достаточно
натрахалсяповозился с наладкой, чтобы представлять это…А если кто-то почему-то часть логики вынес из контроллера в скаду — тому следует умереть в муках.
Варианты «перепрошить контроллер», да ещё и скриптом удалённо — любопытно. Про Stuxnet я тоже слышал. И не только я. Вот только никто его не видел, почему-то :)
А я вот категорически не дружу с безопасностью. Мне проще (в самом крайнем случае) снести и переставить к чёрту винду на компе с нуля, намазать офис и VMware и вернуться к работе.
Просто, помимо серьёзного железа приходится иметь дело со всяким дешёвым говном, авторы которого знают толк в
извращенияххитрых коммуникациях через любопытный порт, который чем-то не нравится антивиру. А ты сиди и ломай башку полдня, почему ж никак не получается до этой чёртовой железки достучаться…На всякий случай, разверну мысль. S7-400H — это физически дублированный контроллер. Две половинки, связанные оптической пуповиной. Обновление программы происходит следующим образом: останавливаем один контроллер (пожалуйста, у нас уже без палева в логах есть информация о том, что один контроллер встал), загружаем в него новую программу и просим (именно, никак иначе) систему перейти с одного контроллера на другой. И никогда на 100% заранее не знаешь, что система ответит. А есть 2 варианта: переход возможен (и он выполняется) либо переход невозможен: контроллер, по своим соображениям, считает, что изменения слишком большие и требуется полная остановка, загрузка обеих половинок и рестарт.
Или внедриться на Profibus (закрытый протокол) и слать левые данные… Конечно, если это получится, я сниму (и, возможно, даже съем) свою шляпу. Но я искренне не понимаю, зачем такие сложности. Есть уйма более простых, надёжных, дешёвых и быстрых способов поставить производство раком. В большинстве случаев это называют человеческим фактором :))))
Он сам по себе несколько странный, а вот за графический редактор его авторам точно гореть в аду. Там не предусмотрено возможности задать координаты и размеры элемента в его свойствах, введя конкретные цифры. Только мышкой.
А если, при этом, требуется сделать какие-то косметические поправки удалённо, через TeamViewer, например… Шоб этим австралийцам в аду гореть :)
Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.
Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
Как хорошо было бы, если б депутаты не были идиотами и не совались со своими инициативами в интернет и к блоггерам…
Потому, что один насос — это не просто насос, а вся нитка от входного до напорного коллектора (сам насос, задвижки, обратный клапан, трубы) плюс часть электрической схемы (частотный привод/софтстартер, выключатель, датчики). Если хоть где-то есть неисправность, то насос выводится из работы, работают другие. А если объект ещё время от времени работает в ручном режиме — то тем более, персонал наработкой не грузится совсем.
Отказ от готовых, проверенных и надёжных контроллеров в пользу самоделок, во-первых, увеличит (пропорционально, а то и экспоненциально масштабам проекта) геморрой (и затраченное время) у разработчиков, монтажников, наладчиков и эксплуатантов.
Резервирование «в ящике стола» недостаточно надёжного оборудования годится только для совершенно не ответственных объектов автоматизации. Только не ответственные объекты никто не автоматизирует :)
Сделать можно много, даже в космос запустить, но основная идея — чередовать насосы, чтобы их наработка была более-менее равномерна.
Для электроэнергии там есть мультиметр с Modbus, но контроллер с него данные не читает. Мастер на Modbus — сотовый терминал, контроллер и мультиметр ведомые. Все интересующие параметры отправляются на сервер и архивируются. Кроме того, мультиметр общий на всю станцию и если, например, в работе 2 насоса, то неизвестно, который сколько потребил. Есть только общие данные, на вводе.
Отдельный регистр под статусы, отдельный — под уставку таймера, отдельный — под текущее значение таймера.
Или бились за уменьшение объёма данных с целью сэкономить на лицензии для SCADA? ;)
За что люблю Siemens — ему не надо каждый раз объяснять алгоритм «как почесать левую пятку», он это на уровне операционки делает. Но вот Modbus и Siemens в моей практике до недавнего был тяжело совместимым. Но с относительно новым их модулем для ET-200S (он ещё и недорогой, кстати) стало полегче :) До этого всегда старались использовать шлюзы AnyBus.
PS а кроме геморроя со связью есть ещё фильтрация аналоговых значений + диагностика каналов, фильтрация дребезга дискретных входов… В общем, даже на мелочёвку иногда руки чешутся PCS намазать :)
Дешёвый он. Вот, пожалуй, главный плюс.
А если вернуться к нашему объекту и вспомнить, что это просто сеть говнокачек и водокачек в арабских деревнях, постоянно на станциях никто не сидит и дежурный заглядывает раз в день. А дежурный этот — араб из этой же деревеньки. Они далеко не все достаточно толковые. Но кофе варят вкусный :)
Короче, совершенно ни к чему на этом проекте городить такой огород и разрабатывать такое, почти уникальное, решение — звезду говнокачки просто. Надо, наоборот, максимально простое, надёжное и тиражируемое решение.
А что до обнаружения пропажи связи — опрос идёт по умолчанию раз в минуту, для важных параметров можно цикл опроса уменьшить. Но даже в этом нет необходимости. Это не мирный советский трактор, который за минуту успеет вертикально взлететь и сделать 10 залпов :)
Соответственно, счётчик опрашивается раз в минуту. Увеличивается на 1, для надёжности, раз в полминуты. На другой стороне полученное значение обновляется тоже раз в минуту. Насколько синхронно всё это делается — не критично. Сравнивать 2 соседних цикла опроса тоже недостаточно надёжно. И смысла в булевой переменной тоже особо нет. Конечно, Modbus позволяет адресовать и передавать отдельные биты («катушки») — т.е. булевые переменные. Но эта промежуточная система под «катушки» не очень заточена, а заточена под обычные регистры Modbus. А это слово, т.е. 2 байта. Соответственно, все дискретные, булевские сигналы тоже передаются упакованными в слова.
А поставить клапан и ресивер… Это значительный объём работ, один клапан чего стоит: там труба четырёхсотка минимум. Кроме того, к клапану привод нужен, а туда только недавно полноценное электричество провели: до этого там стояла солнечная панелька и 2 аккумулятора и ночью контроллер иногда терялся. А тут ещё такой кран крутить :) А без ресивера можно и вовсе обойтись, линия достаточно длинная, сама сойдёт за ресивер.
Короче — возможно, они дозреют и захотят сделать что-то подобное, но это не наша головная боль, мы только автоматикой занимаемся.
На самом деле, на другой такой расходной ёмкости, которую мы ещё не успели обасучить, я видел подобное решение. Только там клапан стоит гидростатический, т.е. прямого действия.
А связь нужна в любом случае, т.к. в конторе желают иметь возможность видеть уровень дистанционно, в архивы его писать… Уже выдвинули пожелания на усовершенствование: сделать 2 временные зоны с двумя наборами уставок включения/отключения насосов. Смысл в том, что хотят сэкономить электричество днём, когда тариф на него выше, чтоб ночью ёмкость наполнить по максимуму, а днём оттягивать включение насосов до последнего.