Как мы проектировали свой отечественный драйвер IGBT

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

В этом году я со своими студентами провел такое проектно-научное исследование в рамках гранта НИУ «МЭИ» на реализацию программы научных исследований «Приоритет 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) — рисунок ниже.

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

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

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

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

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

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

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

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

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

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

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