Способы отладки встраиваемых микропроцессорных систем в преобразовательной технике

В статье рассмотрены типовые вопросы, с которыми сталкивается инженер-программист при создании микропроцессорных систем, управляющих полупроводниковым оборудованием. Описан опыт по созданию специализированного ПО для отладки таких систем в ООО «НПФ Вектор».  Стиль изложения – вольный (размышления на тему…)

Рассмотрим, с какими проблемами сталкивается некий среднестатистический инженер-программист, если ему поставить требование разработать ПО микроконтроллера для, скажем, для преобразователя сервопривода. Т.е. написать низкоуровневую «прошивку» на языке Си, отладить её и выпустить готовый продукт. Задача – позиционировать вал электродвигателя по инкрементальному датчику положения от задания системы верхнего уровня. Как инженер-программист будет решать эту задачу? Давайте дадим ему в таком виртуальном эксперименте всё готовое: его коллега спроектировал аппаратную часть устройства – шестиключевой инвертор напряжения, заложил качественные датчики токов и напряжения, интерфейс с энкодером, поставил производительный микроконтроллер. Путь даже аппаратно устройство не содержит ошибок (а это скорее исключение, а не правило для новых устройств), и пусть инженер уже имеет базовые знания о том, как синтезировать в цифровом виде ПИ-регуляторы токов, модуль векторной ШИМ инвертора, хорошо освоил язык программирования Си и имеет опыт разработки под какой-то микроконтроллер – его не пугает вопрос обслуживания прерываний, общение с периферийными модулями и работа с АЦП. Пусть для начала он написал (или скачал готовую) тестовую программу управления двигателем в замкнутой по току структуре управления – создание вращающегося вектора тока заданной амплитуды. Инженер запустил устройство, вал двигателя провернулся несколько оборотов и встал – на устройстве загорелся светодиод аппаратной аварии ключей инвертора, и ПО отключилось по защите. Как узнать, что пошло не так? Можно взять осциллограф, подключить к выходам инвертора, к датчикам тока и посмотреть осциллограмму этого момента. Что там можно увидеть? Микроконтроллер по ошибке выдал в какой-то момент слишком высокое напряжение – неправильно открыл ключи, ток фазы двигателя «улетел» вверх и достал до защиты. Что делать дальше, как найти, в каком месте программы сформировалось неверное напряжение и почему?

Lg-Sauris-SAU510-USB-Plus

Один из удачных и недорогих JTAG отладчиков для TI фирмы Sauris — SAU510

Теперь мы подошли к главному вопросу данной статьи – что инженер-программист должен делать теперь? В данном случае совершенно не подходит традиционный эффективный метод отладки ПО, где программист шаг за шагом в режиме отладки проходит по строкам программы и наблюдает переменные в окне отладчика, ожидая увидеть неверное значение, а потом «раскрутить» алгоритм назад, выясняя откуда оно взялось. Потому что если остановить микроконтроллер в то время, как он управляет силовым оборудованием, в лучшем случае всё просто отключится по аппаратной защите, и программист не сможет «прошагать» до того места, где кроется проблема, а в худшем – сразу после остановки микроконтроллера силовое оборудование сгорит (возможно со спец. эффектами в виде взрыва, дыма или выбивания автомата защиты – зависит от размеров устройства и способов аппаратной защиты). Что же делать, как найти проблему в программном коде? Можно просматривать его, строчку за строчкой, и, представляя мысленно его работу, пытаться найти ошибку. Это очень долгий метод и только в некоторых случаях он оказывается успешен. Можно попробовать поменять в программе какое-то подозрительное место и запустить еще раз. Но при большом объеме программного кода этим также можно безрезультатно заниматься не одну неделю. Какие еще есть варианты исправить проблему? Производители микроконтроллеров и средств отладки идут в этом случае навстречу: например, у микроконтроллеров серии C2000 фирмы Texas Instruments есть так называемый режим отладки «реального времени». Программист может через отладочный интерфейс JTAG получить доступ на чтение/запись ко всем переменным программы без остановки микроконтроллера. Это свойство штатно поддерживается их средой разработки – Code Composer Studio (CCS). Программист активирует режим «реального времени», запускает выполнение программы – и всё. Он может добавить в поле просмотра значений переменных любую переменную программы, наблюдать её, изменять, а самое главное он может добавить её «на график» – видеть изменение переменной во времени! При этом микроконтроллер остается в работе, его программа работает штатно и без остановок, что совершенно безопасно для силового оборудования. Это может значительно упростить поиск проблемы: программист может вывести на график, скажем, выход АЦП, выход регулятора тока, выход модуля ШИМ и увидеть, на каком этапе происходит сбой. Например, на графике будет видно, что регулятор тока при нормальном значении обратной связи выдал скачок на выходе – значит проблема именно в этом программном модуле. Можно углубляться в него и выводить на график уже его внутренние переменные, чтобы локализовать место с ошибкой еще точнее.

Проблема в том, что описанный выше метод не работает. Потому что чаще всего в задачах электропривода, да и почти во всех цифровых системах управления, процессы протекают настолько быстро, что интерфейс связи компьютера с микроконтроллером, какой бы он ни был, не успевает передавать в реальном времени все данные, чтобы точно увидеть на графике место возникновения ошибки. Типичная частота работы контура тока для электропривода – 5-20кГц. Т.е. 20 000 раз в секунду программные модули будут формировать новые значения – новые данные с АЦП, новый выход регулятора тока, новый выход модуля ШИМ. А отладочный интерфейс JTAG позволяет вывести данные на график с максимальной частотой 10-20 Гц в самом удачном случае (по крайней мере в штатных средствах среды разработки CCS чаще обновлять данные не получается). На график будет попадать одна из тысячи обработанных микроконтроллером точек. Всё, что увидит программист при возникновении проблемы в приводе – что все графики были в норме, а после возникновения проблемы все разом «прыгнули» в какую-то сторону. И что являлось причиной, а что следствием проблемы уже не определить.

Что делают в таком случае? В таком случае на помощь приходит сам микроконтроллер. Его нужно использовать как средство сбора информации о своей же работе. Программист делает в оперативной памяти микроконтроллера массив из точек, скажем, на 256 значений, и циклически с каждым тактом расчета системы управления заполняет их по кругу данными интересующей переменной, например, значениями выхода регулятора тока. Когда происходит отключение по защите, программа перестаёт заполнять массив – там захлопываются данные, которые выдавал регулятор тока до и в момент аварии. Затем данный массив (уже после возникновения аварии) не спеша «скачивается» на компьютер через интерфейс JTAG и визуализируется в виде графика – получается осциллограмма выхода регулятора тока на момент аварии, снятая самим же микроконтроллером. Среда CCS имеет встроенные средства для отображения массива точек в виде графика, а примеры управления электродвигателями от Texas Instruments уже имеют в своем составе готовые универсальные модули «осцилографирования» внутри микроконтроллера. На своем жаргоне разработчики их называют «даталоггеры» от их английского названия datalogger. Единовременно в них записывается не одна переменная, а несколько, настраивается частота сбора данных, настраиваются адреса переменных программы (откуда производить сбор данных) настраивается момент начала и окончания записи (по каким событиям в микроконтроллере).

ccs3_debug

Пример окна отладки старой доброй Code Composer Studio v3.3 от TI

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

Но есть ситуации, когда и этот метод тоже не работает. И с повышением мощности и защищенности устройств это происходит всё чаще. Как этот метод может подвести, удивится читатель? Например, он неприменим, если устройство стоит в герметичном корпусе на глубине десяти метров под землей. В этом случае произвести подключение к разъему JTAG несколько проблематично – придется очень долго копать. Также может оказаться, что выбранный микроконтроллер, или среда разработки, или JTAG просто не поддерживают режим отладки «реального времени». Или, скажем, в проекте по созданию электротрансмиссии, которым мы занимались в ООО «НПФ Вектор», одна из проблем происходила в герметичном блоке, находящимся в моторном отсеке, и происходила она исключительно на скорости в сто километров в час! Но нужно было понять проблему в работе системы управления и увидеть, что же там происходит с формой тока фазы и почему она имеет странную форму. Как производить отладку ПО в таком случае?

pus

Пульты управления c CANopen производства ООО «НПФ Вектор»

Теперь статья расскажет о развитии инструментария программиста/наладчика в ООО «НПФ Вектор». Создание собственных отладочных инструментов началось с обычной задачи – сделать пульт управления для новой серии преобразователей частоты, с которого можно было бы менять те или иные уставки преобразователя и смотреть на текущие значения. Так как одним из самых надежных и популярных интерфейсов связи микроконтроллеров на то время, да и по сей день является интерфейс CAN, было решено на основе него сделать гибкий протокол связи пульта управления (это было отдельное выносное микроконтроллерное устройство) и контроллера преобразователя частоты. Изучая существующие решения, мы пришли к выводу, что наиболее подходящим для нашей задачи является протокол CANopen. Но так как открытого полноценного драйвера (стека) для нашей серии микроконтроллеров на то время не было, мы решили реализовать его самостоятельно – и сделали это. В сети CANopen может быть до 127 устройств, каждое со своим номером узла. Работает CANopen на основе так называемого словаря объектов – по сути обычного списка переменных, где у каждой переменной есть свой адрес доступа к ней. Для удобства группировки адрес двойной: группа (называется индекс), и входящие в нее элементы (подындексы). Например, адрес задания ПИ-регулятора тока может быть 0x5280.1, где 0x5280 это индекс (регулятор тока), а 1 — подындекс (задание). По этому адресу словаря объектов любое другое устройство в сети CAN может как прочитать значение этой переменной, так и записать новое значение (естественно обращаясь по номеру узла в сети к нужному устройству). Так мы получили возможность доступа пультом управления ко всем вынесенным в словарь объектам – переменным контроллера преобразователя. Однако в стандарте CANopen не предусмотрено масштабирование величин и преобразование переменных микроконтроллера в физические величины. Так как система управления внутри микроконтроллера работает чаще всего в относительных единицах, то для неё ток 20 ампер может быть равен, скажем 0x1273842 в виде четырехбайтовой переменной. Заставлять пользователя конфигурировать преобразователь в таких единицах мы не имели право, а закладывать непосредственно в пульт таблицу пересчета одних значений в другие мы посчитали не слишком гибким решением. Поэтому мы дополнили свой драйвер CANopen некоторым расширением: находящейся в самом контроллере таблицей масштабирующих коэффициентов, которая указывает пульту, как пересчитывать ток, напряжение, мощность и т.п. из внутреннего значения переменной данного контроллера в физические величины. Таким образом у нас получился пульт, на котором можно смотреть и задавать все величины в привычных пользователю единицах измерения – вольтах, амперах, оборотах в минуту и так далее, независимо от того, к какому нашему устройству пульт подключился.

Так как мы постоянно сами этими пультами пользовались для пуско-наладки оборудования, а с мелким дисплеем пульта было работать неудобно,

переходник CAN-USB

переходник CAN-USB

то мы решили написать такой же по функционалу пульт, но в виде компьютерной программы, которая работает через USB-CAN переходник. Так родилась программа UniCON. Сначала она умела тоже самое, что и пульт – смотреть и менять переменные. К тому времени практически все значимые переменные программы микроконтроллера у нас получили свое место в словаре объектов CANopen – все параметры и коэффициенты, что только можно было поменять, были доступны по CANopen.
Не осталось практически ни одной «захардкоженной» уставки. Кроме того, в словарь уже было выведено много переменных с типом доступа «только для чтения» – просто для возможности контроля, чему равна та или иная переменная во время работы оборудования без применения JTAG интерфейса.

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

UniCON, главное окно, страница параметров

UniCON, главное окно, страница параметров

остальные медленные процессы, что укладывались в приемлемую частоту запросов данных по сети CAN в 5-10 раз в секунду. Следующим шагом было добавление работы UniCON с «даталоггером» контроллера – UniCON мог послать команду контроллеру на запись осциллограммы выбранных переменных словаря объектов в массивы внутри контроллера, а после не спеша выкачивал их поэлементно через CANopen. Так мы смогли смотреть в UniCON быстротекущие процессы – форму токов фаз, колебания напряжения, работу регуляторов тока и т.п. При этом для такого осциллографирования нам был доступен весь словарь объектов – а это уже под тысячу переменных!

Правда, на одной осциллограмме можно смотреть только до четырех переменных одновременно,

окно программы Unicon

окно программы Unicon

но ничто не мешало в следующий раз посмотреть другие интересующие переменные. Затем мы добавили синхронизацию записи осциллограммы по событиям: теперь стало возможно выбрать, когда именно контроллер запишет осциллограмму: во время срабатывания защиты, во время смены структуры управления, во время смены задания и т.п. Так мы получили инструмент, уже почти полностью заменяющий аналогичную отладку через JTAG, а в некотором смысле и превосходящий его по удобству: не нужно заниматься с массивами, не нужно задавать адреса – достаточно кликнуть правой кнопкой мыши по переменной и нажать «добавить в осциллограф», не нужно ломать голову над единицами измерения осциллограммы – мы их получали непосредственно в вольтах, амперах и ваттах, не нужно бояться нечаянно нажать кнопку «стоп» в среде разработки или бояться зависания компьютера – с отключенным JTAG мы могли не беспокоиться за внезапную остановку микроконтроллера. Оставалось только одно, что нас держит от полного отказа от JTAG – перепрограммирование микроконтроллера. Найдя ошибку в программе, нам приходилось снимать высокое напряжение, открывать силовой шкаф и подключаться напрямую к микроконтроллеру, чтобы обновить прошивку и затем проверить работу еще раз. Долго ли, коротко ли, но в итоге мы написали свой программатор, работающий через сеть CAN по CANopen посредством UniCON. Теперь стало возможно собрать новую версию прошивки на компьютере, выбрать в UniCON файл, нажать «прошить» – и через минуту можно запускать привод – никакого вскрытия оборудования!

окно программы Unicon

окно программы Unicon

UniCON отправляет новую прошивку по сети поблочно, а собственный загрузчик в контроллере прошивает флеш-память этой новой программой. При этом мы предусмотрели в таком способе прошивки различные защиты от сбоев – надежные контрольные суммы, верификацию прошитого кода, перепосылку блока данных при сбое, и даже заложили возможность шифрования данных (вдруг в сети есть жучок, который хочет подслушать нашу прошивку?). Вот теперь мы стали свободны от JTAG интерфейса полностью. Мы получили возможность изготавливать герметичное силовое оборудование и не бояться, что его придется по десятку раз демонтировать и вскрывать для перепрошивки. Теперь мы используем JTAG только один раз – при первом программировании контроллера. Ну или в совсем редких случаях, если новая прошивка имеет настолько критический изъян, что контроллер после этого не запускается совсем – на жаргоне это называется «получить кирпич».

Казалось бы, что может быть еще нужно? UniCON позволяет смотреть осциллограммы всех переменных в контроллере, менять все уставки, перепрограммировать его. Но есть еще ряд сервисных функций, без которых работа по отладке была бы не так удобна. Например, мы создали дополнительную программу для создания словарей объектов CANopen. Изначально для того, чтобы добавить новую переменную языка Си (на котором написано ПО микроконтроллера) в словарь объектов CANopen, нужно было вручную провести ряд нетривиальных действий – задать адрес в словаре, задать адрес в памяти контроллера, задать формат, масштаб, русскоязычный текст (как переменная будет называться в UniCON и на пульте), размерность данных, размещение в энергонезависимой памяти контроллера для сохранения значения переменной после перезагрузки. Чтобы не запутаться со всем этим, мы написали редактор словарей CANopen, который позволяет визуально и интуитивно понятно скомпоновать словарь объектов, а затем сгенерировать его Си-код для вставки в ПО микроконтроллера – эта программа получила название COODEdit. Теперь не нужно иметь какие-то знания о внутреннем устройстве нашего драйвера CANopen – достаточно задать в редакторе COODEdit имя переменной языка Си в программе контроллера, задать понятное русскоязычное название, а COODEdit возьмет на себя всё остальное. Сразу после прошивки программы с новым словарем можно менять, наблюдать и осциллографировать эту переменную по CAN! Помимо этого, сам UniCON с годами использования оброс различными и на первый взгляд мелкими, но значительно облегчающими работу функциями – экспорт графиков и осциллограмм в различные форматы, поддержка различных переходников USB-CAN, сохранение и загрузка всех параметров контроллера (объектов словаря CANopen) в файл на компьютер и выгрузка обратно, ведение лога CAN сети в файл, групповые действия с узлами в сети – когда нужно, например, прошить одним и тем же ПО 16 контроллеров в сети CAN или одинаково сконфигурировать их, загрузка данных черного ящика из контроллера на компьютер (банк аварий), а также многими другими функциями, которые просто трудно перечислить.

Устали читать? Но и это еще не все. Есть еще одна программа, без которой сложно производить отладку сложных многопроцессорных систем управления. Как было сказано, UniCON позволяет делать многое, но он позволяет делать это всё лишь с одним устройством в сети в единый момент времени. Но если вы строите мультипроцессорную систему, то часто бывает нужно видеть, как взаимодействуют несколько устройств друг с другом. Например, это может быть многокоординатный станок, многоколесное транспортное средство с двигателем на каждое колесо, мощный многосекционный электродвигатель и т.п. Когда работает такая мультипроцессорная система, помимо недочетов работы в каждом конкретном устройстве, бывают моменты, когда нужно увязать между собой работу нескольких устройств. Например, при отладке работы противобуксовочной системы гибридного транспортного средства в одном из наших проектов необходимо было наблюдать тяговые моменты, скорости вращения и задания на момент для всех колес машины на одном графике. Только так, видя, что конкретно и на каком устройстве происходит в единый момент времени, можно было понять, что происходит в системе в целом. Для этого мы сначала хотели использовать какое-либо готовое ПО для отображения графиков, типа ПО PowerGraph. Но пришли к выводу, что оно не подходит – во-первых, число переменных, единовременно отображаемых на графике в ПО такого типа ограничено на уровне 30-60 величин. А в наших проектах бывает более пятисот величин, гуляющих в сети CAN, которые надо все видеть одновременно. Отобразить такое число величин на одном графике так, чтобы всё не слилось в одну кучу можно, но только за счет того, что одинаковые величины будут расположены на одних и тех же осях времени и накладываться друг на друга. Например, при движении транспортного средства все колеса ведут себя приблизительно одинаково – имеют одну частоту вращения, момент, токи, мощности и т.п. Логично расположить эти данные на одном графике – график будет идти одной толстой линией, которая будет состоять из, скажем, восьми тонких линий мощностей колес. Если какое-то устройство ведет себя не так, как все – отличие его графика сразу бросится в глаза. К сожалению, мы не нашли ни одного стандартного ПО для отображения графиков, которое позволило бы так отобразить данные и сохранить такой способ в виде постоянного «профиля».

ScopeOpenGL

ScopeOpenGL

Поэтому нам пришлось написать свое ПО – назвали мы его ScopeOpenGL. Это программа исключительно для отображения графиков, причем для очень, очень большого числа графиков. По листу с графиками можно перемещаться как по чертежу какой-нибудь CAD-системы, при помощи колеса мыши увеличивая нужное место, и отдаляясь если нужно увидеть картину в целом. Программа даже не пытается отобразить шкалу с единицами измерений и ценой деления клетки каждой переменной – для такого количества разных графиков это невозможно. Вместо этого она имеет удобный курсор для отображения текущего значения величин: в то место, куда пользователь нажимает мышкой, рисуется некоторое вертикальное «окно» курсора – значения всех переменных, графики которых попали в это окно, будут отображены на панели значений. Графики можно включать и выключать одним кликом – если вы потеряли, где же у вас, например, температура преобразователя заряда аккумулятора, то можно найти эту переменную в списке и «помигать» ей – она сразу станет заметной. ScopeOpenGL можно сконфигурировать для любого типа и количества входных данных и сделать постоянный профиль, настроив масштаб, цвет, расположение и смещение каждого графика. Программа особенно удобна для визуализации работы однотипных устройств, телеметрия которых в норме должна совпадать, сливаясь в один график, а при специфических режимах должна расходиться, что сразу становится заметно и позволяет рассмотреть подробно эти места. Программа позволяет визуализировать данные как в реальном времени, подключаясь к UniCON по TCP/IP и забирая у него данные траффика сети CAN, так и просматривать уже записанные «логи» данных.

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

Выводы

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

ООО «НПФ Вектор» разработало целый комплекс отладочного и конфигурационного ПО, работающего в тесной взаимосвязи:

  • Расширенный драйвер микроконтроллера CANopen для интерфейса CAN, дополненный масштабирующими коэффициентами для преобразования внутренних величин контроллера в понятные пользователю физические величины, дополненный загрузчиком для перепрограммирования по сети и дополненный модулем осциллографирования переменных внутри контроллера;
  • Программу для компьютера UniCON, работающую с указанным драйвером CANopen и позволяющую параметрировать устройства, перепрограммировать и смотреть осциллограммы как в «медленном» режиме реального времени, так и в режиме записи осциллограммы в контроллере и последующей загрузкой.
  • Программу для компьютера COODEdit, которая является редактором словаря объектов для драйвера CANopen микроконтроллера.
  • Программу ScopeOpenGL, которая визуализирует на одном графике сотни переменных, передающихся в сети обмена, и которая позволяет следить за работой распределенной микроконтроллерной системы управления в целом.

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

Конечно, у каждой серьезной фирмы-разработчика существует свой собственный инструментарий для подобной отладки. Для мощных микроконроллеров широко используется Ethernet, предоставляя доступ к устройству по TCP/IP. Если микроконтроллер еще мощнее и содержит внешнюю флеш-память, то можно использовать операционную систему, скажем на базе Linux, и тогда возможности по отладке выходят принципиально на новый уровень. Некоторые для отладки используют дисплей, подключенный непосредственно к микроконтроллеру. Классикой также является метод «printf в UART». Даже ходят шутки с некоторой долей правды о том, что некоторые разработчики подключают к микроконтроллеру быстродействующий ЦАП, чтобы на него вывести значение интересующей внутренней переменной, чтобы затем подключить аналоговый осциллограф, чтобы затем… ну вы поняли…

Наше решение предназначено для относительно специализированных микроконтроллеров, чьи возможности настолько же опережают возможности «arduino», насколько отстают от микроконтроллеров, на которые можно установить полноценную операционную систему с TCP/IP стеком.

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

 

PS

По вопросам отладки систем управления на семинаре МЭИ 2014 был сделан доклад, презентация которого доступна по ссылке.