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

В этом году я со своими студентами провел такое проектно-научное исследование в рамках гранта НИУ «МЭИ» на реализацию программы научных исследований «Приоритет 2030: Технологии будущего». Тематикой работы была «Разработка интеллектуального драйвера IGBT на напряжение 3,3 кВ для 3-уровневых инверторов тяговых электроприводов поездов высокоскоростной железнодорожной магистрали Москва - Санкт-Петербург». Проект выполнялся с апреля по октябрь, и в нём были задействованы кроме меня, как руководителя, студенты 4 курса бакалавриата и 1 курса магистратуры.

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

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

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

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

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

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

Как мы создавали свой драйвер

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

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

Что особенного в этом драйвере?

Чтобы было понятнее транзистор, которым будет совершаться управление имеет следующие параметры: номинальное напряжение 1700 В; номинальный ток 2400А; пиковый ток 4800В. Не сложно представить, какие разрушительные последствия могут быть, если случится авария на оборудовании, оперирующей такой мощностью.

 Силовой транзистор
Силовой транзистор

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

а) Сигнал с системы управления верхнего уровня; б) обратная связь при нормальном режиме работы; в-д) обратная связь при обнаружении аварии.
а) Сигнал с системы управления верхнего уровня; б) обратная связь при нормальном режиме работы; в-д) обратная связь при обнаружении аварии.

*В рамках данной статьи мы не будем подробно описывать все алгоритмы управления драйвера, а рассмотрим лишь один из интересных моментов возникших при их реализации. По всем алгоритмам мы уже подготовили целых две статьи в научные журналы. Одна уже вышла: «Development and Implementation of Algorithms for and Intelligent IGBT Gate Driver Using a Low-Cost Microcontroller». Вторая, в которой мы рассказали о модификации алгоритмов управления выйдет в начале 2025 в российском журнале «Вестник МЭИ».

Особенности работы алгоритмов реализации обратной связи драйвера на выбранном микроконтроллере

Если посмотреть на временные диаграммы работы драйвера на втором рисунке выше и прочитать статью по алгоритмам управления, на которую дана ссылка, то становится ясно, что при разработке ПО пришлось столкнуться с проблемой очень малых временных интервалов реакции драйвера на подачу управляющего воздействия и на выставление сигнала обратной связи. Речь идёт про сотни наносекунд. Тактовая частота процессора, который использовался в разработке – 100 МГц. Один такт – 10 нс. То есть на принятие решения, какой-то небольшой расчёт логики и реализацию нужного сигнала с применением периферии микроконтроллера у нас было 20-25 тактов.

Когда разрабатываешь на микроконтроллерах подобного рода системы управления электроприводов или любого электротехнического оборудования, частота принятия решений там чаще всего связана с частотой широтно-импульсной модуляции и обычно это 10-40 кГц. Для работы на таких частотах тактовой частоты микроконтроллера в 100 МГц хватает если не с запасом, то уверенно. Но здесь мы на первых решениях и версиях ПО столкнулись с проблемой таймингов. Одной из главных проблем было длительное время вызова прерываний, которые были задействованы в реализации выбранных алгоритмов. Всё дело в том, что задание сигнала обратной связи, управление периферией сначала решили реализовать с задействованием модуля ШИМ и его прерывания, триггером для которого был фронт управляющего сигнала, приходящего на драйвер от верхнего уровня. И вот реализовывая диаграмму (б) на втором рисунке, мы увидели, что сам сигнал обратной связи отлично формируется, его длительность ровно какая надо – 700нс. Но вот пауза между приходом фронта управляющего сигнала и формированием этой обратной связи никакие не 250нс, а целых 600нс. Полученные осциллограммы при проверке работы алгоритмы на рисунке ниже. Жёлтым показан управляющий сигнал, синим – сигнал обратной связи. Курсоры установлены как раз для показа задержки обратной связи и видно, что она сильно больше необходимой.

Импульс обратной связи драйвера по фронту сигнала управления
Импульс обратной связи драйвера по фронту сигнала управления

Так откуда лишние 350нс? Тут мы начали измерять время на переход программы из фонового цикла работы в функцию прерывания, где реализована основная логика работы. И увидели, что это время составляет как раз те самые 300-400нс. Опытные инженеры-программисты скажут, что "это же база" и очевидно и стыдно было на такое попасться, но, когда ты оперируешь временами принятия решения 1-0,1мс, то 300нс – это 0,03-0,3%, и ты просто не обращаешь на это внимания, считая, что переход в функцию прерывания почти мгновенен. Редко когда приходится настолько считать такты процессора, чтоб экономить на этих. А в нашем случае это время было не просто сопоставимо с реализуемым таймингом, но было даже больше.**

**А ещё надо помнить, что работу выполнял студент (хоть и под контролем руководителя), для которого это был первый опыт реализации такого рода алгоритмов управления.

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

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

Сигнал обратной связи по нарастающему и спадающему фронтам сигнала управления при нормальной работе драйвера: красный – сигнал обратной связи, синий – сигнал управления
Сигнал обратной связи по нарастающему и спадающему фронтам сигнала управления при нормальной работе драйвера: красный – сигнал обратной связи, синий – сигнал управления

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

Как драйвер испытывался?

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

***Здесь мы тоже не будем давать полные схемы и алгоритмы работы испытательного стенда, а расскажем лишь об одном из этапов проверки драйвера. Разработке и описанию стенда так же посвящена полноценная научная статья, с которой можно ознакомиться по её названию и ссылке: «Development of an IGBT Driver Test Bench».

Решение простое – взять дешёвый транзистор малого тока, но такой же класс напряжения или больше, а параметры затвора имитировать с помощью RC цепочки (R5, R6, C1) - рисунок ниже.

Функциональная схема испытательного стенда IGBT-драйверов
Функциональная схема испытательного стенда IGBT-драйверов

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

А одна из главных функций этого стенда – это реализация перенапряжения для проверки защиты Active-clamping драйвера. Когда из-за больших токов в индуктивной нагрузке образуется перенапряжение на коллекторе силового транзистора в момент закрытия. Здесь это реализуется с помощью индуктивности LActive Clamping реле K2 и резистора R2.

Данная схема была проверена в разных средах моделирования. Замыкается реле K2, включается транзистора – ток течёт через дроссель, накапливая энергию, потом транзистор выключается и ток с дросселя замыкается через резистора R2, на нём образуется перенапряжение и должна сработать защита Active Clamping на драйвере.

Модель схемы проверки защиты Active-clamping
Модель схемы проверки защиты Active-clamping
Напряжение на коллекторе
Напряжение на коллекторе

Момент закрытия транзистора происходит на 10мкс.

Напряжение на затворе транзистора
Напряжение на затворе транзистора

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

Процесс тестирования
Процесс тестирования

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

Узел измерения напряжения на коллекторе
Узел измерения напряжения на коллекторе

На первой плате изначально сопротивление верхнего плеча делителя составляло 3 400 кОм из 17 резисторов и нижнего плеча – измерительного резистора на 100 кОм. В такой конфигурации сигнал до АЦП доходил с задержкой на примерно 5 мкс, при этом, если смотреть щупом осциллографа напряжение на измерительном резисторе, сигнал доходил с задержкой на ещё 10 мкс. Такие задержки возникали из-за паразитных ёмкостей на плате драйвера и щупа осциллографа. Это не давало возможности реализовать защиту от включения транзистора на глухое замыкание, ведь такая защита должна отработать в течении 7 мкс.

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

Осциллограмма измеряемого сигнала
Осциллограмма измеряемого сигнала

Но бороться с паразитной ёмкостью элементов достаточно трудно, а вот уменьшить сопротивление можно, что даст эффект такой же, как и уменьшение ёмкости. Так, в целях уменьшения задержек в измерении напряжения на коллекторе, сопротивления были уменьшены с 3400 до 663 кОм и со 100 до 20 кОм с учётом максимальной продолжительной рассеиваемой мощностью на них, что позволило измерять и анализировать и выдавать сигнал на закрытие транзистора за, примерно, 6 мкс

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

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

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

Савкин Дмитрий Игоревич

 кафедра Автоматизированного электропривода Института электротехники и электрификации НИУ "МЭИ"

Комментарии (13)


  1. R2IN
    20.12.2024 09:50

    "номинальное напряжение 1700 В; номинальный ток 2400А; пиковый ток 4800В "

    Все-таки пиковый ток - тоже в амерах, а не в вольтах :) Поправьте.


    1. savkindmi
      20.12.2024 09:50

      Да, досадная опечатка( Спасибо за внимательность! :)


  1. Ivanii
    20.12.2024 09:50

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

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

    И как по мне то защита должна быть хардварной, без АЦП и МК


  1. nixtonixto
    20.12.2024 09:50

    Тот самый случай, когда нужно использовать ПЛИС. Даже самая дешёвая на таких наносекундах будет работать стабильней, чем ARM (судя по "100 МГц"), особенно после того, как контроллеру драйвера допишут всю остальную программу управления и по программистской привычке добавят программных костылей.


    1. savkindmi
      20.12.2024 09:50

      Да, ПЛИС здесь с точки хрения быстродействия - идеальное решение. Но задача была сделать на моторконтрол микроконтроллере. Потому что нужна была ещë периферия, которая на МК есть и нам понятна. В итоге по таймингам воезли даже с учетом всех дополнительных расчетов. Но было трудно, да. :)


  1. IvanBodhidharma
    20.12.2024 09:50

    По тонкому льду вы ходите со своим ЛГБТ драйвером. Кстати, неплохо бы при первом использовании расшифровывать аббревиатуры, не являющиеся общеупотребительными.


    1. Barma2012
      20.12.2024 09:50

      Вот уж воистину, верна поговорка "У кого чего болит...". Прям показательный случай ))

      "У вас чешется Гондурас? Ну так не чешите его" ))))


      1. IvanBodhidharma
        20.12.2024 09:50

        Это была шутка юмора.


    1. savkindmi
      20.12.2024 09:50

      Надеюсь это какой-то метаироничный комментарий... :)


      1. IvanBodhidharma
        20.12.2024 09:50

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

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


  1. checkpoint
    20.12.2024 09:50

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

    Раз уж сделали на МК, позаботьтесь о фильтрации питания МК, об экранировании от ЭМИ, и о гальванической (оптронной) развязке управляющих сигналов.


    1. savkindmi
      20.12.2024 09:50

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

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


      1. checkpoint
        20.12.2024 09:50

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

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

        Я имел в виду развязать оптронами сигналы от МК к транзисторам, чтобы по ним обратно в МК ничего не прилетало.