Малая автоматизация, или как два байта переслать

Немного обо мне

Я занимаюсь промышленной автоматикой. Буквально от головы до задницы, т.е. от полевого уровня (датчики/исполнительные механизмы) до верхнего (программирование ПЛК/разработка SCADA). Так получилось, что больше всего я занимался наладкой, но последний год — преимущественно разработкой. Кроме того, для меня программные и аппаратные средства делятся на Siemens и всё остальное.

О проекте

Суть проекта заключается в обновлении систем автоматики на довольно большом количестве насосных станций (водонапорных и канализационных). Кроме собственно обновления, была поставлена задача собирать и передавать текущие значения ряда параметров в общую диспетчерскую для централизованного архивирования и наблюдения. Территориально всё это хозяйство находится в Нижней Галилее, в Израиле.
На момент начала работ средства автоматики на разных станциях представляли собой весьма разнообразный зоопарк: от контроллеров ET-200S CPU на более свежих станциях до релейной логики на более старых. На текущий момент на разных станциях работают контроллеры Siemens, Twido (Schneider), Koyo, GE Fanuc.
Получилось так, что формально этот проект реализует Schneider Electric, наша компания является субподрядчиком. Это определило выбор SCADA для диспетчерской (Vijeo Citect) и контроллеров для станций, где требуется их замена.

Особенности и сложности

А их не так много. Главная и почти единственная — как передавать технологическую информацию со станций, достаточно удалённых друг от друга, в диспетчерский центр. Для этой цели была использована система от компании Realiteq. Идея довольно простая: компания продаёт свои устройства (внутренности от Motorola), которые имеют ModBus интерфейс (возможно использовать RS-232, 485, Ethernet), сотовый терминал и конфигурируются с помощью специальной утилиты. Далее, эти терминалы получают данные по Modbus и передают их сервер компании. За это компания берёт абонентскую плату, точный размер которой мне неизвестен. Чтобы получить эти данные и использовать их в SCADA, необходимо установить другую утилиту — OPC-сервер, который через интернет запрашивает данные с сервера компании и отдаёт по протоколу OPC.
Конфигурация, хранимая в самом модуле — минимальная. Это имя проекта, имя узла в проекте (узлов может быть несколько), настройки для соединения с контроллером и настройки сотового терминала.
Вот так выглядит сам терминал:

Все настройки данных, которыми терминал обменивается в ПЛК, выполняются уже через веб-интерфейс или через специальную утилиту. «Доступа к телу» уже не требуется, нужен только интернет. Так выглядит веб-интерфейс:

Кроме сбора данных, в веб-интерфейсе есть минимальная функциональность SCADA, т.е. можно реализовать простейшие картинки.

А вот так выглядит водонапорная станция на экране оператора в системе Citect:

Естественно, что все надписи на иврите — не забываем, где находится проект 🙂 В двух словах, на этом экране мы видим уровень воды в ёмкости, состояние поплавковых датчиков уровня (верхний, нижний и два промежуточных — слева на ёмкости), состояние всех трёх насосов (серый — отключен, зелёный — в работе, красный — неисправность), очерёдность включения (номер в окошке над каждым насосом), давление воды на входе и на выходе насосной станции, уставки уровней (сигнализация полной/пустой ёмкости, уровень отключения насосов, уровень включения первого насоса, уровень включения резервного насоса). Внизу — график изменения уровня за последние 12 часов, история хранится 3 года.

Дополнительные сложности с водонапорными станциями

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

Вернёмся к нашему проекту. Эта территориальная удалённость и создаёт главную сложность. Ёмкость вместе с датчиком уровня расположена слишком далеко от насосной и в разное время предпринимались попытки обеспечить связь по радиоканалу, но на момент внедрения нашего проекта эта система не работала по неизвестным мне причинам.
Но система сбора данных, которую мы используем, позволяет нам не только получать данные, но и передавать их между разными станциями внутри проекта. Таким образом, задачи контроллера на расходной ёмкости минимальны: получить сигнал с датчика уровня (4..20 мА), преобразовать в инженерные единицы и по протоколу Modbus отдать его наверх и на насосную. Этот регистр Modbus и есть те самые 2 байта, вынесенные в заголовок, без которых не может работать насосная. На первом скриншоте я обвёл красным исходный регистр и регистр-получатель во втором контроллере.
На самом деле, этот контроллер передаёт чуть больше информации. В процессе эксплуатации возможно такое, что на насосной мы видим: уровень снизился, пора наполнять ёмкость. И включаем насос. Насос работает, ёмкость наполняется, и в какой-то момент теряется связь. Уровень в ёмкости растёт, а на контроллер насосной информация не поступает. И ёмкость переполняется.
Чтобы этого не допустить, мы передаём с ёмкости на насосную ещё одно значение. Это счётчик, значение которого увеличивается каждую минуту. Так же раз в минуту контроллер насосной сохраняет полученное значение и сравнивает с предыдущими четырьмя. Если все они совпадают, значит, уже 5 минут мы имеем потерю связи.
На насосной же, при каждом пуске насосов, одновременно с ними стартует таймер, уставку которого можно изменять. Если таймер закончил отсчёт и контроллер «видит» потерю связи — насосы останавливаются. Таким образом реализована защита.

Состояние проекта на сегодняшний день

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

И, на десерт, общий вид на деревню, где расположены насосная и расходная ёмкость: