Зачем нам понадобилось избавляться от проводов?

Чтобы ответить на этот вопрос, нужно описать, что мы вообще делаем на заводах. На заводах мы внедряем систему мониторинга промышленного оборудования «Диспетчер». Под промышленным оборудованием понимаем станки, производственные линии, рабочие места и прочее.

Чтобы «Диспетчер» выполнял свои функции, ему нужны данные. Собирать их с промышленного оборудования можно несколькими способами. Самый простой — напрямую подключиться к станку, если в нем есть соответствующий интерфейс. Но нам часто нужно иметь дело со станками без ЧПУ, и для сбора данных с них нужны отдельные устройства. Такие приборы мы сами обычно разрабатываем. Они позволяют определить, включено оборудование или нет, работает ли оно или простаивает, сколько потребляется электроэнергии, сколько деталей обработано и так далее.

В качестве лирического отступления расскажу, как работают наши устройства для сбора данных на примере нашего простого регистратора Р-03 (см. Рис. 1).

У Р-03 есть четыре дискретных входа, один аналоговый вход и интерфейс RS-485. Каждый дискретный вход позволяет контролировать цифровые сигналы (0 или 1) с единичным уровнем в 24 В. Одновременно с контролем уровней измеряется и количество импульсов. Все дискретные входы имеют гальваническую развязку. Аналоговый вход позволяет измерять переменный ток амплитудой до 50 мА. Цифровой интерфейс RS-485 используется для подключения внешних датчиков или дополнительных приборов собственного производства, например, датчика вибрации. Сам регистратор опрашивается также по проводному интерфейсу RS-485 терминалом ввода вывода ТВВ-10, который уже передает собранные данные в «Диспетчер» через Ethernet. При этом к одному ТВВ-10 подключается всего один регистратор Р-03.

Алгоритм работы регистратора прост до безобразия: он собирает данные со всех своих входов и раз в пять секунд отправляет их в ТВВ-10. Вот и всё: измеряем сигналы на входах, опрашиваем внешние датчики и отправляем полученные данные в «Диспетчер».

Но каким бы способом ни производилось подключение, напрямую или через аппаратные устройства, такие как Р-03, всегда приходится использовать провода — как минимум UTP-кабель при прямом подключении, а при аппаратном еще и отдельное питание для прибора.

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

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

Требования к аппаратуре беспроводного подключения

Первым делом мы определили основные требования к новому прибору:

1. Устройство должно передавать данные по беспроводному каналу.

2. Устройство должно быть полностью автономным, включая питание, это позволит полностью отказаться от проводов.

3. Устройства должны сами объединяться в сеть, что позволит избавиться от настройки каждого перед эксплуатацией.

4. Следует свести к минимуму вероятность потери данных, т. к. для системы мониторинга это неприемлемо.

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

6. Необходима максимально возможная дальность связи, чтобы подключать станки из самых дальних уголков большого цеха.

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

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

Выбираем беспроводную технологию передачи данных

К настоящему времени изобретено и описано очень много технологий беспроводной передачи данных, все нам неизвестны, но четыре наиболее популярные мы все же можем рассмотреть и оценить достоинства и недостатки относительно наших потребностей. Для удобства я свел их в таблицу (см. Рис. 2).

Для наших целей хорошо подходят две технологии — Bluetooth и IEEE 802.15.4. Для своего устройства мы выбрали последнюю, т. к. есть возможность работать в относительно чистом диапазоне частот 868 МГц.

Подбираем подходящую микросхему

Теперь необходимо выбрать подходящую микросхему. Основные требования к ней:

1. Должна уметь работать в режимах с низким энергопотреблением, точнее — с очень низким энергопотреблением.

2. Предпочтительно, чтобы это была система на кристалле (SoC), т. е. контроллер и трансивер должны быть в одной микросхеме. Это позволит снизить энергопотребление устройства.

3. Контроллер в микросхеме должен быть достаточно производительным, чтобы на базе одного устройства реализовать функции сбора данных и маршрутизации (шлюза).

4. Наличие периферии: АЦП, UART, SPI, GPIO.

5. Плюсом будет наличие готовых к использованию программных библиотек, реализующих стек протоколов и доступ к периферии.

Если хорошо поискать, можно найти не одну микросхему, удовлетворяющую этим требованиям. Но честно признаюсь — мы не искали долго. Одной из первых нам попалась на глаза микросхема от Texas Instruments — СС1352, которая идеально вписалась в наши пожелания и даже немного больше. У нее внушительный список характеристик. Приводить все я не буду, а расскажу только о ключевых.

Это система на кристалле, внутри которой живут многодиапазонный трансивер и три независимых контроллера. Каждый имеет свое назначение:

Main CPU — главный контроллер, отвечает за логику работы всего устройства. Это высокопроизводительный процессор с архитектурой ARM Cortex-M4F, который для выполнения своей функции может взаимодействовать с двумя другими.

Sensor controller предназначен для опроса внешних датчиков. Он оптимизирован для непрерывной работы с минимальным энергопотреблением и программируется отдельно от основного на С-подобном языке или ассемблере.

У Sensor controller есть свой набор периферии: GPIO, АЦП, компараторы, ёмкостный датчик прикосновения, SPI, UART и I2C (реализованы программно через GPIO). Sensor controller работает независимо от основного, что позволяет получать и обрабатывать данные с датчиков практически непрерывно при минимальном потреблении в 30 мкА. Запись прошивки в RAM Sensor controller осуществляет через Main CPU, так что можно использовать несколько разных прошивок и менять их на лету.

Контроллер трансивера отвечает за управление цифровым многодиапазонным трансивером. Трансивер может работать в семи частотных диапазонах, но нам интересны  2360-2500 МГц и 861-1054 МГц. Управление этим контроллером осуществляет Main CPU через RAM, доступ к которой есть у обоих CPU. Управление осуществляется с помощью команд, которые Main CPU записывает в RAM, а контроллер трансивера выполняет и сохраняет результат в RAM. Для упрощения работы с радиоканалом TI предоставляет набор библиотек, реализующих несколько беспроводных протоколов передачи данных, таких как IEEE 802.15.4g, Bluetooth 5.2 Low energy, Thread и пр. Эти библиотеки в готовом для использования бинарном виде хранятся в отдельной специальной ROM. Таким образом, для организации сети по любому из доступных протоколов достаточно просто использовать API, который уже хранится в контроллере.

В итоге мы выбрали контроллер, который отвечает всем нашим пожеланиям и даже больше. Многодиапазонный трансивер и набор библиотек в ROM позволяют экспериментировать с разными протоколами беспроводной связи. Микросхема прекрасно оптимизирована с точки зрения потребления энергии так, что прибор может работать автономно без замены батареек около года и даже дольше. Мощный CPU дает возможность реализовать в одном устройстве как простой беспроводной датчик, так и мост в другую сеть.

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

Так как алгоритм работы всего устройства достаточно прост, описывать его не вижу смысла, а вот о протоколах передачи данных стоит поговорить подробней. Начнем с нижнего уровня — стандарта IEEE 802.15.4.

Как работает протокол 802.15.4

Немного о топологии

В зависимости от выполняемой функции, в сети можно выделить три типа устройств:

1. Координатор сети — центральный узел сети, к которому подключаются все остальные устройства. Он отвечает за организацию сетевого обмена, маршрутизацию пакетов и адресацию устройств. Координатор сети должен всегда находиться на связи и обрабатывать большое количество пакетов, поэтому он питается от электросети.

2. Координатор — промежуточный узел между координатором сети и конечным устройством. Его основное назначение — маршрутизация пакетов между координатором сети и конечным устройством.

3. Конечное устройство (КУ) — узел сети с автономным питанием и набором датчиков, подключается к координатору сети и периодически отправляет данные с датчиков. Т. к. передача данных по беспроводному каналу расходует большое количество энергии, то большую часть времени это устройство находится в спящем режиме.

Эти три типа устройств позволяют организовать беспроводные сети с любой топологией, однако на практике чаще всего используются «звезда», «кластерное дерево», mesh (см. Рис. 4). Сеть из наших устройств в настоящее время организована в топологии «звезда», где центральным элементом является координатор сети, к которому подключаются конечные устройства (см. Рис. 3). Это простая топология с очень простой системой маршрутизации пакетов. Её основным недостатком является ограниченный радиус покрытия сети, т. е. максимальное расстояние друг от друга, на котором могут быть установлены координатор и конечное устройство. Это расстояние зависит от характеристик радиотракта («чистота» эфира, наличие препятствий, переотражений, мощность передатчика, чувствительность приемника и прочее). В дальнейшем мы планируем перейти на более сложную топологию — «кластерное дерево», что позволит сделать покрытие сети практически неограниченным (см. Рис. 5).

Порядок обмена данными между координатором и КУ

Протоколом предусмотрено два режима организации сети: с периодической отправкой синхронизирующих сообщений координатором (beacon-enabled) и без таковой (non-beacon-enabled). У beacon-enabled есть два основных недостатка в сравнении с non-beacon-enabled:

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

• Необходима синхронизация времени на всех устройствах.

Поэтому мы выбрали режим работы сети non-beacon-enabled: каждое устройство отправляет данные по мере необходимости, а для предотвращения коллизий используется механизм CSMA-CA. Очень упрощенно его можно описать так: перед передачей устройство прослушивает радиоэфир и, если он занят, отправка сообщения задерживается на случайно выбранное время. Плюс такого режима работы — уменьшение энергопотребления конечным устройством. Минус — КУ большую часть времени находится в спящем режиме для экономии энергии и не может передавать или принимать сообщения. Соответственно,  координатор не может отправить сообщение КУ в произвольный момент времени, так как неизвестно, может КУ принять сообщение или нет. Для того, чтобы передать данные, координатор ожидает соответствующего запроса от КУ и только после этого отправляет ему данные, если они есть. Из этого следует, что задержка между началом отправки сообщения координатором и получением его КУ может составлять несколько минут.

Установка соединения

Сразу после включения конечное устройство пытается подключиться к сети, созданной координатором. Для этого КУ отправляет в радиоэфир сообщение "discovery". Координатор в ответ отправляет параметры сети PAN_ID и COORDINATOR_ID. Если PAN_ID подходящий, КУ отправляет запрос на присоединение к сети "association req". В ответ получает "association resp", который либо подтверждает подключение, либо отклоняет его. После того, как соединение установлено, КУ может отправлять данные координатору сети.

Это было краткое знакомство с IEEE 802.15.4. Отсюда перемещаемся на ступень выше в модели OSI и рассмотрим наш протокол прикладного уровня.

Протокол прикладного уровня

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

Устройство с автономным питанием и передачей данных по радиоканалу не может позволить себе такую роскошь по двум основным причинам:

• операции приема/передачи данных по радиоканалу очень энергозатратные в сравнении с операциями опроса периферии;

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

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

• события, которые необходимо зафиксировать

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

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

Таким образом, для оптимизации энергопотребления каждое устройство должно передавать быстрые данные только в момент их появления, а агрегированные — за достаточно длинный промежуток времени (раз в минуту или реже). Как это делается?

Передача быстрых данных

Каждое конечное устройство осуществляет периодический опрос периферии через Sensor controller. При этом Main CPU находится в режиме сна. При появлении быстрых данных Sensor controller пробуждает Main CPU для их передачи, он отправляет данные координатору и снова засыпает.

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

Передача агрегированных данных

Агрегированные данные отправляются регулярно с заданным интервалом (по умолчанию 60 с). Каждое сообщение с агрегированными данными содержит в себе время начала сбора данных и его продолжительность. В случае, если КУ успешно получило подтверждение доставки, сбор данных начинается с начала, а время начала этого сбора будет передано в следующем сообщении. Продолжительность агрегирования рассчитывается непосредственно перед отправкой данных. В случае, если КУ не получило подтверждение доставки, оно продолжает собирать данные до следующего периода отправки. Для обеспечения хронологического порядка в данных, полученных координатором, сообщение с агрегированными данными отправляется, только если очередь отправки мгновенных данных пуста. 

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

Что в итоге получилось

Результат нашей работы — регистратор Р-05 с двумя дискретными и одним аналоговым входами и одним интерфейсом RS-485. Это чуть меньше, чем в проводном Р-03, но количество периферии здесь не главное.

Несколько таких регистраторов самостоятельно организуют беспроводную сеть с топологией «звезда», после чего начинают снимать показания с периферии и отправлять их по мере необходимости в «Диспетчер». В зависимости от прошивки, регистратор может выступать в роли конечного устройства или координатора сети. Питается он от двух батареек типа АА.

Полноценно проверить продолжительность работы регистратора мы еще не успели, но предварительные показания внушают оптимизм. В сети из двух устройств (координатор и КУ) при отправке агрегированных данных с частотой раз в 5 секунд регистратор проработал два месяца. Простая интерполяция дает надежду на год беспрерывной работы при увеличении периода передачи данных в 6 раз (раз в 30 секунд).

Нам предстоит еще проверить Р-05 при большом количестве устройств в сети, исправить кучу неизвестных ошибок, но уже сейчас он может использоваться по назначению и приносить пользу.

Еще у нас много разных планов: организовать сеть с топологией «кластерное дерево», сделать шифрование канала передачи данных, оптимизировать энергопотребление, опробовать bluetooth. Буду рад вам об этом рассказать, если интересно.