ОПЫТ ИСПОЛЬЗОВАНИЯ СРЕДСТВ МОДЕЛЬНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ И АВТОМАТИЧЕСКОГО ГЕНЕРИРОВАНИЯ КОДА В MATLAB ПРИ РАЗРАБОТКЕ ЭЛЕКТРОПРИВОДОВ

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

Почему это важно?

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

И при всём этом очень часто в высшем образовании на электромеханических и электротехнических специальностях микропроцессорная техника - это до сих пор КР580, Intel8086 и Intel8051. В более прогрессивных случаях бывают восьмибитные AVR или восьмибитные же PIC. Естественно, что в 2021 году программировать такие чудеса антикварной техники надо с помощью архаичных средств разработки на языке машинных кодов и ассемблерах с минимальным набором команд. Соглашусь, конечно, что с применением ассемблера удобно изучать архитектуру, устройство и принципы функционирования микроконтроллеров. Но разработка более содержательного программного обеспечения на ассемблере представляет собой путь страданий, когда, например, чтобы сложить два числа, совсем недостаточно просто написать c:= a + b. Для этого надо перекладывать байты из одного регистра в другой и на всякий случай проверять бит переноса, чтобы вместо сложения не получилось вычитание. И не забываем отслеживать содержимое регистров! А как красивы и изящны на ассемблере программы для умножения и деления! Как редкая птица долетит до середины Днепра, так и редкий студент допрограммирует на ассемблере до середины программу для управления, скажем, электрическим двигателем постоянного тока, которая, кстати, алгоритмически совсем простенькая. Почему так? Ответы весьма печальны и я оставлю их за рамками статьи.

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

Допустим, освоили мы устройство и принцип работы микроконтроллера. А дальше? Взять, например, разработку системы управления электропривода. Что изначально знает разработчик, но не простой, а инженер-электромеханик и в прошлом студент? Естественно, если он хороший инженер-электромеханик и хороший бывший студент. Физические процессы электромеханического преобразования энергии в электрическом двигателе и его математическое описание – знает. Теорию управления электроприводами – знает. Теорию автоматического управления в той её части, которая касается регулирования координат электропривода – знает. Принципы управления силовой преобразовательной техникой – знает. Численные методы для решения системы дифференциальных уравнений, а это, между прочим, и есть ПИД-регулятор – тоже знает. А вот теорию передачи информации и её практические воплощения в виде цифровых интерфейсов вполне может и не знать. Да-да, он же ещё знает восьмибитный микроконтроллер PIC или аналоги, а также его ассемблер. Содержание и методология разработки любой технической системы можно аналогичным образом разложить на компоненты.

Да ничего он так просто не разработает. Тут ситуация такая: понимать – понимаю, знать – знаю, а сделать ничего не могу. И дело не только в архаичных средствах разработки. Справится ли перечисленный выше микропроцессорный антиквариат с такими задачами по своей производительности? Это тоже открытый вопрос. Что если использовать более прогрессивную элементную базу, например, STM32 или TMS320? Увы, их описания (даташиты и юзер-мануалы), занимающие многие сотни и даже тысячи страниц, могут вызвать уныние. Вроде бы по аналогии с PIC, Intel8051 и КР580 всё понятно, но как это всё применить? С чего начать? Аналогично и с языком программирования C, даже если Pascal был изучен в общем курсе информатики. Вроде бы всё просто: фигурные скобочки вместо begin и end, всё те же подпрограммы, функции, массивы, циклы, ветвления, переменные. Всё это интуитивно понятно. Но есть же ещё и аппаратно-ориентированные подпрограммы и функции, специфичные для целевого микроконтроллера. Они тоже интуитивно понятны по аналогии даже с ассемблером для КР580, но написать что-то с их использованием с ходу вряд ли получится. Поэтому всё это надо осваивать, начиная с моргания светодиодами и составления «наивных» программ. Вместо разработки электропривода придётся изучать микроконтроллер.

Можно, конечно, обратиться к профессиональному «чистокровному» программисту. Увы, и тут надежды мало. Часто бывает, что программист это не профессия, это образ мышления с ветвлениями, циклами и библиотеками вместо физики и математики. Он почти наверняка не знает вашу профессиональную область во всех её тонкостях и изысках либо представляет её по-своему, весьма своеобразно. Тут профессиональный барьер возникает уже на уровне технического задания, понимания «смысла цифр» и анализа полученных результатов. Это как разница между врачом и биологом. Если разработать программное обеспечение не «как надо», а «как я это понимаю», то электропривод будет иметь весьма посредственные характеристики.

И что же остаётся? Как это ни печально, всё начинаем с моргания светодиодами. Потом генерируем ШИМ… Сколько светлых голов на этом сгинуло (в профессиональном отношении).

Теорию – в действие.

Минуточку. Я вообще инженер-электромеханик или кто? Да я вам таких электроприводов напроектирую. Кто лучше меня знает, как они работают? Например, сколько раз в секунду надо выполнять координатные преобразования при векторном управлении электрическим двигателем переменного тока? Как это связано со скоростью его вращения? На этот вопрос ни один «чистокровный» программист не ответит. Вот только программировать подучусь. И от КР580 перейду на STM32. Причём учиться и переходить надо быстрее, пока не надоело. И так хочется поскорее увидеть результат, а не вот это вот всё. Ведь это вдохновляет!

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

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

Если с заводом всё и так понятно, то применение средств модельно-ориентированного программирования требует детального пояснения.

При разработке электроприводов с микропроцессорным управлением была использована библиотека модельно-ориентированного программирования Waijung Blockset для микроконтроллеров семейства STM32, которая включается в состав системы компьютерной математики и моделирования MATLAB/Simulink.

Следующие преимущества средств модельно-ориентированного программирования по сравнению с традиционными средствами разработки программного обеспечения позволили успешно их применить при разработке электроприводов с учётом перечисленных выше обстоятельств:

1. Общая компоновка программного обеспечения в графической форме в виде исполняемой модели. Именно правильная компоновка позволила рационально распределить вычислительные ресурсы микроконтроллера и использовать встроенные в него аппаратные модули. Распределение вычислительного ресурса микроконтроллера заключается в назначении интервалов повторения, приоритетов выполнения и условий вызова отдельных подпрограмм из состава программного обеспечения.
2. Замена аппаратно-ориентированных подпрограмм эквивалентными модельными блоками позволила решить проблему перехода к использованию микроконтроллера STM32. Это же обстоятельство способствует применению встроенных аппаратных модулей микроконтроллера безотносительно конкретного его типа.
3. Задание параметров модельных блоков и, следовательно, аппаратно-ориентированных подпрограмм с помощью меню, аналогичных меню блоков Simulink. Назначение большинства параметров блоков либо понятно по аналогии с другими микроконтроллерами, либо по пояснениям в меню. При этом изучение даташитов и юзер-мануалов для целевого микроконтроллера имеет лишь справочное, вспомогательное значение.
4. Возможность включения в состав исполняемой модели программного обеспечения, изначально составленного на языке C, в качестве дополнения стандартных модельных блоков или для их замены.

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

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

1. Управление силовым преобразователем для формирования электромагнитных и электромеханических процессов в электрическом двигателе;
2. Регулирование координат в замкнутых контурах: электромагнитного момента, скорости вращения и положения;
3. Информационное взаимодействие с периферийными устройствами;
4. Контроль исправности и защиты при превышении уставок.

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

Рис.1. Функциональные схемы электропривода.

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

1. Компоновка программного обеспечения;
2. Дополнение, частичная или полная замена модельных блоков пользовательским программным обеспечением, разработанным на языке C.

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

На рис.2 показана структура программного обеспечения электропривода на базе трёх типов электрических двигателей.

Рис.2. Структура программного обеспечения системы управления электропривода.

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

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

Рис.3. Элементы для компоновки программного обеспечения по задачам, их приоритетам и интервалам повторения.

Внутри управляемых подсистем, показанных на рис.3, находятся модельные схемы, составленные из блоков Waijung Blockset, Simulink и Basic Custom Code, с помощью которых в состав исполняемой модели включаются пользовательские подпрограммы. Типовые примеры таких схем показаны на рис.4.

                        а                                                 б                                          в   

Рис.4. Примеры модельных схем программного обеспечения для управления электроприводом: а) обработчик инкрементального энкодера;
б) обработчик аналоговых сигналов;
в) обработчик логических сигналов.

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

• Отсутствие в меню модельных блоков доступа к некоторым параметрам конфигурации модулей, встроенных в микроконтроллер;
• Громоздкость модельных схем в некоторых случаях и возникающие при этом затруднения для их наращивания в процессе разработки программного обеспечения;
• Отличие величин шага интегрирования и шага дифференцирования модельных блоков Simulink, имеющих динамические передаточные функции, от интервала повторения при выполнении сгенерированных из них подпрограмм;
• Несогласованное выполнение подпрограмм, сгенерированных из нескольких функционально завершённых модельных схем, в составе единого программного обеспечения особенно при различных интервалах их повторения;
• Неосуществимость доступа к параметрам конфигурации встроенных модулей микроконтроллера в процессе выполнения программного обеспечения.

Перечисленные особенности связаны с тем, что задачи, которые требуется решить при разработке программного обеспечения для управления технической системой, гораздо разнообразнее функциональности стандартных модельных блоков. Эти особенности удалость учесть при замене модельных схем, составленных из стандартных модельных блоков, пользовательскими подпрограммами, изначально составленными на языке C и включаемыми в состав исполняемой модели программного обеспечения с помощью модельных блоков вида Basic Custom Code. Это относится к математическому программному обеспечению систем управления, в то время как в качестве программных обработчиков периферии по-прежнему используются модельные блоки Waijung Blockset. Примеры такого использования стандартных модельных блоков и блоков, основанных на пользовательском программном обеспечении, показаны на рис.4. Кроме того, автоматически сгенерированное программное обеспечение может быть несколько доработано для большего соответствия решаемым задачам. Соотношение различных средств разработки на разных этапах проектирования программного обеспечения электропривода показано на рис.5.

Рис.5. Этапы использования средств модельно-ориентированного программирования.

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

Аппаратно-ориентированные подпрограммы же, напротив, специфичны для конкретной элементной базы, хотя в целом обладают подобием на уровне параметров. Как раз тут модельно-ориентированное программирование чрезвычайно полезно и повышает продуктивность разработки. Выше я писал, что в силу образования и области деятельности не знал, что такое цифровые последовательные интерфейсы UART (Universal Asynchronous Receiver/Transmitter), CAN (Controller Area Network), I2C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface) и как они работают. Если последовательный интерфейс, то данные передаются последовательно. Вот, собственно, и всё, что многие специалисты по электромеханике, электротехнике, электроэнергетике, теплоэнергетике могут знать по этому вопросу, если ранее не имели опыта их применения. Всё же обмен данными - это вспомогательная задача. Тем не менее, её решение должно быть очень тщательно «вплетено» в общее программное обеспечение с учётом распределения вычислительного ресурса микроконтроллера и своевременности обновления информации. Поэтому правильно «вплести» сможет именно специалист по теме проекта.

Средства модельно-ориентированного программирования из состава MATLAB при разработке информационных подсистем электроприводов позволили решить сложную без предварительного изучения даташитов и юзер-мануалов задачу – конфигурирование аппаратных модулей цифровых интерфейсов, встроенных в микроконтроллер STM32, и доступ к ним в процессе функционирования электропривода. Примеры использования модельных блоков интерфейса UART показаны на рис.6.

                а                                          б                                                  в   

Рис.6. Модельные схемы для обмена сообщениями по UART:
а) доступ к приёмному буферу;
б) доступ к принятому сообщению;
в) отправка исходящего сообщения.

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

Что же получилось?

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

1. Сервопривод на базе электрических двигателей разных типов – бесколлекторного двигателя постоянного тока, двигателя постоянного тока с возбуждением от постоянных магнитов, с бесколлекторным двигателем переменного тока;
2. Шаговый сервопривод с векторным управлением;
3. Двухдвигательный электропривод постоянного тока по принципу электромеханического распора;
4. Двухдвигательный электропривод по принципу синхронно-следящей системы;
5. Асинхронный электропривод с частотным (скалярным) управлением.

Блок-схема программного обеспечения сервопривода, имеющего наибольшую степень готовности, показанная на рис.2, даёт представление о его функциональности. По характеристикам и функциональности он примерно аналогичен электроприводу Epos2 от Maxon Motors. Его электронный блок управления имеет завершённую конструктивную форму. Аналогичную функциональность имеет шаговый электропривод с векторным управлением. Его аналогом для сравнения по характеристикам и функциональности является сервопривод СПШ. Следующие по порядку два электропривода прямых аналогов не имеют из-за своей узкой направленности по применению и форме конструкции. При разработке асинхронного электропривода с частотным управлением отработаны принципы формирования трёхфазного напряжения с раздельным регулированием его величины и частоты. Подходы к разработке, методы управления и способы их осуществления, включая распределение вычислительных ресурсов и аппаратных модулей микроконтроллера, могут быть применены при разработке асинхронного электропривода с векторным управлением.

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

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

Резюме.

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

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