Ошибся, извиняюсь, нормально там процесс показан. Только если бы там был двигатель с нестандартной ЭДС то расхождение было бы еще больше чем в видео семинара показано. И отладки непосредственно на схеме я не увидел, смотрят готовые графики записи.
Это костыли и палки от продавцов в России, у которых нет доступа к ядру системы MatLab. Но даже при условии доступа к исходным кодам, продраться через три продукта до ядра, та еще задача. А если вспомнить что для получение кода таргета из Simulink нужно использовать 3 (ТРИ!!!) продукта:
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
К тому же модель электродвигателя в этом проекте из Simulink не подходит. В реальности она работает по другому см. рисунок 1
Потом нельзя отобразить на схеме в процессе отладки кода в контролере его работу. Последний рисунок из модели которая подключена к контроллеру и отображает его работу на схеме.
Ну и сам код ПО из автоматического кодогенератора, тоже не без странностей. Например, для интегратора matlab генерирует такой код:
Отличное решение, -0.01 это временной шаг интегрирования.
Как только запустил с другим шагом система не работает. Опять генерит код, опять заливаем.
А ведь определение оптимального такта работы управляющей программы это практическая и реальная задача, при проектировании любой системы управления.
Так что восторг участников когда у них реально заработала понятен
Да что угодно поддерживает, если среда открыта и настраиваема, то обеспечить поддержку любого МК не является проблемой.
Объект управления в реальном времени в FPGA это возможно только для ограниченного набора моделей. Например уложить в логику FPGA модель какой нибудь теплообменника с «честной» теплофизикой вряд ли возможно.
С моей точки зрения, попытки загнать работу модели в «реальное время» на стадии отладки и проектирования ПО, не всегда оправданы. На стадии проектирования, достаточно обеспечить синхронизацию работы управляющей программы по тактам с модельным временем. И добиться того, что при заданных входных воздействиях система управляет объектом, так как требует проект. Даже если моделирование происходит медленнее или быстрее реального времени. После этого достаточно убедится, что цикл вычислений укладывается в временной такт работы в реальном времени на контроллере.
Хотя возможно для систем, где простые алгоритмы и главная проблема обеспечить передачу данных от сенсоров в контроллер и воздействия на исполнительные механизмы тестирование реальном времени действительно необходимы.
Кстати пример dSPACE как раз и показывает, что для того что бы код из Simulink загнать на контроллер и посмотреть как же он всетаки работает нужно еще отдельную компанию подключать, которая смоделирует таргет. (dSPACE например)
«VEOS is part of the MathWorks Connections Program. dSPACE works closely together with MathWorks to make sure that C code generated with the Simulink® Coder™ can be integrated and simulated with VEOS.»
А если вспомнить что для получение кода таргета и Simulink нужно использовать 3 (ТРИ!!!) продукта:
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
При этом вся это красота сразу перестает работать, как только вы берете отечественный Миландр и проектируете свою плату, для которого нет поддержки соответствующего таргета.
В статье же пример реальный, когда весь процесс (Модель объекта — Создание ПО — Загрузка — Отладка на контроллере), выполняется в одной среде отсюда и восторг участников процесса.
Кстати пример dSPACE как раз и показывает, что для того что бы код из Simulink загнать на контроллер и посмотреть как же он всетаки работает нужно еще отдельную компанию подключать, которая смоделирует таргет. (dSPACE например)
Все что вы этометили это оносится скорее не к теории экономики, а к бухгалтерии. По сути дело это посмертаня констатация факта, зарплата, амортизация, прибыль. Если перейти к аналогии — хорошо начились кидать камни и учитывать куда они упали. Но создать формулу траекторию и предстаказать куда улитит конкретный брошенный камень так и не смогли
Что бы загрузить код сгенерированный из matlab в микроконтроллер и отладить вам нужно столько же програмистов, сколько для того, что бы его написать + специалист по matlab. А если у вас двигатель такой как в статье см. Рис.1, где модель двигателя из Simulinka не подойдет. И нужно будет писать еще и модель двигателя.
Ну и удаленная отладка, когда работа алгоритма, в контроллере отображается на схеме, этого тоже нет в Simulink.
А стоимость ПО это не главное.
А что касается системной части, с учетом уже конкретной реализации на конкретной аппаратной платфореме, то вот видео с примером отладки системной части. Алгоритм технологический мы отладили без превязки к аппаратуре и уверены, что при поступлении данных с сенсора, у нас отработет система как надо.
Паралельно отлаживает системную часть и убеждаемся, что данные с сенсоров оказываются в нужной переменной в нужное время. https://vk.com/video-96293467_456239036
Таки да. UML это совсем не про MBD. Это крафическое пердасталвение архитекуры ПО. Здесь же мы говорим про модель объекта для которого это пишем управляющее ПО, что бы получит время востановления давления в гидроаккумуляторе в примере или время открытия задвижки с учетом нагрузки. И полученное время мы учитываем в управлющем ПО. UML здесь не помощник.
На самом деле нет, вы правы и не правы одновременно, сгенерированный код будет полностью рабочим и робастным, но не полным. В предложеном подходе предпологается разделение управляющего ПО на две условные части:
1) Технологический алгоритм.
2) Системный алогритм.
Технологический алгоритм в этом случае это тот алгоритм, который получает значение показание датчика (датчиков), и должен выработать команду на исполнительный механизм (механизьмы). Это то для чего управляющее ПО и пишется. Для его проверки и нужна модель объекта управления. Именна эта часть алгоритма и поределяет будет у вас двигатель ауди иметь 192 лошадей и 250 лошадей. Механика и датчики одинаковые, а замена кода технологического алгоритма дает 25% прироста мощности. Такие вот самые по вашим словам «базовые тестовые воздействия», которые и определяют суть программы управления.
Системный алгоритм, это алгоритм который обеспечит поступления показания датчика в нужную переменную технологического алгоритма в нужный момент времени. А так же обеспечит доставку команды (открыть — закрыть), из переменной технологического алгоритма до исполнительного механизма. Системные алгоритмы важная часть ПО и без него действительно работать не будет. Но предоженный подход позволяет безопасно и надежно отлаживать технологический алогитм и генерировать код который легко и не принужденно ложится в любую аппаратуру, хотите в QNX на Intel Атом, хотите в безоперационную STM32 или миландр. Измените системную часть, которая аппаратно зависима, и вперед генерируйте себе на здоровье рабочий код. Ранее в статье про ООП в графических языках разобран пример обработки показания датчика. Привожу картинку, видите на ней вход показания TK21FO2B1_ai — это показания датчика в миливольтах. Если мы работаем под QNX, эту переменную на заданном такте обновит драйвер платы ввода вывода, это значение может быть получено по сети от другого прибора, при распределенной системе управления. Если мы работаем на микропроцессора миландр, то это значение в переменной может быть полученого со встроеного АЦП на кристалле. Но остальная схема и автоматически сгенерированый код Си не поменяется. Вы хотите проверит робастность? Да не вопрос, в моделе на схеме ставите белый шум подаете в схему TK21FO2B1_ai с шумами заданного уровня. У вас возможна задержка по времени? Опять не вопрос, добавте к шуму еще и плавающую задержку. Сигнал может пропадать на несколько тактов работы? Сделайте модель обрывов и смотрите как ваш алгоритм справляется с такой ситуацией.
А что касается реального времени, на рис. 3 видно, что в процессе моделирования, мы задаем для каждого проекта в пакете, такт расчета (преобразования входа в выход) и такт синхронизации, в масштабе модельного времени. И если ваш системный алгоритм обеспечит заданные такт на аппратной платформе, то вы получите полное совпадение работы расчетной схемы и сгенерированого ПО в реальной аппаратуре.
Интересно получается, вот что значит разные взгляды на архитектуру управляющего ПО. В исходной точке, мы с вами согласились, что модель не полная и запускать программу нельзя, и тут же пошли в разные стороны.
Я предположил, что нужно, по хорошему модель течения газа по трубам месторождения. Потому что все это мы затеваем, с одной целью — доставить газ из подводного месторождения на берег, с минимальной стоимостью доставки. Поэтому, отлаживть на модели нужно, в первую очередь, алгоритмы решаюшие технологическую задачу когда и какую задвижку двигать. Для модели из обсуждаемой статьи, где рассматривается ПО гидравлической системы управления, команда открыть — закрыть конкретную задвижку, это входная информация. И управляющее по должно ее реализовать с учетом состояния гидавлической системы.
Вы же пошли ровно в противополжном направлении, для вас уже команды есть, и не важно что там с давлением, скоростью работы привода, а важно оценить, уложимся ли мы в такты реального времени, получим ли мы данные с драйвера и прочие системые аппаратно зависимые вещи. Без которых залить код, в микроконтроллер невозможно.
Ну вобщето документацию пишут для облегчения жизни, а не для запутывая в трех соснах. Я попытался помочь людям разобратся где маркетинговая пурга, и чем она от реалной жизни отличается и как на самом деле должно быть. На хабре все об это пишут.
Да не вопрос, просто плохо, когда принципиально путаются в показания, используют термины не по назначению, и пользователю приходитя самому доходить, (или не доходить) предполагать (или не предполагать), что «Executable Specification подразумевает под собой наличие пары Plant + Controller.»
Об этом собственно и речь в статье.
А модель объекта действительно можно и на Си и на Фортране и на ASM писать, главно понимать что она должна быть и видеть где она помогает. Тогда будет счастье.
А если посмотреть на атомные международные стандарты по программированию систем управления важным для безопасности, например IEC 60880 (2006) Nuclear power plants –
Instrumentation and control systems important to safety – Software aspects for computer-based systems performing category A functions.
В них вводятся такое поятие как
Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
По такому определению Диаграмма Simulink это и есть программа для проблемно ориентированом языке Simulink. Когда модель=программа, как в стандартах атомных, то получается по мнению, офицалов MatchWorck название процесса «Модельно-ориентированное проектирование модели для встроенного ПО» Масло масленное.
Никто не спорит, что в Simulink и Матлаб можно созадать модель объекта, но когда обращаешся к документации, или слушаешь (читаешь) продажников MatchWorck, видно что они тулят что-то другое. Типа услышали звон, но не знают где он.
— Увас есть цифровой двойник?
— Да! Мы отсканировали чертежи 50-х годов, и положили их в электронный архив! У нас цифровой двойник.
Так же и Model Based Desig от офицалов MatchWork
Настоящий МОП описан в статье. Или например у атомщиков, где врерифицрованная Госатомнадзором модель объекта явялется обязательной частью проекта, как чертеж и исходный код еще со времен Чернобыля. Там настоящий МБД.
А вот, что пишут в официальных документах MatchWorck: "
Где здесь модель модель объекта вообще? В тексте — нет.
И на картинке нет. ">
Про яму и экскаватор, тут согласен. Но в москве даже на яму в метро глубиной привозят маленький бобкат с ковшом с трех литровую банку и копают им. Зависит от технической оснашенности. И АSM сейчас иногда используют, например для всяких embeded.
А то что, «больше про системы управления». Как раз об этом и речь в статье, термин Model Based Desig в его обще употребительным смысле это про то, что нужно проектировать объект и его систему управления нужно создавая модель объекта. А в изложении MathWorks модель в методологии, это модель ПО, и они тулят это как настоящий Model Based Desig принятый во всем мире, что не верно.
Так в части отладки подвоных модулей управления, модель все потребности вроде, на первый взгляд покрывает. Более сложная логика верхнего уровня, а что конкртено открывать и закрывать в месторождении, рассчитваетеся при анализе уже самого месторождения и в принципе можно эту модель добавить, будет арматура менять движения газа в трубах.
Например вот схема где в SimInTech считается течение газа, мы можем положения задвижек которые рассчитаны в схеме из статьи передавать в ниже приведенню схему трубопроводов с газом. Все можно проверять и алгоритмы управления течения газом с учетом работы гидравлических систем управления.
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
К тому же модель электродвигателя в этом проекте из Simulink не подходит. В реальности она работает по другому см. рисунок 1
Потом нельзя отобразить на схеме в процессе отладки кода в контролере его работу. Последний рисунок из модели которая подключена к контроллеру и отображает его работу на схеме.
Ну и сам код ПО из автоматического кодогенератора, тоже не без странностей. Например, для интегратора matlab генерирует такой код:
Отличное решение, -0.01 это временной шаг интегрирования.
Как только запустил с другим шагом система не работает. Опять генерит код, опять заливаем.
А ведь определение оптимального такта работы управляющей программы это практическая и реальная задача, при проектировании любой системы управления.
Так что восторг участников когда у них реально заработала понятен
Объект управления в реальном времени в FPGA это возможно только для ограниченного набора моделей. Например уложить в логику FPGA модель какой нибудь теплообменника с «честной» теплофизикой вряд ли возможно.
С моей точки зрения, попытки загнать работу модели в «реальное время» на стадии отладки и проектирования ПО, не всегда оправданы. На стадии проектирования, достаточно обеспечить синхронизацию работы управляющей программы по тактам с модельным временем. И добиться того, что при заданных входных воздействиях система управляет объектом, так как требует проект. Даже если моделирование происходит медленнее или быстрее реального времени. После этого достаточно убедится, что цикл вычислений укладывается в временной такт работы в реальном времени на контроллере.
Хотя возможно для систем, где простые алгоритмы и главная проблема обеспечить передачу данных от сенсоров в контроллер и воздействия на исполнительные механизмы тестирование реальном времени действительно необходимы.
«VEOS is part of the MathWorks Connections Program. dSPACE works closely together with MathWorks to make sure that C code generated with the Simulink® Coder™ can be integrated and simulated with VEOS.»
А если вспомнить что для получение кода таргета и Simulink нужно использовать 3 (ТРИ!!!) продукта:
1)MATLAB Coder
2)Simulink Coder
3)Embedded Coder
При этом вся это красота сразу перестает работать, как только вы берете отечественный Миландр и проектируете свою плату, для которого нет поддержки соответствующего таргета.
В статье же пример реальный, когда весь процесс (Модель объекта — Создание ПО — Загрузка — Отладка на контроллере), выполняется в одной среде отсюда и восторг участников процесса.
Что бы загрузить код сгенерированный из matlab в микроконтроллер и отладить вам нужно столько же програмистов, сколько для того, что бы его написать + специалист по matlab. А если у вас двигатель такой как в статье см. Рис.1, где модель двигателя из Simulinka не подойдет. И нужно будет писать еще и модель двигателя.
Ну и удаленная отладка, когда работа алгоритма, в контроллере отображается на схеме, этого тоже нет в Simulink.
А стоимость ПО это не главное.
А что касается системной части, с учетом уже конкретной реализации на конкретной аппаратной платфореме, то вот видео с примером отладки системной части. Алгоритм технологический мы отладили без превязки к аппаратуре и уверены, что при поступлении данных с сенсора, у нас отработет система как надо.
Паралельно отлаживает системную часть и убеждаемся, что данные с сенсоров оказываются в нужной переменной в нужное время.
https://vk.com/video-96293467_456239036
1) Технологический алгоритм.
2) Системный алогритм.
Технологический алгоритм в этом случае это тот алгоритм, который получает значение показание датчика (датчиков), и должен выработать команду на исполнительный механизм (механизьмы). Это то для чего управляющее ПО и пишется. Для его проверки и нужна модель объекта управления. Именна эта часть алгоритма и поределяет будет у вас двигатель ауди иметь 192 лошадей и 250 лошадей. Механика и датчики одинаковые, а замена кода технологического алгоритма дает 25% прироста мощности. Такие вот самые по вашим словам «базовые тестовые воздействия», которые и определяют суть программы управления.
Системный алгоритм, это алгоритм который обеспечит поступления показания датчика в нужную переменную технологического алгоритма в нужный момент времени. А так же обеспечит доставку команды (открыть — закрыть), из переменной технологического алгоритма до исполнительного механизма. Системные алгоритмы важная часть ПО и без него действительно работать не будет. Но предоженный подход позволяет безопасно и надежно отлаживать технологический алогитм и генерировать код который легко и не принужденно ложится в любую аппаратуру, хотите в QNX на Intel Атом, хотите в безоперационную STM32 или миландр. Измените системную часть, которая аппаратно зависима, и вперед генерируйте себе на здоровье рабочий код. Ранее в статье про ООП в графических языках разобран пример обработки показания датчика. Привожу картинку, видите на ней вход показания TK21FO2B1_ai — это показания датчика в миливольтах. Если мы работаем под QNX, эту переменную на заданном такте обновит драйвер платы ввода вывода, это значение может быть получено по сети от другого прибора, при распределенной системе управления. Если мы работаем на микропроцессора миландр, то это значение в переменной может быть полученого со встроеного АЦП на кристалле. Но остальная схема и автоматически сгенерированый код Си не поменяется. Вы хотите проверит робастность? Да не вопрос, в моделе на схеме ставите белый шум подаете в схему TK21FO2B1_ai с шумами заданного уровня. У вас возможна задержка по времени? Опять не вопрос, добавте к шуму еще и плавающую задержку. Сигнал может пропадать на несколько тактов работы? Сделайте модель обрывов и смотрите как ваш алгоритм справляется с такой ситуацией.
А что касается реального времени, на рис. 3 видно, что в процессе моделирования, мы задаем для каждого проекта в пакете, такт расчета (преобразования входа в выход) и такт синхронизации, в масштабе модельного времени. И если ваш системный алгоритм обеспечит заданные такт на аппратной платформе, то вы получите полное совпадение работы расчетной схемы и сгенерированого ПО в реальной аппаратуре.
Я предположил, что нужно, по хорошему модель течения газа по трубам месторождения. Потому что все это мы затеваем, с одной целью — доставить газ из подводного месторождения на берег, с минимальной стоимостью доставки. Поэтому, отлаживть на модели нужно, в первую очередь, алгоритмы решаюшие технологическую задачу когда и какую задвижку двигать. Для модели из обсуждаемой статьи, где рассматривается ПО гидравлической системы управления, команда открыть — закрыть конкретную задвижку, это входная информация. И управляющее по должно ее реализовать с учетом состояния гидавлической системы.
Вы же пошли ровно в противополжном направлении, для вас уже команды есть, и не важно что там с давлением, скоростью работы привода, а важно оценить, уложимся ли мы в такты реального времени, получим ли мы данные с драйвера и прочие системые аппаратно зависимые вещи. Без которых залить код, в микроконтроллер невозможно.
Об этом собственно и речь в статье.
А модель объекта действительно можно и на Си и на Фортране и на ASM писать, главно понимать что она должна быть и видеть где она помогает. Тогда будет счастье.
Instrumentation and control systems important to safety – Software aspects for computer-based systems performing category A functions.
В них вводятся такое поятие как
Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
По такому определению Диаграмма Simulink это и есть программа для проблемно ориентированом языке Simulink. Когда модель=программа, как в стандартах атомных, то получается по мнению, офицалов MatchWorck название процесса «Модельно-ориентированное проектирование модели для встроенного ПО» Масло масленное.
— Увас есть цифровой двойник?
— Да! Мы отсканировали чертежи 50-х годов, и положили их в электронный архив! У нас цифровой двойник.
Так же и Model Based Desig от офицалов MatchWork
Настоящий МОП описан в статье. Или например у атомщиков, где врерифицрованная Госатомнадзором модель объекта явялется обязательной частью проекта, как чертеж и исходный код еще со времен Чернобыля. Там настоящий МБД.
А вот, что пишут в официальных документах MatchWorck:
Где здесь модель модель объекта вообще? В тексте — нет.
И на картинке нет.
А то что, «больше про системы управления». Как раз об этом и речь в статье, термин Model Based Desig в его обще употребительным смысле это про то, что нужно проектировать объект и его систему управления нужно создавая модель объекта. А в изложении MathWorks модель в методологии, это модель ПО, и они тулят это как настоящий Model Based Desig принятый во всем мире, что не верно.
Например вот схема где в SimInTech считается течение газа, мы можем положения задвижек которые рассчитаны в схеме из статьи передавать в ниже приведенню схему трубопроводов с газом. Все можно проверять и алгоритмы управления течения газом с учетом работы гидравлических систем управления.
Смотреть здесь... и здесь...