Реле

Однажды нам поступил интересный заказ на разработку и производство партии контроллеров для управления элементами наружной рекламы (ЭНР).

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

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

О том как начиналась разработка будет рассказано в первой части статьи.

Итак, мы начали разработку с составления полных технических требований к устройству на основе хотелок заказчика. Для начала был проведён анализ текущего решения, которое уже эксплуатировалось в некоторых аптеках. Оказалось, что там было сделано всё довольно просто. Использовался вот такой электронный таймер:

И всё! Ни ток, ни напряжение не измерялись, никакого информирования, соответственно, тоже не было.

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

Таким образом, в результате эксплуатации этих таймеров заказчик и пришёл к понимаю какой именно функционал он хотел бы получить от нового устройства. Укрупнённо вышло четыре пункта, которые нам следовало реализовать:

1. Включать/выключать вывеску по расписанию, чтобы не получить штраф за работу в ночное время, если вывеска расположена, например, напротив жилого дома. Персонал аптеки часто забывал обесточивать её перед уходом, а также включать с утра.
   А вывеска в городе для аптеки очень важна, потому что её неисправность приводит к потере потенциальных клиентов, которые могут не заметить аптеку на первых этажах зданий.
   
2. Контролировать напряжение и ток. Превышение напряжения всегда сказывается не лучшим образом на любой электронике. Поэтому, чтобы избежать выхода из строя ЭНР, было решено их просто обесточивать в такой ситуации. Большое превышение по току свидетельствует о том, что блок питания ЭНР скоро может выйти из строя, либо произошло замыкание в каких либо отдельных элементах, а низкое потребление что вышли из строя светящиеся элементы или сами источники питания ЭНР.
   
3. Организовать оперативное уведомление о возникших неисправностях посредством отправки SMS-сообщений. Уж не знаю чем не устроило заказчика уведомление через боты различных мессенджеров (Telegram, TamTam, ICQ и пр.), но в ТЗ прописали именно отправку SMS.
   
4. Хранить данные мониторинга (напряжение, токи, состояние реле, флаги срабатывания защиты и т.п.) в базе данных на нашем сервере с доступом к информации через Web-интерфейс.
   

В результате у нас уже вырисовывалось не простое электронное устройство, а целая система, состоящая из железа и информационного ресурса.
После проработки общей архитектуры мы приступили к разработке электрической принципиальной схемы устройства. Для этого её вначале тоже расписали в виде набора функциональных блоков:

• Центральный контроллер со стеком протоколов TCP/IP для доступа к удалённому серверу.
  
• Узел питания.
  
• Узел измерения тока.
  
• Узел измерения напряжения.
  
• Узел управления нагрузками.
  

Основным элементом схемы стал микроконтроллер серии PIC18 и внешний Ethernet-контроллер ENC28J60 фирмы Microchip. К микроконтроллеру мы подключили классическую микросхему часов DS1307 с кварцевым резонатором и литиевой батарейкой.

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

Для узла питания мы использовали AC-DC преобразователь с диапазоном входного напряжения питания 85305В.

Узел измерения тока выполнили на базе токового трансформатора:



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

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

Узел измерения напряжения решено было сделать на базе маленького трансформатора:



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

В общем, все основные узлы выполнены без каких-либо хитрых решений. При этом самым интересным оказался узел управления нагрузками!

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

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



Параметры коммутируемой нагрузки приводятся только для значения cos() = 1. А это, по сути, резистивная нагрузка обычный ТЭН.

Самое интересное, что в документации на таймер этот параметр в явном виде не указан.

Мы провели небольшое экспериментальное исследование и получили следующую табличку со значениями cos() для различных нагрузок:

Измерения проводились специальным прибором APPA 138:



Как известно, в случае превышения тока для заданного типа нагрузки ресурс контактов реле значительно уменьшается и увеличивается вероятность их залипания.

Мы использовали реле серии RT314 для которых максимальный ток указан в 16А. Но с учётом cos() нужно использовать следующие значения:

Также надо отметить, что при максимальном токе количество переключений сильно снижается. Оно составляет всего 50 тыс. циклов.

В нашем случае, однако, максимальный ток не превышал 5А и переключения обычно осуществлялись два раза в сутки. Поэтому запас по мощности реле был довольно ощутимый.

Но всё же, не имея возможности, измерять величину cos() на каждом объекте, мы рекомендовали заказчику все нагрузки мощностью более 100Вт подключать через развязывающие контакторы:

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

В предыдущей части статьи мы рассмотрели этап начала проектирования системы. Сейчас я хочу рассказать какое устройство получилось в итоге.



Часть 1
Часть 2

В обсуждение первой части был затронут вопрос измерения напряжения и тока. Поэтому я решил осветить его более подробно. Как я уже писал ранее, датчиками напряжения и тока у нас в схеме являются трансформаторы. Для измерения напряжения используется миниатюрный трансик BV 201 0145, а для датчика тока AC-1020:



С них снимаются напряжения, которые оцифровываются встроенным в микроконтроллер АЦП. Аналоговая часть показана ниже:



Датчик тока нагружается на резистор R3. Стабилитрон VD3 защищает от резких всплесков напряжения, вызванных короткими бросками тока. Резисторы R2, R4 задают нулевую точку в районе 1,8В. Аналогично сделано для трансформатора напряжения. Только там делитель на резисторах R8 и R10, т.к. трансформатор в нашем случае выдаёт номинальное напряжение 12 В.

Оцифровку мы осуществляем с частотой 1000 Гц в течение 200 мс. На основе полученных значений рассчитываем RMS. Быстрый расчёт квадратов значений мы производим прямо в прерывании. После накопления 200 выборок уже в основном цикле программы осуществляется окончательный расчёт с использованием чисел с плавающей точкой.

Для чего нужно измерение RMS и как его лучше сделать хорошо описано вот в этой статье.

Я уже не раз писал, что при разработке наших устройств мы всегда стараемся максимально использовать самые обычные электронные компоненты, чтобы с одной стороны снизить себестоимость, а с другой стороны не иметь проблем с их поставкой при производстве серии. В данной разработке все используемые резисторы имеют 5% допуск. Естественно, из-за такой погрешности изделия после производства имели большую ошибку при измерении напряжения и тока. Данная ошибка устранялась на автоматизированном калибровочном стенде. Стенд, конечно, звучит немного громко, но свою функцию он исполняет как надо. Состоит стенд из следующих компонентов:

• Набор из трёх галогеновых ламп мощностью по 500 Вт
• Датчик тока, описанный выше
• Электросчётчик Энергомера СЕ102М
• Преобразователь USB-RS-485
• Автоматический выключатель

Счётчик мы используем в качестве образцового измерителя напряжения в сети и тока нагрузок. Модель СЕ102М очень удобна тем, что, во-первых, подключается всего двумя проводами к преобразователю USB-RS-485 (внутри счётчика имеется собственный преобразователь питания), а, во-вторых, не требует для считывания данных ввода серийного номера. Вроде мелочи, но удобства в пользовании счётчиком они прибавляют.

Протокол обмена хорошо описан в руководстве от производителя. Так что сложностей с программной реализацией не возникало.

Кстати, по счётчикам можно отдельную небольшую статью написать. В своё время я с ними плотно работал, в итоге в некоторых наших устройствах реализована поддержка четырёх популярных моделей: Инкотекс-СК Меркурий 206, Энергомера СЕ102, Энергомера СЕ102М и IEK STAR 104/1.

Общий вид стенда получился такой:



Для автоматизации была разработана несложная программа, которая считывает данные со счётчика, управляем встроенными реле контроллера и автоматически подбирает коэффициенты для измерителя тока и напряжения:

Обычно мы используем штрих-коды для серийных номеров наших устройств. Их очень удобно вводить при помощи сканера штрих-кодов:



Но в данном случае девайс был заказным, и заказчик попросил выполнить серийник просто в виде крупных цифр на лицевой панели.

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

Кстати, по поводу MAC-адресов. Мы покупаем их в виде микросхем 24AA025E48-I/SN производства Microchip. При оптовой закупке они обходятся недорого, при этом очень удобны в использовании. MAC-адрес считывается по интерфейсу I2C.

Теперь что касается связи с сервером. На начало разработки основной функционал у нас уже имелся. Это несложный Web-сервис, написанный на ASP.net и отдельная серверная программа для обмена данными с железом. Каждый контроллер раз в минуту передаёт информационный пакет по протоколу UDP. Серверное ПО разбирает его, сохраняет данные в базе (с прореживанием до раза в час) и дополнительно запоминает внешний IP-адрес и порт, с которого пришёл пакет. Это нужно для управления контроллером с сервера.

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

Сразу напишу почему мы используем именно UDP-, а не TCP-соединение, хотя наше устройство, естественно, имеет реализацию обоих протоколов. Выбор UDP обосновывается всего лишь простотой использования и малыми вычислительными затратами как со стороны контроллера, так и со стороны сервера. Да, он не гарантирует доставку пакетов данных, но нужно понимать, что это легко реализуется протоколом более высокого уровня, который работает поверх UDP. Кроме того, при передаче данных мониторинга потеря нескольких пакетов в сутки абсолютна несущественна, особенно учитывая, что при сохранении в базу мы их всё равно прореживаем и сохраняем данные только раз в час. А вот при удалённом управлении контроллером, например, при включении/выключении реле в ручном режиме, работает система запрос-ответ и осуществляется несколько попыток отправки команды.

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

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