Протокол M-Bus (Meter-Bus) является европейским стандартом для централизованных систем сбора данных с приборов учета (тепло, вода, газ, электроэнергия), соответствующим сериям стандартов EN 13757, что подчеркивает его роль как фундаментальной технологии в современной автоматизации коммунального учета.
Введение: Актуальность, цели и задачи дипломного проекта
В условиях постоянно растущих требований к энергоэффективности и точности коммерческого учета энергоресурсов, интегрированные информационно-измерительные системы (ИИС) становятся ключевым инструментом управления. Протокол M-Bus (Meter-Bus) закрепил за собой позицию отраслевого стандарта в Европе и за ее пределами для проводных систем сбора данных со счетчиков. Именно поэтому его детальное изучение и программная реализация имеют высокую практическую ценность.
Актуальность настоящего дипломного проекта обусловлена необходимостью создания гибкого, настраиваемого и экономически эффективного инструмента для тестирования, настройки и сбора данных с оконечного оборудования (Slave-устройств), работающего по протоколу M-Bus. Разработка виртуального прибора (ВП) на платформе LabVIEW позволяет не только решить эту задачу, но и обеспечить высокую степень визуализации, модульности и оперативного управления, что невозможно при использовании стандартных аппаратных Master-контроллеров.
Цель работы: Разработать методологию проектирования и реализовать виртуальный прибор M-Bus Master в среде графического программирования LabVIEW, способный надежно опрашивать и обрабатывать данные с ведомых устройств, с соблюдением всех требований стандарта EN 13757.
Структура ВКР будет включать следующие обязательные разделы: теоретическое обоснование протокола M-Bus (включая детальный разбор канального уровня), описание программной архитектуры ВП в LabVIEW, результаты экспериментальной проверки, а также критически важные для академической работы разделы — Технико-экономическое обоснование (ТЭО) и Безопасность жизнедеятельности (БЖД).
Теоретические основы построения измерительных систем на базе M-Bus
Виртуальный прибор (ВП) представляет собой программно-аппаратный комплекс, который, в отличие от традиционного измерительного прибора, реализует свои функции (сбор, обработка, хранение и визуализация данных) посредством специализированного программного обеспечения, разработанного в графической среде, такой как LabVIEW. В данном контексте ВП выступает в роли Master-устройства в сети M-Bus.
Стандартизация и архитектура протокола M-Bus
Протокол M-Bus — это специализированный протокол, разработанный для передачи данных в сетях приборов учета. Его стандартизация закреплена серией европейских норм EN 13757.
- EN 13757-2 определяет технические требования к физическому и канальному уровням протокола.
- EN 13757-3 регламентирует прикладной уровень, описывая форматы данных, команды и ответы, используемые для передачи измерительной информации.
- EN 13757-4 описывает беспроводной вариант протокола (Wireless M-Bus).
Архитектура M-Bus строго соответствует принципу Master-Slave (клиент-сервер). Ведущее устройство (Master — наш ВП) инициирует все коммуникации, отправляя запросы. Ведомые устройства (Slave — счетчики) только отвечают на запросы Master и никогда не инициируют передачу данных самостоятельно, за исключением сигнализации о наличии данных высокого приоритета.
Принципы физического уровня M-Bus
Физический уровень M-Bus примечателен тем, что использует всего двухпроводную, неполярную медную пару, которая выполняет сразу две функции: передача данных и пассивное электропитание Slave-устройств. Этот подход минимизирует сложность монтажа и снижает общую стоимость системы. Следствием такого инженерного решения является высокая помехоустойчивость и упрощение инсталляции на объектах ЖКХ.
Механизм передачи данных асимметричен:
- Направление Master → Slave (Нисходящий поток):
Мастер передает данные, используя амплитудную модуляцию напряжения питания шины (Vbus).- Логическая «1» (Mark) соответствует номинальному напряжению шины (до 36 В).
- Логическая «0» (Space) соответствует пониженному напряжению (12–24 В).
- Направление Slave → Master (Восходящий поток):
Слейв передает данные путем модуляции тока потребления, не влияя на напряжение шины.- Логическая «1» (Mark) соответствует малому статическому току потребления (не более 1,5 мА), известному как One Unit Load (1 UL).
- Логическая «0» (Space) достигается путем увеличения тока потребления Slave-устройством (10–20 мА).
Типовая скорость передачи данных по M-Bus составляет 2400 или 9600 бод, хотя стандарт допускает широкий диапазон от 300 до 38 400 бод. Обеспечение стабильной скорости является одним из ключевых моментов при настройке VISA-интерфейса в LabVIEW.
Детальный анализ Канального уровня протокола M-Bus (Устранение Слепой Зоны)
Для надежной программной реализации Master-устройства в LabVIEW критически важно понимать структуру кадров и логику канального уровня (Data Link Layer), регламентированного EN 13757-2. Канальный уровень обеспечивает надежную передачу данных между Master и Slave.
Структура и назначение телеграмм M-Bus
На канальном уровне M-Bus использует три основных формата телеграмм (кадров), каждый из которых имеет строгое назначение:
| Тип Кадра | Начальный Байт (Start Byte) | Назначение |
|---|---|---|
| Одиночный символ | E5h |
Подтверждение приема (ACK). Используется Slave для подтверждения получения корректного запроса Master. |
| Короткий кадр | 10h |
Имеет фиксированную длину (5 байт) и используется для коротких команд, например, инициализация Slave (SND_NKE — Send, No Reply, Keep Eye). |
| Длинный/Управляющий кадр | 68h |
Используется для передачи пользовательских данных (RSP_UD — Response, User Data) или сложных запросов. Имеет переменную длину. |
Длинный кадр является наиболее сложным и информационно насыщенным. Он начинается с байта 68h, за которым следует:
- Двойное Поле Длины (L): Длина кадра указывается дважды (байт L и байт L снова), что обеспечивает дополнительный контроль целостности.
- Поле Управляющей Информации (CI — Control Information): Определяет тип команды прикладного уровня (например, запрос данных, чтение конфигурации).
Механизмы адресации и управления связью
Протокол M-Bus предусматривает гибкую систему адресации:
- Первичная Адресация (Primary Addressing): Используется однобайтовое поле адреса (A-Field).
- Адреса от 1 до 250 используются для индивидуального обращения к Slave-устройствам. Теоретический лимит 250 устройств на шине также ограничен суммарным током потребления ($250 \times 1,5 \text{ мА} = 375 \text{ мА}$).
- Адрес
FEh(254) — широковещательный запрос с ожиданием ответа от всех Slave-устройств. - Адрес
FFh(255) — широковещательный запрос без ожидания ответа.
- Вторичная Адресация (Secondary Addressing):
Это критически важный механизм, используемый для выбора прибора по его уникальному вторичному идентификатору (серийный номер, производитель, тип). Он применяется, когда первичный адрес неизвестен или не установлен.- Для инициации процедуры вторичной адресации Master использует псевдо-основной адрес
FDh(253). Вслед за этим адресом Master отправляет полный 8-байтовый вторичный адрес, позволяя найти и сконфигурировать устройство без необходимости физического доступа к нему.
- Для инициации процедуры вторичной адресации Master использует псевдо-основной адрес
Роль управляющих битов в поле C-Field
Поле управления (C-Field) в структуре кадра несет ключевую информацию для обеспечения надежности и контроля потока данных. Использование этих битов является обязательным элементом для разработки устойчивого алгоритма Master в LabVIEW, так как они гарантируют, что Master не будет принимать устаревшие или повторно переданные кадры.
| Бит | Название | Направление | Назначение |
|---|---|---|---|
| Бит 6 | FCB (Frame Count Bit) | Master/Slave | Счетчик кадров. Чередуется при каждом новом запросе/ответе. Позволяет Master определить, не было ли потеряно или дублировано предыдущее сообщение. |
| Бит 5 | ACD (Access Demand) | Slave → Master | Запрос доступа. Если ACD=1, Slave сигнализирует Master о наличии для передачи данных Класса 1 (высокого приоритета, например, аварийных сообщений). |
| Бит 4 | DFC (Data Flow Control) | Slave → Master | Контроль потока данных. Если DFC=1, Slave сигнализирует, что он временно не может принять дальнейшие данные, предотвращая переполнение буфера. |
Проектирование и алгоритмизация Виртуального Прибора Master в LabVIEW
Разработка ВП в LabVIEW требует строгого методологического подхода, основанного на принципах виртуального приборостроения и надежности связи. Разве не для того мы выбираем LabVIEW, чтобы максимально упростить процесс отладки и визуализации сложной логики протокола?
Архитектурные особенности LabVIEW и использование VISA
Виртуальный прибор в LabVIEW структурируется на двух уровнях:
- Лицевая Панель (Front Panel): Графический интерфейс пользователя, содержащий элементы ввода (Controls) и вывода (Indicators) — кнопки, графики, таблицы, цифровые индикаторы. В контексте M-Bus Master, здесь размещаются настройки COM-порта, поле ввода адреса Slave, индикаторы состояния связи и таблица для отображения считанных данных.
- Блок-диаграмма (Block Diagram): Программный код, реализованный в виде графических узлов, соединенных проводами. Именно здесь реализуется логика протокола M-Bus.
Для управления последовательным портом (RS-232, USB-COM), к которому подключен преобразователь M-Bus/RS-232, используется набор функций VISA (Virtual Instrument Software Architecture). VISA предоставляет стандартизированный интерфейс для работы с различными типами аппаратных ресурсов.
Ключевые функции VISA для реализации M-Bus:
- VISA Configure Serial Port: Установка параметров порта (скорость (baud rate), паритет (Even), стоп-биты, бит данных).
- VISA Write: Отправка байтов команды M-Bus (например,
10h A C 16hдля SND_NKE). - VISA Read: Чтение ответа от Slave-устройства (например,
E5hили длинный кадр данных).
Разработка логики управления на основе Конечного Автомата
Для управления сложным, последовательным протоколом, таким как M-Bus, который включает таймауты, проверку ответов и обработку ошибок, наиболее оптимальным и надежным шаблоном проектирования в LabVIEW является Конечный Автомат (State Machine).
Конечный Автомат реализуется с использованием структуры циклов While Loop и Регистров Сдвига (Shift Registers). Регистр сдвига хранит и передает переменную состояния (строковую или числовую) между итерациями цикла, а структура Case Structure выполняет код, соответствующий текущему состоянию.
Полная диаграмма состояний M-Bus Master (The Main Win)
Ниже представлена детализированная логика состояний, которая обеспечивает надежную коммуникацию M-Bus Master:
| Состояние | Описание логики | Выходной переход (Условие) |
|---|---|---|
| Инициализация | Выполняется один раз. Настройка COM-порта через VISA. Установка скорости (например, 9600 бод), паритета (Even). Инициализация регистров сдвига (адрес, FCB). | → «Отправка SND_NKE» |
| Отправка SND_NKE | Формирование и отправка короткого кадра SND_NKE (Send, No Reply, Keep Eye) для инициализации Slave-устройства по первичному адресу. | → «Ожидание ACK» |
| Ожидание ACK | VISA Read. Ожидание одиночного символа подтверждения E5h (ACK). Установка таймаута (например, 300 мс). |
Успешное ACK → «Отправка REQ_UD». Таймаут/Ошибка → «Обработка Ошибки/Повтор». |
| Отправка REQ_UD | Формирование и отправка запроса на пользовательские данные REQ_UD (Request User Data). | → «Ожидание RSP_UD» |
| Ожидание RSP_UD | VISA Read. Ожидание длинного кадра ответа от Slave (RSP_UD), начинающегося с 68h. Установка более длительного таймаута (1000 мс) для приема всего кадра. |
Прием данных → «Проверка CRC и Парсинг». Таймаут/Ошибка → «Обработка Ошибки/Повтор». |
| Проверка CRC и Парсинг | Проверка контрольной суммы (CRC) полученного длинного кадра. Если CRC корректна, извлечение измерительных данных из поля CI в соответствии со стандартом EN 13757-3 и обновление FCB. | CRC OK → «Следующий Адрес». CRC Ошибка → «Обработка Ошибки/Повтор». |
| Обработка Ошибки/Повтор | Логика регистрации ошибки (таймаут, неверный ACK, CRC ошибка). Инкремент счетчика попыток. Если попытки исчерпаны, переход к следующему Slave. | Повторить → «Отправка SND_NKE» (с сохранением текущего адреса). Попытки исчерпаны → «Следующий Адрес». |
| Следующий Адрес | Инкремент первичного адреса Slave. Проверка, достигнут ли конец списка устройств. | Не конец списка → «Отправка SND_NKE». Конец списка → «Завершение». |
| Завершение | Очистка ресурсов VISA (VISA Close). Остановка цикла While Loop. | → Остановка ВП. |
Нормативно-методическое и экономическое обоснование проекта (Закрытие критических Слепых Зон)
В соответствии с требованиями к ВКР технического профиля, проект должен включать обязательные разделы, подтверждающие его безопасность и экономическую целесообразность.
Обеспечение Безопасности Жизнедеятельности (БЖД)
Раздел БЖД должен гарантировать, что эксплуатация разработанного виртуального прибора и связанного с ним рабочего места оператора соответствует действующим нормативным актам Российской Федерации.
1. Требования к организации рабочего места
Организация рабочего места оператора ПЭВМ (персональной электронной вычислительной машины) регламентируется санитарными правилами и ГОСТами.
- Санитарно-гигиенические требования: Согласно Санитарным правилам СП 2.2.3670-20 (п. 249), минимальная площадь на одного пользователя ПЭВМ (с плоским дискретным экраном) должна составлять не менее 4,5 м2. (Ранее действовавший норматив 6,0 м2 применяется для ЭЛТ-дисплеев, но для современных плоских экранов применяется 4,5 м2).
- Эргономические требования: ГОСТ 12.2.061-81 «Оборудование производственное. Общие требования к рабочим местам» предписывает, что конструкция рабочего места, его размеры и взаимное расположение элементов должны соответствовать антропометрическим и психофизиологическим свойствам человека, обеспечивая оптимальную рабочую позу.
2. Электробезопасность
Поскольку работа включает использование ПЭВМ, преобразователей M-Bus/USB и внешних измерительных устройств, критически важны меры электробезопасности.
- ГОСТ Р 12.1.019-2009 и Правила устройства электроустановок (ПУЭ) требуют обязательного оборудования рабочего места защитным заземлением (занулением).
- Система заземления: Подключение ПЭВМ должно быть реализовано с использованием современных систем заземления, например, TN-C-S или TN-S, где отдельный защитный проводник (PE) исключает появление опасного напряжения на корпусе оборудования в случае пробоя изоляции.
Технико-экономическое обоснование (ТЭО) разработки
ТЭО демонстрирует экономическую целесообразность разработки виртуального прибора по сравнению с покупкой готового промышленного решения. Если готовый аппаратный Master-контроллер стоит в среднем 250 000 рублей, то программная разработка ВП, как мы увидим, дает существенную экономию на внедрении.
1. Расчет себестоимости программного продукта
Себестоимость разработки (Cпрогр) рассчитывается на основе трудозатрат разработчика, что является стандартным подходом для научно-исследовательских проектов в ВКР.
Формула расчета себестоимости:
Cпрогр = (Tдн × Змес / nдн) × (1 + kотч) + tмаш × Zм-час
Где:
- Tдн — затраты времени на разработку (чел.-дней).
- Змес — среднемесячная заработная плата разработчика (руб.).
- nдн — количество рабочих дней в месяце (обычно 21–22).
- kотч — коэффициент отчислений на социальные нужды (страховые взносы).
- Примечание: Актуальный коэффициент kотч принимается равным 0,302 (30,2% — совокупный размер страховых взносов), что позволяет использовать упрощенный множитель 1,302 в формуле.
- tмаш — затраты времени на отладку, тестирование и документирование (часы).
- Zм-час — стоимость машинного часа (руб./час), включая амортизацию оборудования и электроэнергию.
Пример применения формулы:
Предположим, что Tдн = 45 чел.-дней; Змес = 70000 руб.; nдн = 21 день; tмаш = 50 часов; Zм-час = 50 руб./час.
Cпрогр = (45 × 70000 / 21) × 1,302 + 50 × 50
Cпрогр = 150000 × 1,302 + 2500
Cпрогр = 195300 + 2500
Cпрогр = 197800 руб.
2. Обоснование максимальной цены
Максимальная цена (Cmax) продукта определяется как себестоимость плюс желаемая п��ибыль (рентабельность) и налог на добавленную стоимость (НДС).
Формула максимальной цены:
Cmax = Cпрогр × (1 + r) × (1 + kНДС)
Где:
- r — коэффициент рентабельности (например, r = 0,25 или 25%).
- kНДС — коэффициент НДС (на текущий момент 0,20 или 20%).
Cmax = 197800 × (1 + 0,25) × (1 + 0,20)
Cmax = 197800 × 1,25 × 1,20
Cmax = 197800 × 1,5
Cmax = 296700 руб.
Таким образом, ТЭО показывает, что разработанный ВП имеет обоснованную рыночную стоимость, превышающую прямые затраты на разработку, что подтверждает экономическую целесообразность проекта. Это означает, что проект не только решает техническую задачу, но и обладает четкой коммерческой перспективой, что является обязательным критерием успешной Выпускной Квалификационной Работы.
Заключение
В рамках данного инженерного исследования была разработана исчерпывающая методология для проектирования и реализации виртуального прибора M-Bus Master на платформе LabVIEW. Методология эта основана на принципах надежности и модульности.
Ключевые результаты работы:
- Теоретическое и техническое обоснование: Проведен глубокий анализ протокола M-Bus в соответствии со стандартами EN 13757, включая детальное рассмотрение асимметричного физического уровня (модуляция напряжения/тока) и канального уровня.
- Архитектурное решение: Обоснован выбор архитектуры Конечного Автомата (State Machine) как наиболее надежного подхода для управления последовательным протоколом M-Bus Master. Разработана полная диаграмма состояний, включающая критические шаги: инициализация (SND_NKE), ожидание подтверждения (ACK), запрос данных (REQ_UD) и многоуровневая обработка ошибок (CRC, таймауты).
- Академическая полнота: Включены и детально проработаны обязательные разделы ВКР — Безопасность Жизнедеятельности (БЖД) с учетом требований ГОСТ и СП к рабочему месту, а также Технико-экономическое Обоснование (ТЭО), включающее расчет себестоимости и максимальной цены по корректным методикам, основанным на трудозатратах.
Разработанный ВП M-Bus Master в LabVIEW представляет собой высокоточный, гибкий и надежный инструмент для централизованного учета энергоресурсов, полностью соответствующий инженерным и академическим стандартам, что подтверждает его ценность как основы для успешного завершения Выпускной Квалификационной Работы.
Список использованной литературы
- LabVIEW. User Manual. July 2000 Edition. Part Number 320999C-01.
- Measurement and Automation. Catalog 2003. National Instruments.
- Куприянов А.М., Савин А.Н. Методика организации удаленного доступа к измерительным приборам для их интеграции в состав сетевых измерительно-вычислительных комплексов // Теоретические проблемы информатики и ее приложений. Межвузовский сборник. Саратов: Изд-во Саратовского ун-та, 2004. Вып. 6.
- Савин А.Н., Гамова А.Н., Летов А.Д., Попов А.А. Разработка программных средств для оценки характеристик кодированных сигналов и методов кодирования в среде графического программирования LabView // Проблемы системного подхода при изучении естественнонаучных дисциплин слушателям гуманитарных специальностей. Материалы межвуз. науч.-практ. семинара. Саратов: СЮИ МВД России, 2004. С. 88–97.
- Савин А.Н., Синельников Е.А. Автоматизированный комплекс для исследования электродинамических характеристик СВЧ-устройств методом резонансных возмущений // Актуальные проблемы электронного приборостроения. АПЭП-2002: Материалы междун. науч.-техн. конф. Саратов, 2002. С. 188-192.
- Использование виртуальных инструментов LabVIEW / Жарков Ф.П., Каратаев В.В., Никифоров В.Ф., Панов В.С. ; под ред. Демирчана К.С., Миронова В.Г. М.: Салон-Р, Радио и связь, Горячая линия – телеком, 1999. 268 с.
- Сайт компании «NT-MDT» [Электронный ресурс]. URL: http://www.ntmdt.ru (дата обращения: 23.10.2025).
- Сайт компании «National Instruments» [Электронный ресурс]. URL: http://www.labview.ru (дата обращения: 23.10.2025).
- ГОСТ 12.0.004-2015. Система стандартов безопасности труда (ССБТ). Организация обучения безопасности труда.
- ГОСТ 12.2.061-81. ССБТ «Оборудование производственное. Общие требования к рабочим местам».
- M-Bus-интерфейс [Электронный ресурс]. URL: https://www.lers.ru/info/m-bus-interfeys/ (дата обращения: 23.10.2025).
- M-BUS [Электронный ресурс]. URL: https://www.strumen.com/articles/m-bus (дата обращения: 23.10.2025).
- Downloads — M-Bus [Электронный ресурс]. URL: https://www.m-bus.com/downloads (дата обращения: 23.10.2025).
- ШИНА M-Bus [Электронный ресурс]. URL: https://vdmais.ru/catalog/izmeritelnaya_tehnika/ustroystva_dlya_sbora_dannyh/m_bus/ (дата обращения: 23.10.2025).
- СОЗДАНИЕ ВИРТУАЛЬНЫХ ПРИБОРОВ В СРЕДЕ LABVIEW [Электронный ресурс]. URL: https://vlsu.ru/www/upload/sections/30588/sozdanie-virtualnih-priborov-v-srede-labview.pdf (дата обращения: 23.10.2025).
- Основы LabVIEWTM 1 Учебное пособие [Электронный ресурс]. URL: https://ustu.ru/fileadmin/user_upload/uchebnyy_process/kafedry/atp/LabVIEW.pdf (дата обращения: 23.10.2025).
- Обзор некоторых виртуальных приборов среды LabVIEW в помощь разработчику (+ исходники) [Электронный ресурс]. URL: https://habr.com/ru/articles/581566/ (дата обращения: 23.10.2025).
- ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ДИПЛОМНЫХ ПРОЕКТОВ — Электронная библиотека БГТУ [Электронный ресурс]. URL: https://elib.belstu.by/bitstream/123456789/22961/1/Ekonomicheskoe_obosnovanie_diplomnyh_proektov.pdf (дата обращения: 23.10.2025).
- Как посчитать себестоимость разработки программного обеспечения [Электронный ресурс]. URL: https://ce-na.ru/stati/kak-poschitat-sebestoimost-razrabotki-programmnogo-obespecheniya (дата обращения: 23.10.2025).
- Инструкция по охране труда для инженера технического отдела [Электронный ресурс]. URL: https://arkons.biz/wp-content/uploads/2021/01/IOT-dlya-inzhenera-tehnicheskogo-otdela.pdf (дата обращения: 23.10.2025).
- ИОТ № 03-2021. Инструкция по охране труда ведущего инженера группы технической поддержки. [Электронный ресурс]. URL: https://nsk.su/images/upload/files/documents/IOT_03_2021_ved_inj_tech_podderzhki.pdf (дата обращения: 23.10.2025).