Automated system for determining heat lossesof the educational audience. Hardware part

Full Text

Вопрос коммунальных платежей в России волнует жителей стабильно остро. Это неудивительно т. к., по данным Федеральной службы государственной статистики, за 10 лет цены поднялись более чем в 2 раза (см. таблицу 1) [1] и составляют значительную часть от бюджета семьи [2]. Одним из самых дорогих ресурсов является отопление. Ситуация с юридическим лицами обстоит ещё сложнее, так как применяемые к ним тарифы существенно выше (иногда в несколько раз) чем для физических лиц.

 

Таблица 1 – Индексы потребительских цен на товары и услуги, процент, РФ,период с начала отчетного года в % к соответствующему периоду предыдущего года (январь)

	2011	2012	2013	2014	2015	2016	2017	2018	2019	2020	2021	итого за 10 лет
Жилищно-коммунальные услуги	111,9	102,4	109,6	109,8	109,8	109,8	105,4	104,3	106	102,79	103,35	205,8
Коммунальные услуги	113,4	101,7	110,5	111,1	105,2	109,1	105,4	104,4	106,8	102,31	103,76	202,9
Отопление	112,5	101,1	110,5	111,2	105,8	109,7	104,9	103,6	105,6	102,23	103,41	197,3

 

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

Внедрение системы индивидуального регулирования в каждом помещении представляется интересным вариантом для решения указанной проблемы. Главным недостатком такой системы являются высокие вложения на этапе внедрения. Достоинством – повышение комфорта нахождения в помещении за счет точного дозирования поступающего тепла. «Комфорт» всегда был всегда «дорогой опцией», но в данном случае он может окупиться за относительно короткий промежуток времени за счет сокращения затрат на коммунальные платежи.

Для определения теплопотерь в помещении и, как следствие, возможной экономии потребления тепла была создана «цифровая лаборатория» на базе аудитории 450 3-го корпуса Югорского государственного университета. Общая структурная схема проекта показана на рисунке 1.

 

Рисунок 1. Структурная схема проекта «Цифровая лаборатория»

 

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

На первом этапе следует определиться с архитектурой системы и сетевого взаимодействия.

Получаемую от датчиков информацию необходимо хранить в базе данных, а также выводить ее в удобном для пользователя виде. Таким образом, в системе необходимо предусмотреть сервер для сбора, хранения и вывода данных.

При выборе средств сетевого взаимодействия был поставлен ряд требований:

1. масштабируемая архитектура;
2. простота конструкции;
3. двусторонний обмен данными;
4. промышленный стандарт.

Под эти требования прекрасно подходит интерфейс RS-485 – один из наиболее распространенных стандартов физического уровня. Физический уровень – это канал связи и способ передачи сигнала (1 уровень модели взаимосвязи открытых систем OSI) [3]. Простота интерфейса, с одной стороны, является достоинством, с другой, – недостатком, ведь он предусматривает передачу только одного байта. В качестве протокола более высокого уровня обычно применяют ModBus [4]. Минусом указанного протокола является работа по принципу «запрос-ответ», т. е. наличие одного главного устройства (master) и множества ведомых (slave). Транзакцию может начинать только ведущее устройство, а ведомые устройства обязаны ответить на запрос. С другой стороны, это позволяет не задумываться о явлениях коллизии при отсутствии схемы арбитража.

Счетчик тепла

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

На рынке бытовой теплосчетчиков свою продукцию представляют более десятка фирм, при этом передачу телеметрии предлагают в различных вариантах: интерфейс-импульсный выход, MBus [5] и RS-485. Более экзотические и менее применяемые, такие как Bluetooth, LoRa и прочие, в данной статье не рассматриваются.

Реализация системы с импульсным выходом требует использования дополнительного оборудования в виде счетчика импульсов. В случае использования интерфейса MBus, возникает необходимость наличия преобразователя RS-485 в MBus. Третий вариант с использованием интерфейса RS-485 представляется наиболее простым. Как уже указывалось выше, интерфейс RS-485 является интерфейсом физического уровня и не накладывает ограничений на канальный уровень. На рынке можно найти теплосчетчики с собственным протоколом канального уровня, MBus (используется только протокол).

В результате исследования рынка выбран теплосчетчик SANEXT Mono RM с интерфейсом RS-485 [6]. Несмотря на использование нестандартного протокола, он хорошо документирован [7]. Эта особенность и наличие его в продаже определили выбор прибора.

 

Рисунок 2. Теплосчетчик SANEXT Mono RM

 

Рассмотрим подробнее используемый протокол. Устройства, работающие по протоколу SANEXT, взаимодействуют по модели master-slave. Данные предаются пакетами по интерфейсу RS-485. Формат байт 8N1. Битовая скорость 9600 бит/с.

Общая структура передаваемых пакетов выглядит следующим образом. На рисунке 3 представлена структура пакета запроса от ведущего устройства.

 

ADDR

F

L

DATA_IN

ID

CR16

Рисунок 3. Структура пакета запроса от ведущего устройства

 

Пакет запроса состоит из следующий полей:

• ADDR – сетевой адрес устройства (4 байта) в формате BCD, старшим байтом вперед.
• F – код функции запроса (1 байт);
• L – общая длина пакета (1 байт);
• DATA_IN – входные данные запроса (длина определяется F);
• ID – идентификатор запроса (любые 2 байта);
• CRC16 – контрольная сумма (uint16_t) 2 байта младшим байтом вперед.

На рисунке 4 представлена структура пакета ответа от ведомого устройства.

 

ADDR

F

L

DATA_OUT

ID

CR16

Рисунок 4. Структура пакета ответа от ведомого устройства

 

Пакет ответа состоит из следующий полей:

• ADDR – сетевой адрес устройства (4 байта) в формате BCD, старшим байтом вперед.
• F – код функции (1 байт);
• L – общая длина пакета (1 байт);
• DATA_OUT – входные данные ответа (длина определяется F и DATA_IN);
• ID – идентификатор запроса (2 байта присутствующие в ID запроса);
• CRC16 – контрольная сумма (uint16_t) 2 байта младшим байтом вперед.

Приборы, работающие по протоколу SANEXT, возвращают значения параметров в формате числа с плавающей точки одинарной точности float32, либо в формате числа с плавающей точкой двойной точности double64.

Терморегулирование

В качестве исполнительного механизма для ограничения потока тепла изначально был установлен обычный кран, который не позволяет подключиться к автоматическому терморегулятору. Для решения этой проблемы ручной вентиль был заменен на клапан (рисунок 5а), который будет применяться совместно с сервоприводом (рисунок 5б). Сервопривод такого типа осуществляет бесшумное управление (в отличие от моторизированный вентилей) за счет встроенного нагревателя и работающего по принципу расширения от нагрева с последующим давлением на клапан. Время открытия/закрытия лежит в пределах 3–5 минут.

 

Рисунок 5. Клапан управления батарей отопления (а); Сервопривод клапана

 

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

• Максимально простой монтаж: во внешнюю монтажную коробку или din-рейку (с соблюдением правил безопасности).
• Ограничение доступа к изменению настроек температуры терморегулятора.

В результате было решено доработать собственное устройство терморегулятора, применяемое в системах «умный дом» [8]. Доработка заключается в замене радиомодуля на проводной интерфейс RS-485. Электрическая принципиальная схема устройства приведена на рисунке 6.

В основе схемы лежит микроконтроллер STM32F030F4P6 фирмы STMicroelectronics [9]. Преобразователь UART-RS485 не показан, он в виде небольшого модуля устанавливается на разъем P5, а линия pf0 служит сигналом W/R. Питается устройство напряжением 5–12В. В качестве датчиков температуры используются готовые интегральные микросхемы DS18B20 (рисунок 7) [10] со следующими параметрами.

• Для однопроводного интерфейса 1-Wire достаточно одного порта связи с контроллером.
• Каждое устройство имеет уникальный серийный код длиной 64 разряда.
• Возможность подключения нескольких датчиков через одну линию связи.
• Нет необходимости во внешних компонентах.
• Возможность получать питание непосредственно от линии связи. Напряжение питания в пределах 3,0 В … 5,5 В.
• Диапазон измерения температуры -55 ... +125 °C.
• Погрешность не превышает 0,5 °C в диапазоне -10 ... +85 °C.
• Разрешение преобразования 9…12 бит. Задается пользователем.
• Время измерения не превышает 750 мс при максимально возможном разрешении 12 бит.
• Возможность программирования параметров тревожного сигнала.
• Тревожный сигнал передает данные об адресе датчика, у которого температуры вышла за заданные пределы.

 

Рисунок 6. Электрическая принципиальная схема терморегулятора

 

Алгоритм работы терморегулятора

Микроконтроллер после запуска настраивает периферийные модули:

• порты ввода-вывода;
• UART;
• таймер.

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

При поступлении посылки от ведущего устройства контроллер сохраняет ее в буфере с целью последующего декодирования в соответствии с протоколом ModBus. Для чтения данных используются стандартные ModBus-команды 3 и 4, которые в данном случае являются равнозначными и обращаются к единому адресному пространству регистров ModBus. Для записи используются команды 6 и 16. Структура данных для работы с протоколом ModBus показана на листинге 1

Листинг 1

typedef struct {

unsigned int rxtimer;   //  *** этим считаем таймаут (не используется т.к. используется аппаратный таймаут по приему)

unsigned char delay;    //  *** задержка (не используется т.к. используется аппаратный таймаут по приему)

unsigned char buffer[256];//буфер для хранения запроса

uint16_t reg [reg_col];//буфер для хранения регистров

unsigned char rxcnt;    //количество принятых символов

unsigned char txcnt;    //количество переданных символов

unsigned char txlen;    //длина посылки на отправку

unsigned char rxgap;    //окончание приема

} UART_DATA;

 

Рисунок 7. Внешний вид датчика температуры DS18B20 в корпусе TO-92

 

Два датчика температуры подключаются к портам микроконтроллера PA.0 и PA.1. Подключаются они по трем проводам GND, Data, VCC. Паразитное питание не используется.

Код опроса датчика температуры по интерфейсу 1-wire представлен на листинге 2.

Листинг 2

if ( flag_tim3 & 1){    // если пора опрашивать первый датчик температуры и канал регулятора не отключен

flag_tim3 &=~1;

ow_a_sendAll(0x4e); //настройка датчика

ow_a_sendData(0xff);

ow_a_sendData(0xff);

ow_a_sendData(0x1f);

Delay_ms(50);

ow_a_sendAll(0x44);     //начало преобразование температуры

Delay_ms(94*100);       // 100*100 -- 100 ms for 9 bit; 800*100 for 12 bit

ow_a_sendAll(0xbe);     //получение регистра с температурой

*t1=ow_a_getData16();

ow_a_reset();

TempRegulator(1, *t1);

}

По результатам опроса датчика внутренней температуры показания передаются в функцию TempRegulator (1, *t1) в которой произойдёт сравнение текущей температуры с желаемой с учетом гистерезиса, и в результате будет принято решение о включении или отключении подачи тепла в батарею отопления. Так как для управления сервоприводом используется напряжение 220В, то для платы предусмотрен ключ для коммутации переменного напряжения на основе силового симистора и управляющего оптосимистора.

Все переменные и регистры ModBus находятся в едином адресном пространстве с различными функциями и ссылаются на него посредством механизма указателей. Пример приведен на листинге 3.

Листинг 3

extern UART_DATA uart1;

uint16_t* t1=&uart1.reg[0];

uint16_t* t2=&uart1.reg[1];

uint16_t* temp_1=&uart1.reg[2];   // уставка температуры канала 1

uint16_t* temp_2=&uart1.reg[3];   // уставка температуры канала 2

uint16_t* reg_1=&uart1.reg[4];    // состояние регулятора 1

uint16_t* reg_2=&uart1.reg[5];    // состояние регулятора 2

Сервер

При разработке программы к ней были предъявлены следующие требования:

• операционная система – Ubuntu Linux;
• база данных – MySQL [11, 12];
• взаимодействие с оборудованием осуществляется по протоколу ModBus и SANEXT.

Тестирование программы

Для проверки работоспособности сбора данных от терморегулятора и теплосчетчика была написана консольная программа на языке Python3, которая периодически опрашивает устройства, указанные в базе данных. Если устройство не найдено, то выводится сообщение «invalid response from device», в противном случае выводятся показания на экран. Результат представлен на рисунке 8.

 

Рисунок 8. Запуск программы

 

Заключение

В результате была реализована аппаратная часть системы удаленного автоматического сбора информации и управление инженерным оборудованием в помещении. В дальнейшем данную систему планируется объединить с системой контроля удаленного доступа ЮГУ [13, 14].

About the authors

Evgeniy A. Godovnikov

Yugra State University
st. 16 Chekhov

Author for correspondence.
Email: judchin@rambler.ru

Associate Professor for the Institute of Digital Economy

Candidate of Physical and Mathematical Sciences

Russian Federation, Khanty-Mansiysk

Olga A. Petuhova

Yugra State University
st. 16 Chekhov

Email: oa_petuhova@mail.ru

Candidate of Physical and Mathematical Sciences, Associate Professor for the Institute of Digital Economy

Russian Federation, Khanty-Mansiysk

Tatiana V. Pronkina

Yugra State University
st. 16 Chekhov

Email: t_pronkina@ugrasu.ru

Candidate of Physical and Mathematical Sciences, Associate Professor for the Institute of Digital Economy

Russian Federation, Khanty-Mansiysk

Ruslan T. Usmanov

Yugra State University
st. 16 Chekhov

Email: r_usmanov@ugrasu.ru

Senior Lecturer for the Institute of Digital Economy

Russian Federation, Khanty-Mansiysk

Anatoliy V. Shitselov

Yugra State University
st. 16 Chekhov

Email: anatoliy.shitselov@gmail.com

Lecturer for the Institute of Digital Economy

Russian Federation, Khanty-Mansiysk

References

Supplementary files