Как стать автором
Обновить

Модельно-ориентированное проектирование – как не повторить Чернобыль

Время на прочтение 13 мин
Количество просмотров 11K
Всего голосов 13: ↑11 и ↓2 +9
Комментарии 26

Комментарии 26

Не расскажете про трудозатраты в условных "чел/мес"? Mathworks заявляет о снижении трудозатрат на 25%-50% при использовании МОП при разработке. На ваш взгляд на сколько это соответствует действительности?

Все зависит от процесса на самом деле. Цифры взяты с потолка, как средняя темперутра пациентов по больнице, с учетом температуры холодильника морга и температуры печки для сжигания мед отходов.
МОП позволяет сокртатить и больше, если в разработке приходится отлаживать на «живом» объекте или проводить эксперименты. А может просто увеличить трудозатраты, за счет создания модели объекта.

Насколько экскаватор может ускорить рытье ямы. Зависит от масш аба ямы. Если по колено метр на метр — то накладные расходы на подвоз экскаватора могут свести на нет всю затею. Если же котлован под фундамент, да не один — тогда без экскаватора туго.


Еще хороша аналогия с компилятором: насколько он ускоряет разработку ПО? Можно ведь и на асме написать. Сейчас это звучит смешно, а вот лет 30 назад это был вполне резонный вопрос.


Хочется также добавить, что МБД от MathWorks все же больше про системы управления. И их подход плохо применим к ПО на которое не ложится data flow пврвдигма.

Про яму и экскаватор, тут согласен. Но в москве даже на яму в метро глубиной привозят маленький бобкат с ковшом с трех литровую банку и копают им. Зависит от технической оснашенности. И АSM сейчас иногда используют, например для всяких embeded.
А то что, «больше про системы управления». Как раз об этом и речь в статье, термин Model Based Desig в его обще употребительным смысле это про то, что нужно проектировать объект и его систему управления нужно создавая модель объекта. А в изложении MathWorks модель в методологии, это модель ПО, и они тулят это как настоящий Model Based Desig принятый во всем мире, что не верно.
Под «больше про системы управления» я имел ввиду сферу применения.

>> в изложении MathWorks модель в методологии, это модель ПО

Это где Вы такое нашли? У них везде довольно четкое разделение на Plant and Controller. И то и другое являются моделями в процессе разработки.

>> они тулят это как настоящий Model Based Desig

Как по мне — так у них МБД самый что ни на есть настоящий + еще немножко. Если не согласны — то укажите, у кого настоящий.
Никто не спорит, что в Simulink и Матлаб можно созадать модель объекта, но когда обращаешся к документации, или слушаешь (читаешь) продажников MatchWorck, видно что они тулят что-то другое. Типа услышали звон, но не знают где он.
— Увас есть цифровой двойник?
— Да! Мы отсканировали чертежи 50-х годов, и положили их в электронный архив! У нас цифровой двойник.
Так же и Model Based Desig от офицалов MatchWork
Настоящий МОП описан в статье. Или например у атомщиков, где врерифицрованная Госатомнадзором модель объекта явялется обязательной частью проекта, как чертеж и исходный код еще со времен Чернобыля. Там настоящий МБД.
А вот, что пишут в официальных документах MatchWorck:
"
Где здесь модель модель объекта вообще? В тексте — нет.
И на картинке нет.
">
Вы довольно резко отзываетесь о продукте на основании общения с «продажниками, которые тулят». Это крайне наивно требовать от них сравнимой глубины компетенций и не делает Вам чести. Онако, я не столь категоричен касательно последнего аргумента и предполагаю, что Executable Specification подразумевает под собой наличие пары Plant + Controller. Но не в этом суть.

Суть в том, что постановка вопроса в корне не верна. Если вязть, например, язык С — то это полноценный инструмент для MBD, так как MBD — это методология разработки. С ним Вы можете сделать управление требованиями, испольняемые спецификации и модели для объекта управления и системы управления, Вы сможете сделать формальную верификацию Ваших алгоритмов и доказать их безотказность, проводить декомпозицию сложности и интегрировать артефакты на финальных этапах. При полном отсутствии даже упоминания о МБД в документации (стандарте) на С. Но это не делает инструмент не применимым к конкретной методологии, так ведь?

Как Вы упоминали в своей статье, MBD был придуман не в MathWorks, но эти ребята делают хорошую работу и облегчают жизнь инженера. Где-то хуже, где-то лучше. Но все же облегчают.

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

PS: Я далеко не адепт их продуктов и решений, некоторые из них ужасны, как например переход к бинарному формату для моделей Симулинк и довольно плохо реализованный аппарат для реализации merge при использовании системы контроля версий.
Просто нужно знать зону применимости продукта и применять к отраслевым стандартам со знанием дела. Это с опытом обычно приходит.
Да не вопрос, просто плохо, когда принципиально путаются в показания, используют термины не по назначению, и пользователю приходитя самому доходить, (или не доходить) предполагать (или не предполагать), что «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 название процесса «Модельно-ориентированное проектирование модели для встроенного ПО» Масло масленное.
очень внимательно нужно слушать такие заявления и уточнять. х% на каком этапе жизненного цикла? При проектировании? Вряд ли. Наверно имеет смысл говорить о снижении трудозатрат на всём цикле разработки систем управления, вплоть до пуско-наладки и запуска в эксплуатацию конечного изделия. В проектировании необходимо учитывать процент взаимозаменяемости матмоделей от проекта к проекту. Грубо говоря, матмодель нескольких различных энергоблоков может не сильно отличаться друг от друга, тогда основные трудозатраты будут отнесены к созданию самой первой матмодели, и наверно, в сравнении с текущими процессами они не будут ниже (как бы не стали выше). Последующие проекты будут выполняться значительно быстрее, с существенным ростом качества. Качество выполнения работ на этапе проектирования очень сильно влияет как на дальнейшие трудозатраты по проекту, так и стоимость изделия целиком.
Mathworks заявляет о снижении трудозатрат на 25%-50% при использовании МОП при разработке.

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

Тут надо бы признаться, что модель не полная и запускать программу отлаженную на такой модели сразу в поле нельзя.
Модель только лишь для того чтобы автоматизировать некоторые тестовые воздействия на программу, и то не все, а только самые базовые.
В этой теме самое интересное это автогенерация кода. Какой он получается и насколько сложно его интегрировать в уже имеющуюся платформу.
С этим все порядке чистый сертифицированый и безопасный Си, используется для АЭС.
Смотреть здесь... и здесь...

Это совсем не то.
Выж не для bare metal генерите код.
У вас там QNX где-то проскакивает. Короче RTOS.
В вашей модели вообще не видно сервисов RTOS, где контроль реального времени?
Или надежда но то что все процессы достаточно медленные?
Эт одна из проблем вашей модели.
Другая проблема в программных интерфейсах модели и платформы на которую она переносится. Здесь не проработано. Модель строится с учетом доступных программных интерфейсов если она предусматривает генерацию рабочего кода.
Далее масштаб времени. Не видно других моделей более низкого и более высокого уровня в масштабе времени.
Где детализованные модели клапанов? Или надежда на готовые библиотечные элементы. Опасное упрощение.
Словом представленная вами модель — это такой эскиз. По нему можно в принципе проектировать архитектуру софта некоторого уровня абстракции, но сгенерить достаточно робастный и рабочий код — нет.
Интересно получается, вот что значит разные взгляды на архитектуру управляющего ПО. В исходной точке, мы с вами согласились, что модель не полная и запускать программу нельзя, и тут же пошли в разные стороны.
Я предположил, что нужно, по хорошему модель течения газа по трубам месторождения. Потому что все это мы затеваем, с одной целью — доставить газ из подводного месторождения на берег, с минимальной стоимостью доставки. Поэтому, отлаживть на модели нужно, в первую очередь, алгоритмы решаюшие технологическую задачу когда и какую задвижку двигать. Для модели из обсуждаемой статьи, где рассматривается ПО гидравлической системы управления, команда открыть — закрыть конкретную задвижку, это входная информация. И управляющее по должно ее реализовать с учетом состояния гидавлической системы.
Вы же пошли ровно в противополжном направлении, для вас уже команды есть, и не важно что там с давлением, скоростью работы привода, а важно оценить, уложимся ли мы в такты реального времени, получим ли мы данные с драйвера и прочие системые аппаратно зависимые вещи. Без которых залить код, в микроконтроллер невозможно.
На самом деле нет, вы правы и не правы одновременно, сгенерированный код будет полностью рабочим и робастным, но не полным. В предложеном подходе предпологается разделение управляющего ПО на две условные части:
1) Технологический алгоритм.
2) Системный алогритм.
Технологический алгоритм в этом случае это тот алгоритм, который получает значение показание датчика (датчиков), и должен выработать команду на исполнительный механизм (механизьмы). Это то для чего управляющее ПО и пишется. Для его проверки и нужна модель объекта управления. Именна эта часть алгоритма и поределяет будет у вас двигатель ауди иметь 192 лошадей и 250 лошадей. Механика и датчики одинаковые, а замена кода технологического алгоритма дает 25% прироста мощности. Такие вот самые по вашим словам «базовые тестовые воздействия», которые и определяют суть программы управления.
Системный алгоритм, это алгоритм который обеспечит поступления показания датчика в нужную переменную технологического алгоритма в нужный момент времени. А так же обеспечит доставку команды (открыть — закрыть), из переменной технологического алгоритма до исполнительного механизма. Системные алгоритмы важная часть ПО и без него действительно работать не будет. Но предоженный подход позволяет безопасно и надежно отлаживать технологический алогитм и генерировать код который легко и не принужденно ложится в любую аппаратуру, хотите в QNX на Intel Атом, хотите в безоперационную STM32 или миландр. Измените системную часть, которая аппаратно зависима, и вперед генерируйте себе на здоровье рабочий код. Ранее в статье про ООП в графических языках разобран пример обработки показания датчика. Привожу картинку, видите на ней вход показания TK21FO2B1_ai — это показания датчика в миливольтах. Если мы работаем под QNX, эту переменную на заданном такте обновит драйвер платы ввода вывода, это значение может быть получено по сети от другого прибора, при распределенной системе управления. Если мы работаем на микропроцессора миландр, то это значение в переменной может быть полученого со встроеного АЦП на кристалле. Но остальная схема и автоматически сгенерированый код Си не поменяется. Вы хотите проверит робастность? Да не вопрос, в моделе на схеме ставите белый шум подаете в схему TK21FO2B1_ai с шумами заданного уровня. У вас возможна задержка по времени? Опять не вопрос, добавте к шуму еще и плавающую задержку. Сигнал может пропадать на несколько тактов работы? Сделайте модель обрывов и смотрите как ваш алгоритм справляется с такой ситуацией.
image
А что касается реального времени, на рис. 3 видно, что в процессе моделирования, мы задаем для каждого проекта в пакете, такт расчета (преобразования входа в выход) и такт синхронизации, в масштабе модельного времени. И если ваш системный алгоритм обеспечит заданные такт на аппратной платформе, то вы получите полное совпадение работы расчетной схемы и сгенерированого ПО в реальной аппаратуре.

А что касается системной части, с учетом уже конкретной реализации на конкретной аппаратной платфореме, то вот видео с примером отладки системной части. Алгоритм технологический мы отладили без превязки к аппаратуре и уверены, что при поступлении данных с сенсора, у нас отработет система как надо.
Паралельно отлаживает системную часть и убеждаемся, что данные с сенсоров оказываются в нужной переменной в нужное время.
https://vk.com/video-96293467_456239036

У вас там QNX где-то проскакивает. Короче RTOS.
В вашей модели вообще не видно сервисов RTOS, где контроль реального времени?

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


Поэтому код, сгенерированный MBD всегда крутится на real-time платформе, у которой весьма простая задача — обеспечить детерминизм. Во всем. Сигнал А должен доставляться в алгоритм с задержкой X при любых условиях. Алгоритм B должен запускаться каждые 10мс независимо от нагрузки системы. Время передачи сигнала B от Алгоритма B к алгоритму C должно быть Y циклов исполнения. Алгоритм С должен выполняться за Z миллисекунд.
И так далее. Это характеристики платформы, которые должны быть гарантированными, и их несоблюдение приравнивается к отказу оборудования.


Тогда в модели все это можно не моделировать или моделировать с упрощениями. И код будет работать.

Так в части отладки подвоных модулей управления, модель все потребности вроде, на первый взгляд покрывает. Более сложная логика верхнего уровня, а что конкртено открывать и закрывать в месторождении, рассчитваетеся при анализе уже самого месторождения и в принципе можно эту модель добавить, будет арматура менять движения газа в трубах.
Например вот схема где в SimInTech считается течение газа, мы можем положения задвижек которые рассчитаны в схеме из статьи передавать в ниже приведенню схему трубопроводов с газом. Все можно проверять и алгоритмы управления течения газом с учетом работы гидравлических систем управления.
image
А если бы вместо эксперимента на реакторе можно было все то же самое сделать на математической модели объекта...

Не помогло бы. Если при создании реактора не заметили проблему не смотря на все расчеты — почему её должны были заметить при проведении эксперимента на мат. модели?

Потому что модель, легко бы показала, что возможна ситуация когда сверху вода и все стрежни тоже сверху. Это можно было посмотреть на динамической модели.
А расчеты были преведены в статике. В статике стержень вверху тогда когда реактор уже работает и сверху пар. Эфекта разгона при опускании сверху не было.
Статья интересная и на важную тему.
Но у меня есть один вопрос.
Вы обошлись без упоминания UML. Это сознательно?
Таки да. UML это совсем не про MBD. Это крафическое пердасталвение архитекуры ПО. Здесь же мы говорим про модель объекта для которого это пишем управляющее ПО, что бы получит время востановления давления в гидроаккумуляторе в примере или время открытия задвижки с учетом нагрузки. И полученное время мы учитываем в управлющем ПО. UML здесь не помощник.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории