Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Plc

Из песочницы Автоматизация квартиры

13.06.2020 18:19:58 | Автор: admin

Предыстория


Давняя мечта об автоматизации квартиры начала свое превращение в реальность с покупки квартиры в новостройке. Уже на этапе планирования ремонта вырисовались основные требования к инженерным сетям:

  1. гибкое управление освещением, водоснабжением, вентиляцией, отоплением и силовыми нагрузками;
  2. возможность реализации сценариев;
  3. удаленное управление и оповещение;
  4. централизованное отключение всего освещения;
  5. централизованное отключение неприоритетных нагрузок и водоснабжения;
  6. в перспективе возможность голосового управления.

Электрика


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

По проекту застройщика, все нагрузки были поделены на 4 группы:

  • котел;
  • освещение;
  • розетки кухни и коридора;
  • всё остальное.

Вся модульная автоматика была расположена в этажном щите, в квартиру заходили 4 кабеля 2 3х2,5 мм2 и 2 3х1,5 мм2, что не соответствовало моим потребностям. Было принято решение о перетяжке кабеля от этажного щита и переносе распределительного щита непосредственно в квартиру. В результате в этажном щите остался счетчик и вводной автоматической выключатель на 40А, далее кабель 3х6 мм2 до квартирного щита.

При проектировании квартирного щита учитывались следующие требования:

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

В итоге вырисовалась следующая схема:

image

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

Для размещения всей необходимой модульной автоматики был выбран встраиваемый щит на 72 модуля (как впоследствии выяснилось места в щите много не бывает).

Начался процесс полной переделки электрики внутри квартиры. Из особенностей кабельные трассы от всех источников освещения и выключателей были заведены непосредственно в квартирный щит.

Автоматика


В силу того, что в своей практике приходилось сталкиваться с промышленной автоматикой, в качестве устройства управления рассматривались разные варианты ПЛК и ПЛР от Siemens, ABB, Schneider-Electric, Овен и т.д. В итоге выбор пал на программируемое логическое реле ONI PLR (PLR-S-CPU-1004R-AC-BE, далее, для краткости контроллер). Почему именно так:

  • встроенная шина RS-485 с поддержкой протокола Modbus;
  • дискретные выходы, реализованные в виде 3-х и 10-ти амперных реле;
  • питание от 220В;
  • компактные размеры;
  • форм-фактор для установки на DIN-рейку;
  • наличие экрана и органов управления непосредственно на корпусе;
  • цена.

Так как 10 дискретных входов и 4 релейных выходов было недостаточно, в дополнение к основному блоку, было выбрано два модуля расширения по 8 дискретных входов, 4 релейных выхода 3А, 4 релейных выхода 10А. Разработка под данное реле ведется с использование языка функциональных диаграмм (FBD).

Водоснабжение


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

Установленный шаровый кран с приводом:

image

Выбор ПО управления


Т.к. являюсь пользователем различных гаджетов компании Samsung, в качестве программной платформы для управления решил остановиться на ПО SmartThings, которое поддерживает интеграцию через облачный коннектор. Для стыковки ONI PLR со SmartThings Cloud потребуется разработать OPC-сервер и CloudConnector.

На перспективу запланирована интеграция с GSM-модемом в качестве резервного канала управления, а также для аварийного оповещения о внештатных ситуациях.

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

image


Реализация


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

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

image

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

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

image


Выключатели:

image

В процессе пуско-наладки контроллера и отладки ПО были замечены странные задержки в 0,5 1 секунду при включении/отключении релейных выходов, находящихся в модулях расширения. Проблема оказалась весьма банальной невнимательное изучение мануалов. Перед подключением необходимо было выставить DIP-переключателями адреса для модулей расширения, как только это было сделано, контроллер заработал как часы.

В настоящее время собранный щит в интерьере выглядит следующим образом:

image

На текущий момент реализованы следующие функции:

  • управление освещением с выключателей, для ряда помещений из нескольких мест;
  • простые сценарии с автоматическим включением вентиляции в помещениях с повышенной влажностью (пока без соответствующих датчиков, только на основании типовых поведенческих сценариев, исходя из времени нахождения людей в помещениях);
  • общее отключение освещения (отдельный выключатель);
  • принудительное отключение водоснабжения;
  • отключение водоснабжения при намокании датчиков.

В ближайших планах реализация взаимодействия с экосистемой SmartThings, реализация более сложных сценариев работы. На текущий момент завершаются отделочные работы, реализация программной части проекта запланирована после переезда.
Подробнее..
Категории: Инженерные системы , Интернет вещей , Умный дом , Plc

Реализация кастомной Edge I-IoT платформы

15.07.2020 18:16:18 | Автор: admin
В предыдущей статье был краткий обзор промышленного интернета вещей I-IoT и описание платформы граничных вычислений. В этой статье я хочу показать простой пример релизации Edge I-IoT платформы, используя популярные открытые технологии.

С архитектурной точки зрения платформа IoT требует решить следующие задачи:

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

Одной из особенностей IoT платформы является независимость между объектами и сигналами, что позволяет выполнять параллельные вычисления, повышая производительность.

Данные, поступающие с датчиков, собираются из источников, таких как ПЛК, DCS, микроконтроллеров и т.п и могут храниться во временной области для избежание потери данных из-за проблем с подключением. Данные могут быть временным рядом, такими как событие, полуструктурированные данные, такие как логи и двоичные файлы, или неструктурированные, как изображение. Данные и события временного ряда собираются часто (от каждой секунды до нескольких минут). Затем они отправляются по сети и сохраняются в централизованном озере данных (data lake) и базе данных временных рядов (time-series database TSDB). Data lake может быть облачным, локальным центром обработки данных или сторонней системой хранения.

Данные могут быть немедленно обработаны с использованием анализа потока данных, который называется hot path, с механизмом проверки правил, основанном на простой или интеллектуальной уставке. Продвинутая аналитика может включать: цифровые близнецы, машинное обучение, глубокое обучение или аналитика на основе физических характеристик. Такая система может обрабатывать большой объем данных (от десяти минут до месяца) с разных датчиков. Эти данные хранятся в промежуточном хранилище. Эта аналитика называется cold path, и как правило, запускается планировщиком или доступностью данных и требует большого количества вычислительных ресурсов. Продвинутая аналитика часто нуждается в дополнительной информации, такой как модель контролируемой машины и эксплуатационные атрибуты; эта информация содержится в asset registry. Asset registry содержит информацию о типе актива, включая его имя, серийный номер, символическое имя, местоположение, рабочие возможности, историю комплектующих, из которых он состоит, и роль, которую он играет в производственном процессе. В asset registry мы можем хранить список измерений каждого актива, логическое имя, единицу измерения и диапазон границ. В промышленном секторе эта статическая информация важна для правильной аналитической модели.

Причины разработки кастомной платформы:

  • Возврат инвестиций: небольшой бюджет;
  • Технология: использование технологии независимо от поставщика;
  • Конфиденциальность данных;
  • Интеграция: необходимость разработки уровня интеграции с новой или устаревшей платформой;
  • Другие ограничения;

image

Cквозной поток данных в I-IoT

Пример кастомной реализации Edge-платформы


На данном рисунке показана реализация следующих звеньев платформы:

  • Источник данных: как пример выбран симулятор контроллера Simatic PLCSIM Advanced с активированным OPC сервером, как описано в предыдущей статье.
  • В качестве граничного шлюза выбрана популярная платформа Node-Red c установленным плагином node-red-contrib-opcua flows.nodered.org/node/node-red-contrib-opcua
  • MQTT брокер Mosquitto используется как диспетчер передачи данных между другими звеньями потока.
  • Apache Kafka используется как как распределенная потоковая платформа, выполняющая роль аналитики hot path с помощью kafka-streams.

image

Node-red Edge gateway


В качестве шлюза граничных вычислений будем использовать Node-red, как простую настраиваемую платформу, имеющую множество различных плагинов. Роль промышленного адаптера (Industrial adapter) играет плагин node-red-contrib-opcua. Для множественного сбора данных с контроллера способом подписки используются ноды: OpcUa-Browser и OpcUa-client. В OPC браузер ноде настраивается url OPC-сервера (endpoint) и топик, в котором указано пространство имен и имя читаемого блока данных, например ns=3;s=HMI_Alarms_Area. В OPC-клиент ноде также указывается url OPC-сервера, в качестве действия (Action) устанавливается SUBSCRIBE и интервал обновления данных.

Node-red main flow
image

Настройка ноды OPC-browser
image

Настройка ноды OPC-client
image

Для того, чтобы выполнилась подписка на чтения множественных данных, необходимо подготовить и загрузить топики тегов чтения с контроллера, согласно OPC протокола. Для этого вначале используется inject нода с чекбоксом only once, которая тригерит единократное чтения блоков данных, указанных в нодах OPC-браузера. Затем данные обрабатываются функцией Decode&filter. После чего нода OPC-клиента подписывается и читает изменяющиеся данные с контроллера. Дальнейшая обработка потока зависит от конкретной реализации и требований. В своем примере я обрабатываю данные для дальнейшей отсылки их в MQTT брокер на разные топики.

Вкладки HMI control и Office представляют собой простую реализуцию HMI на базе Scadavis.io и node-red dashboard, как описано ранее в статье.

image

Пример парсинга данных OPC-browser ноды

var items = msg.payload;for (var i=0; i<items.length; i++) {    var item = items[i];var ref = item.item;var nodeClass = ref.$nodeClass;var typeDef = ref.typeDefinition;var bname = ref.browseName;var ns=bname.namespaceIndex;var name=bname.name;var value = ref.value;var datatype = ref.dataType;// Select only want namespace variablesif (ns==3) {    var newmsg={};newmsg.topic =     ref.nodeId+    ";datatype="+datatype;newmsg.payload=value;node.send(newmsg);}}

MQTT брокер


В качестве брокера можно использовать любую реализацию. В моем случае уже установлен и настроен Mosquitto брокер mosquitto.org. Брокер выполняет функцию транспорта данных между Edge gateway и другими участниками платформы. Есть примеры с балансировкой нагрузки и распределенной архитектурой, например habr.com/ru/company/yandex/blog/491740. В данном случае ограничимся одним mqtt брокером с передачей данных без шифрования.

Локальное хранилище данных временных рядов


Данные временного ряда удобно записывать и хранить в NoSql time-series базе данных. Для наших целей удачно подходит стек InfluxData. Нам необходимо четыре сервиса из этого стека:

InfluxDB это база данных временных рядов с открытым исходным кодом, которая является частью стека TICK (Telegraf, InfluxDB, Chronograf, Kapacitor). Предназначена для обработки данных с высокой нагрузкой и предоставляет SQL-подобный язык запросов InfluxQL для взаимодействия с данными.

Telegraf это агент для сбора и отправки метрик и событий в InfluxDB из внешних IoT систем, датчиков и т.п. Настраивается на сбор данных из mqtt топиков.

Kapacitor это встроенный механизм обработки данных для InfluxDB 1.x и интегрированный компонент в платформу InfluxDB 2.0. Этот сервис можно настроить на мониторинг различных уставок и тревог, а также установить обработчик отправки событий во внешние системы, как Kafkf, email и т.п.

Chronograf это пользовательский интерфейс и административный компонент платформы InfluxDB 1.x. Используйтся для быстрого создания панелей мониторинга с визуализацией в реальном времени.

Все компоненты стека можно запустить локально или настроить Docker контейнер.

image
Выборка данных и настройка дашбордов с помощью Chronograf

Для запска InfluxDB достаточно выпонить команду influxd, в настройках influxdb.confможно указать место хранения данных и другие свойства, по умолчанию данных храняться в пользовательском каталоге в .influxdb директории.

Для запуска telegraf необходимо выполнить команду telegraf -config telegraf.conf, где в настройках можно указать источники метрик и событий, в нашем примере для mqtt это выглядит так:

# # Read metrics from MQTT topic(s) [[inputs.mqtt_consumer]]   servers = ["tcp://192.168.1.107:1883"]   qos = 0   topics = ["HMI_Status_Area/#", "HMI_Alarms_Area/#"]   data_format = "value"   data_type = "float"

В свойстве servers указываем url к mqtt брокеру, qos можем оставить 0, если достаточно записывать данные без подтверждения. В свойстве topics указываем маски mqtt топиков, из которых будем читать данные, например HMI_Status_Area/# означает, что мы читаем все топики, имеющие префикс HMI_Status_Area. Таким образом telegraf для каждого топика создаст свою метрику в базе, куда будет писать данные.

Для запуска kapacitor необходимо выполнить команду kapacitord -config kapacitor.conf. Свойства можно оставить по умолчанию и дальнейшие настройки выполнить с помощью Chronograf.
Чтобы запустить chronograf достаточно выполнить одноименную команду chronograf. Веб интервейст будет доступен localhost:8888/

Для настройки уставок и тревог с помощью Kapacitor можно воспользоваться мануалом docs.influxdata.com/kapacitor/v1.5/working/kapa-and-chrono. В кратце нужно перейти во вкладку Alerting в Chronograf и создать новое правило с помощью кнопки Build Alert Rule, интерфейс интуитивно понятен, все выполняется визуально. Для настройки отсылки результатов обработки в kafka (и др.) необходимо добавить обработчик в разделе Conditions

Настройки обработчика Kapacitor
image

Распределенная потоковая обработка с Apache Kafka


Для предлагаемой архитектуры необходимо отделить сбор данных от обработки, улучшив масштабируемость и независимость уровней. Для достижения этой цели мы можем использовать очередь. В качестве реализации может быть Java Message Service (JMS) или Advanced Message Queuing Protocol (AMQP), но в данном случае будем использовать Apache Kafka. Kafka поддерживается большинством аналитических платформ, имеет очень высокую производительность и масштабируемость, а также имеет хорошую библиотеку потоковой обработки Kafka-streams.

Для взаимодействия к Kafka можно использовать плагин Node-red node-red-contrib-kafka-manager flows.nodered.org/node/node-red-contrib-kafka-manager. Но учитываю разделения сбора от обработки данных, установим плагин MQTT, который подписывается на топики Mosquitto. Плагин MQTT доступен по ссылке github.com/evokly/kafka-connect-mqtt.

Для настройки коннектора необходимо в каталок kafka/libs/ скопировать библиотеки kafka-connect-mqtt-1.1-SNAPSHOT.jar и org.eclipse.paho.client.mqttv3-1.0.2.jar (или другую версию). Затем в каталоге /config необходимо создать файл свойств mqtt.properties со следующим содержимым:

name=mqttconnector.class=com.evokly.kafka.connect.mqtt.MqttSourceConnectortasks.max=1 kafka.topic=streams-measuresmqtt.client_id=mqtt-kafka-123456789 mqtt.clean_session=truemqtt.connection_timeout=30mqtt.keep_alive_interval=60 mqtt.server_uris=tcp://192.168.1.107:1883mqtt.topic=mqtt

После чего мы можем запустить коннектор с помощью команды предварительно запустив zookeeper-server и kafka-server

connect-standalone.bat \config\connect-standalone.properties \config\mqtt.properties

Из топика mqtt (mqtt.topic=mqtt) данные будут записываться в Kafka-топик streams-measures (kafka.topic=streams-measures).

В качестве простого примера можно создать maven-проект, используя библиотеку kafka-streams.
С помощью kafka-streams можно создавать различные сервисы и сценарии hot аналитики и потоковой обработки данных.

Например, сравнение текущей температуры с уставкой. 
StreamsBuilder builder = new StreamsBuilder();        KStream<String, String> source = builder.stream("streams-measures");        KStream<Windowed<String>, String> max = source                .selectKey((String key, String value) -> {                        return getKey(key, value);                    }                )                .groupByKey()                .windowedBy(TimeWindows.of(Duration.ofSeconds(WINDOW_SIZE)))                .reduce((String value1, String value2) -> {                        double v1=getValue(value1);                        double v2=getValue(value2);                        if ( v1 > v2)                            return value1;                        else                            return value2;                    }                )                .toStream()                .filter((Windowed<String> key, String value) -> {                        String measure = tagMapping.get(key.key());                        double parsedValue = getValue(value);                        if (measure!=null) {                            Double threshold = excursion.get(measure);                            if (threshold!=null) {                                if(parsedValue > threshold) {                                    log.info(String.format("%s : %s; Threshold: %s", key.key(), parsedValue, threshold));                                    return true;                                }                                return false;                            }                        } else {                            log.severe("UNKNOWN MEASURE! Did you mapped? : " + key.key());                        }                        return false;                    }                );        final Serde<String> STRING_SERDE = Serdes.String();        final Serde<Windowed<String>> windowedSerde = Serdes.serdeFrom(                new TimeWindowedSerializer<>(STRING_SERDE.serializer()),                new TimeWindowedDeserializer<>(STRING_SERDE.deserializer(), TimeWindows.of(Duration.ofSeconds(WINDOW_SIZE)).size()));        // the output        max.to("excursion", Produced.with(windowedSerde, Serdes.String()));


Asset registry


Реестр активов вообще говоря не является структурной составляющей Edge платформы и представляет часть облачной IoT среды. Но в данном примере показано взаимодействие Edge и Cloud.

В качестве asset registry будем использовать популярную IoT платформу ThingsBoard. Интерфейс которой также достаточно интуитивно понятен. Установка возможно с демо-данными. Платформу можно установить локально, в докере или использовать готовую облачную среду.

В набор демо-данных входят тестовые устройства (можно легко создать новое), в которые мы можем отправлять значения. По умолчанию ThingsBoard запускается со своим mqtt брокером, к которому необходимо подключаться и отсылать данные в json формате thingsboard.io/docs/reference/mqtt-api. Допустим, мы хотим отсылать данные в ThingsBoard от устройства TEST DEVICE A1. Для этого нам необходимо подключиться к ThingBoard брокеру по адресу localhost:1883, используя A1_TEST_TOKEN в качестве логина, который можно скопировать из настроек устройства. После чего можем публиковать данные в топик v1/devices/me/telemetry: {temperature:26}

image

В документации платформы имеется манул по настройке передачи данных и обработке аналитики в Kafka IoT data analytics using Kafka, Kafka Streams and ThingsBoard

Пример использования Kafka ноды в Thingsboard
image
Подробнее..
Категории: Интернет вещей , Plc , Анализ и проектирование систем , Nosql , Промышленное программирование , Iot , Scada , Node-red , Siemens 1500 , Kafka , Opc-server

Power-line communication. Часть 1 Основы передачи данных по линиям электропередач

25.08.2020 02:16:19 | Автор: admin
Не так давно передо мной встала нетривиальная задачка собрать устройство, которое могло бы по линиям электропередач (0,4 кВ), в сетях обычных бытовых потребителей, передавать некоторую информацию, а точнее показания электросчетчиков.



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

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


Коммуникация


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



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



Проводник


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

Полезный сигнал




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

Шум



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

Протокол



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

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

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

Линии электропередач как канал связи



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

Чтобы использовать линии электропередач в качестве канала связи, нужно понять, как они устроены, и какие физические процессы в них происходят.
Взглянем на схему доставки электроэнергии от подстанции до жилых домов. Электрические сети трехфазные, и от подстанции идут три фазы (A, B и С), которые электрически изолированы друг от друга.



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



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



Проводник


Подробнее изучим среду передачи сигнала. Для этого рассмотрим, в каком виде передается электрическая энергия, и узнаем, как через этот поток мы можем передать свой полезный сигнал.
Электроэнергия передается в виде переменного тока. Проводниками обычно выступают алюминиевый или медный кабели. Напряжение в электрической сети имеет форму синусоиды с периодом 20 миллисекунд (частота 50 Гц).



Так как ток переменный, он периодически меняет направление течения, и в момент смены направления мощность практически не передается (если не учитывать сдвиг из-за сильной емкостной или индуктивной нагрузки). Наступают мгновения затишья. Это называется zero cross (далее ZC) момент, в который напряжение равно нулю.



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

В электрической сети с частотой 50 Гц (как в России) момент ZC происходит 100 раз в секунду. И если передавать по одному символу за один переход через ноль, то скорость соединения будет равна 100 бод/сек. Скорость передачи в байтах уже зависит от формата кадра, от того, сколько служебных бит, помимо самих данных, будет в кадре (о формате кадров ниже по тексту).

Синхронизация


Еще один немаловажный момент это синхронизация момента передачи и приема между устройствами.
Для нашего нового протокола будем использовать синхронную передачу данных, так как это проще в реализации.
Передатчику нужно знать, в какой конкретный момент надо включить ЦАП для генерации сигнала. Приемнику нужно понимать в какой конкретный момент надо включить АЦП для измерения и оцифровки входящего сигнала. Для этого кто-то должен подавать сигнал процессору.
Этим будет заниматься отдельная часть схемы устройства Zero Cross Detector. Он просто дожидается, когда напряжение на линии будет 0 вольт, и подает об этом сигнал. В сетях с частотой 50 Гц, сигнал будет приходить каждые 10 миллисекунд.



Электрическое напряжение распространяется со скоростью света, и поэтому можем условно принять, что момент ZC во всех точках сети происходит одновременно.

В интернете можно найти примеры схем детектора под названиями Детектора нуля или Zero Cross Detector.


Полезный сигнал


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



Другой вариант: как в стандарте X10, наличие сигнала означает 1, а его отсутствие 0.

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


Подробнее о том, как эффективно генерировать синусоидальный сигнал, расскажу в следующей статье.

Шум


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

Для понимания, сравним выделенную линию передачи данных с ЛЭП.
Выделенная линия это отдельный провод, по которому общается некоторое количество устройств. Можно сравнить с пустой комнатой, в которой можно комфортно общаться.



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



Протокол


Кодирование очень простое выбираем несколько символов и ставим в соответствие каждому какую-либо частоту сигнала. Для простоты сделаем три символа:

  • Start по этому символу устройство поймёт, что началась передача кадра;
  • 0 это символ бита 0;
  • 1 это символ бита 1.


Передатчик по сигналу из ZC детектора на короткое время генерирует синусоиду нужной частоты. И таким образом передается по одному символу (S, 0 или 1) за один переход напряжения сети через ноль (каждые 10 миллисекунд). Приемники измеряют этот сигнал, узнают его частоту и записывают соответствующий этой частоте символ (S, 0 или 1) в буфер.


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

Формат кадра


Нужно ещё придумать формат кадра, который мы будет передавать с помощью этих символов. Есть несколько важных моментов, которые отразятся на формате данных: длина кадра, адресация, проверка целостности.

Длина кадра
Чем больше порция данных, тем меньше накладных расходов на передачу данных, так как помимо самих данных в кадре есть служебная информация вроде контрольной суммы и адреса назначения. Но чем меньше порция данных, тем больше вероятность успешной передачи. Тут важно найти золотую середину. Определяется это обычно опытным путем. Если взять пример из компьютерных сетей, то в Ethernet кадре было выбрано ограничение в 1500 байт данных (несмотря на то, что эта цифра быстро устарела, она используется до сих пор).


При сильном увеличении длины кадра, вероятность передать хоть какие-то данные стремится к нулю.

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

Длина адреса выбирается исходя из максимального количества устройств, которые могут одновременно находится в одной области видимости. Например, 8 бит это максимум 255 устройств (если 0 оставить как широковещательный).

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

Придумаем окончательный вид кадра. Пусть длина адреса будет 8 бит (255 устройств в канале + 1 широковещательный адрес). Затем идут данные 8 бит (1 байт).
Концевиком у нас будет просто результат сложения адреса и байта. Но есть один нюанс: устройство может стабильно ловить сильный шум на частоте наших символов 0 или 1 и думать, что это полезный сигнал. И есть большая вероятность ложно считывать крайние значения типа 0x00 или 0xFF. Для защиты от этого, при подсчете концевика, просто будем прибавлять число 42.

Примерно так будет выглядеть один кадр данных: отправляем число 110 на устройство с адресом 17, концевик 169 (110 + 17 + 42).


Целый кадр будем собирать по кусочку из приходящих символов 0 и 1 после символа Start.

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


Каждый следующий символ (0 или 1) последовательно пишем в буфер приема и инкрементируем счетчик бит.


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



Если значения сошлись, извлекаем из кадра данные и отправляем в вышестоящий протокол.



Если значения не сошлись, продолжаем ждать символ Start. И всё заново.

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

Итог


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

Возможно кто-то в комментариях подкинет ещё идей. Буду рад обратной связи!

Ссылки и материалы по теме:
Про шум в сетях
Ещё про шум в сетях
Один из вариантов Детектора нуля
Wiki: Связь по ЛЭП
Wiki: Трёхфазная система электроснабжения
ГОСТ Р 51317.3.8-99 (МЭК 61000-3-8-97) Совместимость технических средств электромагнитная. Передача сигналов по низковольтным электрическим сетям.
Подробнее..
Категории: Plc , Разработка систем связи , Программирование микроконтроллеров , Stm32 , Передача данных , Ацп , Блог компании directum , Power line communication , Лэп , Цап , Линии электропередач

Клиент-серверный обмен данными между двумя PLC серии S7-1500 по протоколу OPC UA

04.01.2021 04:07:06 | Автор: admin

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

1. Creating of OPC UA clients with .NET and helper class

https://support.industry.siemens.com/cs/document/109737901/creating-of-opc-ua-clients-with-net-and-helper-class?dti=0&pnid=13716&lc=en-RU

2. OPC UA Client Library

https://support.industry.siemens.com/cs/document/109748892/opc-ua-client-library?dti=0&pnid=13716&lc=en-RU

3. On-line справка Step 7 Professional V15.1

4. SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL, ET 200pro Communication. Function Manual (10/2018 A5E03735815-AG)

5. Здравый смысл

Протокол OPC UA (http://personeltest.ru/aways/ru.wikipedia.org/wiki/OPC_UA) появился впервые в контроллерах Simatic во второй версии прошивки и в Step 7 версии 14. Тогда контроллер можно было настраивать только в качестве OPC UA - сервера, то есть ПЛК мог отвечать на запросы и отдавать данные, но не мог сам инициировать связь и опрашивать других участников сети.

Радикально ситуация меняется в ноябре-декабря 2018 года с выходом прошивки 2.6 и Step 7 версии 15.1. Появляется возможность настроить CPU в качестве OPC UA клиента. А это, в свою очередь дает нам возможность организовать защищенный канал обмена информацией машина-машина (контроллер-контроллер). И это важно (про существование Secure OUC мне так же известно, однако OUC являет собой обмен данными в свободном формате, чего хватает для маленьких объемов, но отсутствие строгого формата данных накладывает свой отпечаток). Большинство протоколов полевого уровня для промышленности разрабатывалось в прошлом веке и рассчитаны они, в первую очередь, на честных людей. Только время идет, честных людей становится меньше, злодеев - больше, поэтому обмен данными надо как можно лучше спрятать, зашифровать, запаролить, обложить сертификатами, а всем посторонним в ответ показывать обидные жесты и говорить неприличные слова.

Итак, настройка контроллера (S7-1512 FW2.6) в качестве OPC UA сервера.

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

  1. По умолчанию OPC UA отключен в настройках, поэтому заходим в свойства CPU, ищем ветку OPC UA Server General и активируем OPC UA Server.

2. Использование OPC UA в контроллерах Simatic требует приобретение лицензии, поэтому покупаем лицензию, заходим в свойства Runtime licenses OPC UA и ставим тип приобретенной лицензии. Лицензии для 1500ой серии бывают трех типов: маленькая, средняя и большая, в зависимости от типа CPU. S7-1510 и S7-1512 требуют small.

3. По желанию можно задать Application name для OPC UA сервера, порт и временные интервалы. Интервалы сбора (sampling) и публикации (publishing) я выставил минимальными. Стоит помнить, что уменьшение интервалов повышает нагрузку на CPU. Имя приложения и номер порта оставил по умолчанию.

4. Базовая настройка закончена. Компилируем и грузим PLC.

5. Пора бы и проверить, работает ли вообще. Запускаем программу OPC UA Client (ее можно скачать с SIOS по первым двум ссылкам в начале заметки). Ставлю ip адрес моего контроллера 192.168.43.10 и нажимаю кнопку Get Endpoints. Получаю возможные точки входа

Захожу по самому первому варианту, без сертификатов, без шифрования, без пароля, нажимаю Connect to selected Endpoints и перехожу на вкладку Browse nodes. В контроллере загружена программа управления котельной, нахожу одну переменную (Node или узел так называется тэг или переменная в протоколе)

В правой верхней части есть строчка Node id (идентификатор узла или адрес переменной), выделяю его мышкой и жму Ctrl-C

Перехожу на вкладку Read/Write, вставляю скопированный node id и нажимаю кнопку Read

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

Закрываю программу. Базовый функционал есть, и он работает. Но этого мало. Сейчас OPC UA сервер настроен на режим заходи, кто хошь, бери, че хошь. Необходимо добавить немного безопасности.

6. Включаем глобальные настройки безопасности в свойствах CPU, Protection&Security Certificate Manager, ставим галочку Use global settings

7. В навигации всего проекта находим Security Settings Settings. Смело нажимаем кнопку Protect this project. Действие необратимое. Снять защиту с проекта уже не получится. Дело в том, что оффлайновый проект будет содержать сертификаты серверной и клиентской машины, они должны быть защищены во избежании покражи. После нажатия кнопки Protect система предложит создать администратора проекта:

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

8. После того, как мы активировали глобальные настройки безопасности, необходимо заново вручную сгенерировать сертификат контроллера. В дальнейшем лучше, конечно же, сразу защищать проект, создавать администратора проекта и ставить контроллерам глобальные настройки безопасности, но данная заметка частично носит общеобразовательный характер. Возвращаемся в настройки CPU, ищем OPC UA Server Security

Нажимаем кнопку рядом с надписью Server certificate,а в появившемся окне кнопку Add new.

Создаем новый сертификат устройства, все значения остаются по умолчанию. Сертификат, как видно, подписан серьезной организацией! В итоге все становится вот так:

Сейчас предлагаю скомпилировать проект, загрузить его в ПЛК и проверить программой, как работает связь. На самом деле, в результате последних изменений в настройках уровень секьюрности не поднялся ни на йоту. Все это было лишь подготовительным процессом. Потихоньку приходит время приступать к настройкам контроллера, который будет играть роль OPC UA клиента, проверить обмен данными, ну а потом уже закрыть все бреши в безопасности. Но вначале необходимо выгрузить xml файл с описанием всех тэгов (узлов, nodes) контроллера-сервера. Этот файл формируется достаточно просто система выбирает только те переменные, которые помечены флагом Accessible from HMI/OPC UA и разрешает их запись, если стоит флаг Writable from HMI/OPC UA . При этом блок данных тоже должен быть доступен по OPC UA (по умолчанию доступен). Например:

Для экспорта снова заходим в настройки CPU и ищем там OPC UA Server Export, нажимаем кнопку Export OPC UA XML file

Переходим к настройкам OPC UA клиента, то есть той стороны обмена, которая будет инициировать связь, запрашивать и записать переменные. В качестве клиентской части у меня выступает S7-1510 с прошивкой FW2.6.

9. Добавляю контроллер в проект и сразу активирую глобальные настройки безопасности.

10. Активирую OPC UA клиента

11. Активирую лицензию OPC UA

12. Генерирую сертификат этого второго, клиентского контроллера. В дальнейшем контроллер-сервер и контроллер-клиент обменяются (не без моей помощи) своими сертификатами, а подключение незнакомых устройств будет запрещено. В свойствах CPU идем на Protection & Security, жмем Add new.. в таблице Device certificates, жмем на кнопку в появившейся пустой строке, жмем Add new в появившемся окне, наблюдаем уже знакомое окно создания нового подписанного сертификата:

В поле usage я дополнительно указал, что сертификат используется для OPC UA Client'а, по умолчанию у меня был выставлен Tls.

13. Наступает одно из самых интересных: настройка клиентского интерфейса,а точнее настройка соединения к серверу и создания наборов данных для чтения и/или записи. В структуре проекта у второго (клиентского) контроллера:

PLC_2 OPC UA communication Client Interfaces Add new client interface

Жмем кнопку Import interface и подгружаем ранее экспортированный XML файл

Теперь открыты все Nodes серверного контроллера. Поскольку стоит задача учебного характера, требуется немного просто считать 4 переменных блока OKPumpsAuto.

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

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

Необходимо прописать ip-адрес сервера, в моей случае 192.168.43.10.

На странице Security выбираем ранее созданный клиентский сертификат и пока ничего более не меняем.

Создание и заполнение клиентского интерфейса привело к автоматическому созданию двух блоков данных: Client interface_1_Data и Client interface_1_Configuration.

Смотрим блок данных Data, там уже указаны те переменные, которые планируем читать. Чертовски удобно.

14. Теперь необходимо написать программу, которая будет устанавливать связь с OPC UA сервером, готовить канал связи, читать информацию и закрывать соединение. Программа носит строго демонстрационный характер, в боевых задачах она должна быть написана по-другому. В онлайн справке на вызываемые блоки находится все необходимая информация. Там же приводится пример на языке SCL, лучше подходящий к промышленному применению, но не такой наглядный, как в моем случае.

В проект добавляются следующие меркерные переменные

Ищем функцию OPC_UA_Connect и перетаскиваем ее в нетворк OB1

Имя экземплярного блока я оставил по умолчанию. Что радует этот вызов имеет графический конфигуратор, как, например, вызовы S7-связи в TIA Portal'е или вызов PID-регулятора. Этот конфигуратор экономит просто уйму времени, а это не может не радовать.

Остается выбрать только созданный клиентский интерфейс (он один) и обвязать блок вспомогательными переменными.

Для лучшего понимания привожу скриншот из онлайн справки Step 7. Именно в таком порядке необходимо выполнять вызовы (как минимум три) перед тем, как приступить к чтению/записи данных. Любой вызов выполняется по переднему фронту входа Req. Успешное или неуспешное выполнения вызова я фиксирую (не сбрасывая, сброс только ручной) в переменных с именами done или err.

Теперь привожу скриншоты всех нетворков программы уже после того, как я последовательно сделал запрос на выполнение функциональных блоков. Как вы видите бит запроса req у меня выставлен в истину (блок отрабатывается только по переднему фронту), биты успешного исполнения (done) выставлены в истину. Если у вас ни done, ни error не выставляется в истину,а connectionid первого вызова остается равным нулю, значит, что-то сделано не так. Например, используется не тот Server Endpoint или неправильно установлен сертификат. Эти вызовы должны вызваться последовательно один за другим. Я взводил биты руками и смотрел на результат вызова, а только потом переходил к следующему. Очевидно, что полноценная программа должна осуществлять вызов автоматически и переходить на следующий шаг в зависимости от результата текущего.

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

В результате вызова нетворка 4 в блоке данных DB2 появились прочитанные данные:

15. В настоящий момент два контроллера общаются по протоколу OPC UA, цель почти достигнута. Но не полностью. Настройки безопасности до сих пор находятся на уровне бери, чо хошь. Я спокойно могу подключиться программой OPC UA Client и читать/записывать все возможные данные. Давайте ограничим круг общения этих ПЛК, пусть они дружат только друг с другом. Переходим на серверный контроллер, свойства CPU, OPC UA Server Security Secure channel, убираем из Endpoint'ов политику No Security

Проматываем ниже до Trusted Clients. Добавляем сертификат контроллера-клиента (PLC_2). Снимаем галочку Automatically accept client certificates during runtime. Сервер теперь не будет общаться ни с кем, кроме как с клиентским PLC.

Переходим на User authentication, запрещаем гостевой доступ, создаем логин/пароль для пользовательского доступа: user1 / password1.

Прогружаем серверный PLC. Возвращаемся к клиентскому PLC, открываем Client interface, закладка Configuration, выбираем Security, в поле General выставляем режим и политику безопасности:

Проматываем ниже, выбираем тип аутентификации пользователь и пароль, указываем имя пользователя user1, пароль password1

Снимаем галочку Automatically accept server certificate during runtime

Жмем на зеленую стрелочку, сразу переходим на другую закладку настроек ищем там поле сертификаты партнерских устройств и добавляем в него сертификат сервера

Компилируем и прогружаем клиентский ПЛК (PLC_2), открываем мониторинг OB1 и последовательно вручную исполняем блоки в нетворках 1..4 Если все сделано правильно, то все блоки отработают успешно, а данные будут успешно прочитаны в DB2.

16. Осталось лишь проверить, пустит ли кого-нибудь еще серверный контроллер. Запускаем OPC UA Client и пробуем подключиться. Список Endpoint'ов возвращается. Подключаемся по Basic256 SignAndEncrypt, указав имя пользователя user1 и пароль password1.

Предлагается проверка сертификата сервера, принимаем его

Но соединение не устанавливается, сервер не принимает сертификат левого клиента.

Итого, поставленная цель достигнута. Настроен безопасный обмен данными на уровне ПЛК, то есть - "горизонтальное" взаимодействие.

Подробнее..
Категории: Plc , Промышленное программирование , Программирование микроконтроллеров , Siemens , Simatic , Opc , Plc контроллер

Power-line communication. Часть 2 Основные блоки устройства

26.01.2021 02:10:54 | Автор: admin

Часть 1 Основы передачи данных по линиям электропередач

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

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

- Введение
- Мозги устройства микроконтроллер
- Основные требования к микроконтроллеру
- Выбор подходящего микроконтроллера
- Особенности питания устройства

Дисклеймер: статья не является руководством по созданию устройства и не является справочником по электронным компонентам. Это просто результаты моих экспериментов и некоторый накопленный практикой опыт, который, надеюсь, будет полезен тем, кто интересуется темой. Если есть какие-то замечания, интересные ссылки и книги, обязательно оставляй это в комментах.

Введение

Для начала кратко вспомним из части 1, как происходит передача данных. На изображении одна из фаз ЛЭП. Красное устройство передает, синие слушают. Биты данных один за одним передаются в виде синусоидальных сигналов различной частоты (FSK модуляция).

В мозге устройства микроконтроллере зашит протокол, по которому передаются/принимаются данные. Также в прошивке микроконтроллера для каждого передаваемого символа (или бита) задана соответствующая частота сигнала.

Для примера: если передается символ 0, то генерируется полезный сигнал в виде синусоиды 74 кГц. А если передается 1, то генерируется синусоида с частотой, например, 80 кГц. Номиналы частот не особо важны, просто выбираются любые из разрешенных диапазонов. Главное, чтобы приемник смог их различить.

В первой части статьи упоминалось про третий символ S, который означал начало кадра. Он также кодировался своей определенной частотой. Когда устройство получало символ S, входной буфер очищался. Для простоты в этой статье будут упоминаться только 0 и 1.

Передающие и принимающие устройства синхронизируются между собой с помощью отдельного блока устройства zero cross детектора.

Представим передающее устройство, в котором есть подготовленный кадр данных некий массив нулей и единиц, и этот кадр нужно передать по PLC каналу связи (ЛЭП). Передача/прием кадра происходит по одному биту за один синхросигнал из ZC детектора.

Физически это значит, что за один синхросигнал из ZC детектора генерируется один полезный сигнал определенной частоты. В нашем случае это синусоиды 74 кГц или 80 кГц.

Таким образом, бит за битом, передается кадр данных в PLC канал. Совместно с микроконтроллером генерацией сигналов будет заниматься отдельная часть схемы. Назовём её Выходная цепь.

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

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

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

В следующей части рассмотрим как устройство можно согласовать с сетью 220 В, работу ZC детектора, а также про входную и выходную цепи.

Мозги устройства микроконтроллер

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

Микроконтроллер это такой мини-компьютер, который в одном корпусе содержит процессор (ЦПУ), память (ПЗУ и ОЗУ), ввод-вывод и периферийные устройства. По сути, внутри уже все есть для работы: подаем питание и поехали. Дальше все зависит уже от программы прошивки, которую мы в него записали.

Рисунок с сайта digikey.comРисунок с сайта digikey.com

Сейчас выпускают микроконтроллеры с большим количеством различной встроенной периферии. Это очень удобно, так как меньше необходимости во внешних компонентах, что экономит место на печатной плате (и, конечно же, ваши денежки). Внутри может иметь ЦАП и АЦП, часы с календарем. Даже встроенный USB уже не удивляет.

На рынке огромное разнообразие микроконтроллеров с разной вычислительной мощностью и периферией. Обычно они группируются в серии и подходят под разные классы задач. Например, чтобы помигать светодиодом в миниатюрном устройстве, нам не нужен мощный камень, на котором можно запустить Linux, подойдет ATtiny. Но для нашего устройства его уже не хватит, так как нужны ЦАП, АЦП и быстрые вычисления в реальном времени.

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

Основные требования к микроконтроллеру

Производительность

Основной нагрузкой на ЦПУ будет обработка оцифрованного входного сигнала с помощью ДПФ для выяснения того, какой символ был закодирован в сигнале: 0 или 1. Далее этот символ будет отправляться в протокол на уровень выше. Больше всего вычислений будет происходить именно при подсчете гармоник в ДПФ.

Циклично, с интервалом 10 миллисекунд, АЦП будет оцифровывать входящий сигнал и сохранять его в виде массива чисел. Затем этот массив несколько раз прогоняется через ДПФ для выяснения амплитуд гармоник каждой из интересующих нас частот в полезном сигнале.

Результат визуально можно представить в виде эквалайзера, на котором нарисованы полоски определенных частот разной высоты (амплитуды). Для подсчета высоты каждой отдельной полоски нужно сигнал прогонять через ДПФ.

После подсчета некоторого количества гармоник, делаются выводы о том, какой символ закодирован.

В самом простом случае можно просто сравнить амплитуды гармоник 74 и 80 кГц между собой. Если в сигнале преобладает гармоника с частотой 74 кГц, записываем в входной буфер бит 0.

Если в сигнале преобладает гармоника с частотой 80 кГц, записываем в входной буфер 1.

В таком случае, любой шум что-то означает: 0 либо 1, даже если ничего не передавалось. Отделением зерен от плевел будет заниматься отдельная подпрограмма уровнем выше которая будет проверять целостность кадра и прочие прелести.

Задача же этого уровня просто, как конвейер, подавать 0 и 1 наверх, а дальше из них будут складываться правильные целостные кадры данных. Или не будут.

Также можно заморочиться и дополнительно рассчитывать амплитуды смежных гармоник и узнавать уровень шума относительно полезного сигнала. Можно программно фильтровать сигнал и тд. Вариантов много.

Суть в том, что считать, возможно, придется много. Успевать считать нужно гарантированно, так как это реалтайм-конвейер.

Если разложить всю нагрузку на которую ЦПУ тратит время друг за другом, то получим примерно это:

  • оцифровка сигнала

  • подсчет амплитуд гармоник через ДПФ и анализ результата

  • прочая нагрузка (обработка прерываний из интерфейсов USB или CAN, обработчики таймеров, моргания светодиодами, работа с памятью, какие-то вычисления по протоколу и т.д.)

Это должно циклично выполняться каждые 10 миллисекунд снова и снова. ЦПУ никогда не должен быть загружен на 100%, иначе есть риск не успеть посчитать что-то важное. Поэтому всегда нужно оставлять запас по производительности.

Энергоэффективность

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

Подобрать нужную производительность ЦПУ можно опытным путём: берём микроконтроллер с запасом вычислительной мощности и памяти, пишем код, запускаем и смотрим за какое время он справляется с конкретными задачами. Выбираем из линейки контроллеров подходящий, оставляя небольшой запас мощности и памяти (для возможных обновлений и улучшений).

Должен быть достаточно быстрый АЦП

Нам нужно оцифровывать входной аналоговый сигнал и желательно, чтобы был встроенный АЦП. Точность тут не так важна, как скорость. Так как измеряемый сигнал имеет частоту до сотни килогерц. Для корректных вычислений гармоник есть условие.

Частота дискретизации должна быть минимум в два раза больше частоты измеряемого сигнала [Теорема Котельникова].

Это значит, что для распознавания сигнала нужно сделать от двух точек измерения на период. А по-хорошему 4-5. Посмотрим на примере.

Представим, что мы измеряем сигнал, в котором есть нужная нам гармоника частотой 80 кГц. У сигнала с частотой 80 кГц период 1/80000 = 12,5 микросекунд. Чтобы оцифровать 5 точек на период нужно успевать делать измерение раз в 2.5 микросекунды для адекватного распознавания сигнала.

С пятью точками измерений на период уже выглядит неплохо. ДПФ с этим отлично справится.

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

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

Не похоже на синусоиду.

Если интересно посмотреть, что будет, если проводить измерения частотой меньше двух точек за период, то поищите в гугле картинки Эффект алиасинга.

Должен быть достаточно быстрый ЦАП

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

Представим на примере синусоиды с частотой 80 кГц, период 12.5 микросекунд. Возьмем для начала 4 точки на период. Генерация каждые 3.125 микросекунды.

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

Увеличим количество точек вдвое. Генерация каждые 1.56 микросекунды.

Нужна достаточная скорость ЦАП для того, чтобы сигнал был хотя бы похож на синус. В нашем случае, с сигналом частотой до 80 кГц, будет достаточно чтобы ЦАП успевал менять уровень сигнала раз в 1.5 микросекунды. Если успеет быстрее, то еще лучше.

С выхода ЦАП этот угловатый сигнал проходит через пассивный фильтр нижних частот и в сглаженном виде идет на усилитель выходной цепи.

Если нет АЦП

Помню, в самом начале я проводил эксперименты на 8-битных AVR от Atmel серии ATmega8, и у них в распоряжении не было АЦП. Но на них было очень удобно начинать знакомство с миром микроконтроллеров. Низкий порог вхождения и никаких танцев с бубнами при запуске.

Ну так вот, входной сигнал я решил оцифровывать простой ножкой в режиме входа. Если входное напряжение выше 2.5В, то у ножки было логическое состояние 1, если ниже 2.5В, то 0. В равные промежутки времени просто считывалось текущее состояние ножки и эти значения записывались в массив.

И этот оцифрованный сигнал прогонялся через ДПФ и вычислялось наличие нужных гармоник. Ни о какой точности или чувствительности речи и не шло, но это работало.

Если нет ЦАП

Аналогичная ситуация на ATmega8 была с ЦАП. Его там нет, и мне очень не хотелось заморачиваться с внешним ЦАП.

Оказалось, что можно пожертвовать логическими выходами микроконтроллера и подключить к ним резисторную матрицу R-2R. Таким образом из горстки резисторов собрать свой ЦАП с нужной разрядностью.

Картинка с сайта easyelectronics.ruКартинка с сайта easyelectronics.ru

Подавая 0 и 1 на выходы микроконтроллера, можно получать нужный уровень напряжения на выходе OUT. Чем больше выходов будет использовано, тем выше разрядность ЦАП. По схеме R-2R оставил ссылку в конце.

Выбор подходящего микроконтроллера

После экспериментов на ATmega8 мне захотелось улучшить то, что есть. Выбирая из разных вариантов, я положил глаз на STM32. А конкретно на STM32F103 это 32-битные микроконтроллеры на ядре ARM Cortex-M3 (до 72 MHz).

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

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

Производительность?

Схема тактирования позволяет работать ЦПУ на частоте 72 MHz, что после 8-битных на 20 MHz было с запасом. Хватало для более точных расчетов по алгоритму ДПФ.

Энергоэффективность?

При почти максимальной нагрузке потреблял около 40-50 мА. Дешевый стабилизатор напряжения в схеме питания на 100 мА с этим справлялся. Даже с учетом остальной маложрущей периферии этого было достаточно.

Достаточно быстрый АЦП?

Разобрался, как разогнать до максимальной скорости АЦП при частоте ЦПУ 72 MHz. Так как ранее было сказано, что полезный сигнал будет частотой в районе 80 кГц, то будем считать исходя из этого.

В доках для STM32 нашел, как вычислять минимальное время преобразования: нужно к настраиваемому времени семплирования (минимум 1.5 цикла) прибавить 12.5 машинных циклов. Получается 14 машинных циклов на одну точку измерения.

При определенной настройке схемы тактирования на модуль АЦП приходится 14 MHz. Если перевести в секунды, то 14 циклов при частоте тактирования 14 MHz это одно измерение в 1 микросекунду.

Идеально! Даже если полезный сигнал будет частотой 100 кГц, я смогу измерить 10 точек за один период сигнала. С минимальной точностью, но быстро.

Примерно так будет выглядеть оцифровка синусоиды 80 кГц.

Достаточно быстрый ЦАП?

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

Почитав документацию, я понял, что в ЦАП STM32F103 встроенный ОУ имеет ограничение в 1 MSPS. Получилось настроить генерацию каждой точки сигнала раз в 1 микросекунду.

Примерно так при этом будет выглядеть синусоида с частотой 80 кГц на выходе из ЦАП.

Периферия

Что еще мне понравилось в STM32F103 это наличие встроенного USB. Там есть режим эмуляции COM порта. Мне показалось это очень удобным, особенно после внешних преобразователей USB-UART.

Можно подключать устройство к ПК обычным шнурком от телефона и через терминал посылать на устройство какие-нибудь отладочные команды.

Для экспериментов подключал два PLC устройства к двум компам, и они посылали друг другу ASCII символы, вводимые с клавиатуры. Получилось что-то вроде чата через розетку 220 В.

Особенности питания устройства

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

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

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

Остальные потребители вроде усилителей входного сигнала во входной цепи, EEPROM памяти или какие-то UART конвертеры потребляют немного.

Стабильное питание микроконтроллера

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

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

Примерная картина потребления мощностиПримерная картина потребления мощности

При передаче кадра это происходит каждые 10 миллисекунд длиной в 1 миллисекунду.

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

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

Совет 1 - Разделить землю на аналоговую и цифровую

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

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

Для питания условно цифровых компонентов схемы (микроконтроллер, EEPROM память и т.д.) от самого блока питания должна идти отдельная линия, можно назвать её DGND.

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

Совет 2 - Не забыть про керамику

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

Картинка с сайта allexpress.comКартинка с сайта allexpress.com

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

С танталовыми осторожнее, они красиво взрываются :).

Еще надо не забыть защитить ножку Reset микроконтроллера, как указано в Datasheet. В противном случае микроконтроллер может внезапно перезагружаться. Если нет светодиодной индикации запуска программы микроконтроллера, то можно этого даже не заметить.

Совет 3 - Экранировать цифровые компоненты

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

Мне помогло расположение микроконтроллера на другой от ВЧ трансформатора стороне печатной платы и наличие земляного полигона под корпусом микроконтроллера.

Картинка с сайта caxapa.ru "Помехоустойчивые устройства, Алексей Кузнецов"Картинка с сайта caxapa.ru "Помехоустойчивые устройства, Алексей Кузнецов"

Подробнее можно почитать в статье по ссылке в конце.

Заключение

В этой части мы в общих чертах разобрали чем занимается микроконтроллер. Узнали некоторые особенности питания устройства и возможные проблемы.

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

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

У кого был/есть какой-либо опыт в PLC обязательно делитесь этим с остальными в комментариях :)

Полезные ссылки

https://nag.ru/articles/article/24485/strasti-po-plc.html - интересная статья по истории PLC
https://www.electronshik.ru/catalog/interfeys-modemy-plc - заводские PLC микросхемы с datasheet (там много схем и характеристик)
https://ru.wikipedia.org/wiki/Частотная_манипуляция - FSK модуляция
http://www.atmega8.ru/ - про ATmega8

STM32
https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html - STM32F103
https://themagicsmoke.ru/courses/stm32/led.html - Помигать светодиодом на stm32
https://blog.avislab.com/stm32-clock_ru - схема тактирования stm32
http://personeltest.ru/aways/habr.com/ru/post/312810/ - подробнее про ЦАП в stm32
https://blog.avislab.com/stm32-adc_ru/ - АЦП в stm32
https://blog.avislab.com/stm32-usb_ru/ - USB в stm32

Аналоговая часть
http://easyelectronics.ru/parallelnyj-cifro-analogovyj-preobrazovatel-po-sxeme-r-2r.html - преобразователь по схеме R-2R
http://caxapa.ru/lib/emc_immunity.html - "Помехоустойчивые устройства", Алексей Кузнецов
https://www.ruselectronic.com/passive-filters - пассивные фильтры

Подробнее..
Категории: Plc , Разработка систем связи , Программирование микроконтроллеров , Stm32 , Передача данных , Ацп , Avr , Блог компании directum , Power line communication , Цап , Линии электропередач , Stm32f103 , Atmega8

Power-line communication. Часть 3 Основные блоки устройства

25.05.2021 00:13:35 | Автор: admin

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

Осталось разобраться, что такое ZC детектор, на примере одной из его возможных реализаций. Посмотрим, как можно реализовать входную и выходную сигнальные цепи, и как их подключить к сети 220 В.

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

Zero cross детектор

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

Передающее устройство, отправляет подготовленный кадр данных по одному биту за один синхросигнал из ZC детектора. Физически это значит, что за один синхросигнал из ZC детектора генерируется один полезный сигнал определённой частоты, которым кодируется один бит.

В электросетях с частотой 50 Гц, синусоида напряжения пересекает ноль 100 раз в секунду.

Есть несколько вариантов исполнения ZC детектора. Ниже я покажу пример реализации на оптопаре.

Начнём с конца схемы сначала представим, как сигнал с ZC детектора попадает на контроллер.

На картинке схема с подтягивающим pull-up резистором и ключом. При замыкании ключа, на вход МК будет подаваться логический 0, а при размыкании ключа, pull-up резистор будет подтягивать напряжение на входе МК до логической единицы.

На место ключа ставим оптрон. Оптрон (оптопара) это простой элемент, в котором с одной стороны светодиод, а с другой фототранзистор.

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

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

Для выпрямления можно использовать smd мостовой выпрямитель.

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

Номинал сопротивления можно вычислить исходя из характеристик фотодиода в оптопаре

В datasheet на оптопару пишут максимальный ток, на который рассчитан фотодиод, исходя из этого нужно выбрать сопротивление с расчётом на 310 В. Чтобы резистор не перегрелся, можно вместо одного последовательно поставить несколько резисторов для эффективного отвода тепла (это особенно полезно если у вас SMD резисторы).

Из datasheet на PLC817Из datasheet на PLC817

На примере PC817 видно, что максимальный ток, который выдержит светодиод - 50 мА. Максимальный коэффициент передачи при 20 мА. И "замыкать ключ" он будет уже и при >1 мА.

SMD резисторы типоразмера 1210 выдерживают рассеивание до 0.5 Вт мощности. Максимальный постоянный ток, который мы может пропускать при 310 вольт равен 0.5/310 = 0.00161 А. С учетом, того что у нас пульсирующее напряжение, округлим до 0.002 А (2 мА). Этого тока достаточно, чтобы "ключ замыкался". Номинал сопротивления при этом равен 310/0.002 = 155000 Ом. Итог: ставим последовательно три SMD резистора, типоразмером 1210, номиналом 51 кОм каждый.

В итоге, схема ZC детектора выглядит примерно так.

Теперь микроконтроллеры PLC устройств, подключенных к одной фазе могут синхронизироваться между собой с помощью сигнала на ножке "ZC input" из такого ZC детектора.

Схема согласования сигнальных цепей с линией 220 В

Схема согласования закрывает собой компоненты входной и выходной цепей. Входная и выходная сигнальные цепи обычно выполнены на микросхемах усилителях, которые питаются небольшим постоянным напряжением (3-12 В). Подключить их напрямую к 220 В не получится.

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

Эта часть схемы принимает различный вид в разных datasheet на готовые PLC микросхемы. Опишем минимально работоспособный вариант.

Для первых опытов

Можно взять ферритовое кольцо типа 17,5x8,2x5 М2000Н, есть в любом магазине электроники. Провод МГТФ наматываем сразу 3 обмотки в 20 витков.

Конденсатор плёночный из серии MKP или любой аналогичный, который выдерживает от 220 В переменки (с запасом).

Для отсечения ненужных низкочастотных гармоник ставится конденсатор, который выдержит 220 В. После него, для гальванической развязки и также фильтрации, высокочастотный трансформатор. Трансформатор можно сделать с отдельными обмотками для входной и выходной цепей (как на изображениях) или использовать одну обмотку на "вход"/"выход".

Для защиты усилителей от импульсных перенапряжений можно поставить защитные диоды (супрессоры) и/или варисторы с предохранителем. Тема защиты устройства от электрических неприятностей довольно обширная, в этой статье не рассматривается. Но забывать про это не стоит.

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

Входная цепь измерение полезного сигнала

Входная цепь должна выполнить как минимум две задачи:

  • отфильтровать грубый входящий сигнал, срезав все лишнее;

  • после этого усилить сигнал до приемлемого уровня, подходящего для измерения и оцифровки с помощью ЦАП микроконтроллера.

Фильтрация

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

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

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

Усиление

У АЦП есть такая характеристика как разрешение. Оцифровка сигнала происходит с некоторой дискретностью. А после пассивной фильтрации входной сигнал заметно похудеет в амплитуде. И если подать на АЦП очень слабый сигнал, то его форма сильно исказится и потеряется большая часть информации о сигнале.

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

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

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

Ссылки на статьи про операционные усилители и их про каскадное подключение оставил в конце статьи.

Выходная цепь генерация полезного сигнала

Задача выходной цепи фильтровать и усиливать сигнал из ЦАП микроконтроллера.

Микроконтроллер по специальному алгоритму генерирует полезный сигнал, нужной длительности и частоты, соответствующей передаваемому символу. На выходе из ЦАП у нас получается просто болванка полезного сигнала, угловатая, примерно похожая на синусоиду, но (самое главное!) нужной нам частоты.

Далее сигнал сглаживается фильтром и отправляется в аналоговую часть схемы (усилитель и схема согласования с 220 В).

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

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

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

Гуглить их можно по фразе audio amplifier btl 1w. Но тут нужно учесть, что они обычно рассчитаны на аудио сигналы до 20 кГц, и производитель не рассчитывал, что их будут использовать в PLC модеме. Есть модели, которые хорошо усиливают частоты до 100-150 кГц, и обычно в datasheet об этом не пишут.

Плюсы:

  • они очень удобны тем что там встроенная стабилизация сигнала;

  • есть режим mute - мизерное потребление в режиме простоя;

  • хватает однополярного питания не надо париться с блоком питания.

Минусы:

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

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

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

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

Итого

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

В следующей части статьи планировал на примерах показать, как можно программно генерировать синус нужной частоты для ЦАП в STM32. И заодно как обработать приходящий на АЦП сигнал и выяснить наличие в нём нужных гармоник (частот) полезного сигнала.

Полезные ссылки

Общее:

Фильтры:

Операционные усилители:

ZC детекторы:

Схемы согласования с 220 В в доках на PLC микросхемы:

Подробнее..
Категории: Plc , Разработка систем связи , Программирование микроконтроллеров , Stm32 , Передача данных , Ацп , Блог компании directum , Power line communication , Лэп , Цап , Линии электропередач

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru