В предыдущей части статьи мы рассмотрели этап начала проектирования системы. Сейчас я хочу рассказать какое устройство получилось в итоге.
Часть 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-реле отключит у них какую-то нагрузку и перезапустится :-)
В заключение хочу сказать, за последние два года мы произвели почти тысячу таких устройств. Все они находятся в «онлайне». Ещё около двух тысяч других контроллеров также постоянно общаются с нашим сервером. В целом всё работает достаточно устойчиво. Хотя функционал мы, конечно, постоянно расширяем. Например, недавно мы выпустили моб. приложение для удалённого управления нашими устройствами через Интернет. Но о нём напишу как-нибудь в следующий раз…
