Часть 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 детектора, а также про входную и выходную цепи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Представим, что мы измеряем сигнал, в котором есть нужная нам гармоника частотой 80 кГц. У сигнала с частотой 80 кГц период микросекунд. Чтобы оцифровать 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. Таким образом из горстки резисторов собрать свой ЦАП с нужной разрядностью.

Подавая 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 на микроконтроллер.

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

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

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

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

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

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

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

Заключение

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

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

В следующей части подробнее разберём оставшиеся блоки устройства: входная и выходная цепи, 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 - пассивные фильтры

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

• Часть 2 Основные блоки устройства (начало)

Во второй части статьи мы начали знакомиться с основными блоками устройства для передачи данных по 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

На примере 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. И заодно как обработать приходящий на АЦП сигнал и выяснить наличие в нём нужных гармоник (частот) полезного сигнала.

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

Общее:

• https://nag.ru/articles/article/24485/strasti-po-plc.html Интересная статья по истории PLC;

• https://cmi.to/разрешение-и-разрядность-ацп/ Про разрешение АЦП;

• https://ru.wikipedia.org/wiki/Частотная_манипуляция FSK модуляция;

• http://personeltest.ru/aways/habr.com/ru/post/312810/ - интересно, подробно про ЦАП в stm32;

• https://narodstream.ru/stm-urok-30-hal-dac-sinus-dma/ STM32, синус через DMA;

• http://www.electrosad.ru/Electronics/zaschita.htm Защита электронных схем.

Фильтры:

• https://www.ruselectronic.com/passive-filters/ Пассивные фильтры;

• https://www.ruselectronic.com/achh-and-fchh/ Про АЧХ и ФЧХ.

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

• https://cxem.net/beginner/beginner96.php ОУ для начинающих;

• http://hardelectronics.ru/lm358.html Примеры одного дешевого ОУ;

• http://easyelectronics.ru/operacionnyj-usilitel.html ещё про ОУ

• http://zpostbox.ru/kaskadnoye_vklyucheniye_operatsionnykh_usiliteley.html Каскадное подключение ОУ.

ZC детекторы:

• https://cxemka.com/62-detektor-perehoda-cherez-nol-s-galvanicheskoi-razvjazkoi-i-bez-neyo.html - пример 1;

• https://radio-samodel.ru/detektor%20nulya.html - пример 2;

• http://radiopolyus.ru/radiolicbez/39-radiokonstruktoru/257-detektor-perexoda-cherez-nol - ещё пример;

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

• https://data.electronshik.ru/z/Datasheet/S/ST7540.pdf ST7540;

• http://old.angstrem.ru/netcat_files/229/254/kr1446xk1.pdf КР1446ХК1;

• https://www.electronshik.ru/catalog/interfeys-modemy-plc PLC микросхемы с datasheet, там много схем и характеристик.

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

И мы тут как тут. За изоляцию мы сделали 6 онлайн-митапов, сегодня делимся материалами с трёх, организованных при участии коллег из EPAM и Контура. На каждом рассматривали по две темы:

Backend

• Публичные контракты как обеспечить их согласованность.

• ElasticSearch, и для чего его НЕ надо использовать.

Мобильная разработка

• Навигация в Android-приложении, её кроссплатформенная реализация.

• Как и зачем писать свой фреймворк на iOS. Создали в прямом эфире. (EPAM)

AI Meetup

• Аугментация текстов: как сделать из мухи слона.

• Сокращение длительности чатов техподдержки с помощью машинного обучения. (Контур)

Далее ссылки на записи и подробности о каждом.

Backend Meetup

https://youtu.be/3NLzI4L-diA

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

• к каким проблемам приводит недостаточное внимание к публичным контрактам;

• инструменты (Swagger, OpenAPI, gRPC) и подходы для работы с контрактами на всех этапах разработки ПО;

• опыт применения OpenAPI в нашей платформе Sungero;

• способы версионирования и тестирования контрактов (CDC).

ElasticSearch, и для чего его НЕ надо использовать:

• для чего нужен и из чего состоит ES;

• про опыт его использования в Directum: сборка и анализ логов, полнотекстовый поиск;

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

+наши наработки на GitHub: плагин морфологии для качественной быстрой лемматизации и модификация библиотеки Tika (что меняли, смотри в докладе). Пригодится, если делаете поиск на русском языке.

Мобильная разработка

Доклад про iOS представил приглашённый разработчик из Минского EPAM Игорь Набоков.

Запись лежит в вк и на гугл-диске.

Навигация в Android-приложении:

• как работает навигация, её кроссплатформенная реализация и проблемы, с которыми столкнулись при рефакторинге навигации в Directum Solo ECM-приложении;

• как выделять новые объекты навигации, как строить диплинки, как их вообще реализовать, как сделать версии iOS и Android максимально похожими;

• посмотрели фреймворки, разобрали решения на С#, Xamarin с дополнительным коротким экскурсом в среду поймут все.

Свой фреймворк на iOS:

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

• Рассказал про свой опыт, объяснил, зачем, как, чем может создаваться iOS-фреймворк, какие возникают проблемы, как их решать. Разобрали на примере библиотеки телематики.

• Для практики взяли такую ситуацию: есть набор классов, который нужно собрать в библиотеку, допустим, какой-то логер. Посмотрели, как из этого сделать бинарный фреймворк, как добавить в fastlane нужные сценарии, как создать репозиторий в CocoaPods, как опубликовать CocoaPods, как залить бинарную часть, например, на s3, как потом создать новое приложение и подключить этот самый свежеопубликованный фреймворк.

AI Meetup

Тему машинного обучения для чатов техподдержки раскрыл Константин Фролов из Контура.

На пару минут позже включили запись.

https://youtu.be/DuRVIn1BGAg

Аугментация текстов: как сделать из мухи слона

Работаете с NLP? Отметьте галочкой, где болит:

• мало размеченных данных;

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

• мало сил и времени, чтобы разметить больше данных.

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

Сокращение длительности чатов техподдержки с помощью машинного обучения:

Константин Фролов рассказал, как в Контуре разрабатывали оптимальное ML-решение.

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

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

Судя по ситуации, тема с онлайн-митапами в Directum продолжается. Все следующие события будем освещать на https://meetup.directum.ru/.

Если есть предложения по темам и желание присоединиться в качестве докладчика - пишите по любым каналам @stalyonka или официально на strelkova_aa@directum.ru.

Надеюсь, были вам полезны! И будем.

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

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

Набор артефактов:

1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

1. Руководитель проекта сотрудник, который планирует процесс реализации требований, координирует действия всех участников, вплоть до завершения проекта.

2. Scrum-мастер обычно тимлид группы разработки, занимается управлением процесса разработки, несет ответственность за конечный результат работы разработчиков.

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

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

Совещания:

1. Ежедневный митинг команды.

2. Ретроспектива в конце спринта.

3. Ежеквартальные ретроспективы.

Параметры спринта:

1. Продолжительность: 1 месяц.

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

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

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

Хьюстон, у нас проблемы

Явные проблемы заметили на втором месяце этапа ОПЭ (опытно-промышленной эксплуатации), когда новые требования по дефектам начали закрывать время затраченное на запланированные дефекты и пожелания. Фактически мы стояли на месте. Вероятность успеха сделать все вовремя стремилась к 0.

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

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

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

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

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

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

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

А что думает заказчик? Заказчик недоволен динамикой реализации требований. Но готов рассмотреть вариант с четким и прогнозируемым планом.

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

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

Сильные стороны:

1. Получение результата в ограниченное время.

2. Устранение ненужных действий, которые могут снизить стоимость.

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

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

Слабые стороны:

1. Большие требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

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

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

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

В процессе адаптации к текущему проекту мы постарались минимизировать слабые стороны за счет более простого документирования (мини-техпроекты, создаваемые разработчиками), упрощенного планирования с небольшим числом участников, договорились с заказчиком работать на результат.

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

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

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

• Предельно быстрая доставка заказчику. Короткие итерации.

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

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

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

1. Убрать ненужное

Под ненужным будем понимать следующее:

1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

2. Ненужный код, дублирование кода.

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

4. Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.

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

Что мы сделали, чтобы решить задачу:

1. Детальная проработка требований и согласование описания требований с тимлидом разработки, дополнительная расшифровка требований тимлидом на понятный для разработчиков язык.

2. Ввели отдельную колонку в Trello Техдолг, в которую помещаются задачи с приоритетом, для устранения дублированного кода, для доработки найденных в процессе разработки потенциально сбойных участков и задачи с не оптимальным кодом.

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

4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

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

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

3. Повышение качества кода

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

Для повышения качества были приняты следующие предложения:

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

2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

3. Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

2. На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.

3. Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).

4. Публикация на продуктивный стенд выполняется только один раз в последний день спринта.

5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

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

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

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

6. Не торопиться с принятием решений

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

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

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

1. Организует периодическое обучение, разбор сложных ситуаций.

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимается развитием разработчиков и расширением их компетенций.

5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

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

Основная проблема бережливого производства отодвигание сроков

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

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

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

Итоги

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

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

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

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

1. Обеспечить единую общую среду общения и обмена знаниями.

2. Организовывать совместные видеоконференции, желательно с камерой, чтобы видеть эмоции участников.

3. Не пренебрегать неформальным общением.

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

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

1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

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

3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

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

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

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.