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

    В продолжение темы ООП в графических языках программирования разберемся более подробно с model-based design. Что такое модельно-ориентированное проектирование (МОП), как его правильно готовить и с чем его едят.


    Некоторые авторы в своих публикациях при описании модельно-ориентированного проектирования систем управления транслируют представление, что под словом «модель» подразумевается «модель системы управления». Что не есть правильно.



    Почему это не верно, как делать правильно и причем здесь Чернобыль, читайте далее.

    Вот типичный пример – картинка из статьи уважаемых авторов, про «лучшие практики разработки ПО с использованием модельно-ориентированного проектирования»:


    Рисунок 1. Один из вариантов МОП.

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


    Или, например, картинка к рекомендации типового процесса разработки ПО:



    Рисунок 2. Другой вариант МОП-процесса.

    А где на этой картинке модель? Вот этот квадратик, из которого получается исходный код? Серьезно?! Так это опять модель управляющего ПО.


    Особенно умиляет на этой картинке наличие исходных требований к ПО.
    Как вам, например, такое самое обычное, практически хрестоматийное, требование к системе управления:


    «При повышении давления выше предельного значения время закрытия (открытия) предохранительного клапана должно составлять не более 5 секунд


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

    Model-based design provides an efficient approach for establishing a common framework for communication throughout the design process while supporting the development cycle (V-model). In model-based design of control systems, development is manifested in these four steps:

    1. modeling a plant,
    2. analyzing and synthesizing a controller for the plant,
    3. simulating the plant and controller,
    4. integrating all these phases by deploying the controller.


    Разработка модели объекта является первым пунктом при определении МОП. Сначала – модель объекта, а потом уже управление для него. И это правильно: нет модели объекта, «всем спасибо – все свободны» и это не модельно-ориентированное проектирование, а сплошной обман потребителя.


    Почему это важно и причем здесь Чернобыль?


    В Чернобыле произошло именно, то что происходит при отсутствии модели объекта. Советские ученые задались вопросом: «А что будет, если отключить электросеть, а насосы охлаждения реактора питать током от генератора, работающего на выбегающей турбине? Сколько воды успеют прокачать насосы через реактор, пока турбина и генератор не остановятся?» Интересно, что такой вопрос они задавали на основе опыта протекания аварии на американской АЭС, где подачи воды не хватило для охлаждения и американский реактор расплавился. И чтобы быть уверенным, что наши реакторы не плавятся, решили провести эксперимент. Наверное, ответ на этот вопрос позволил бы сделать следующее поколение реакторов РБМК еще более безопасным. Хотели как лучше, а получилось как всегда. В результате эксперимента безопасный реактор сначала привели к опасному состоянию, а потом взорвали. И следующего поколения реакторов РБМК больше нет и не предвидится. Аминь.


    А если бы вместо эксперимента на реакторе можно было все то же самое сделать на математической модели объекта, то, вполне возможно, мы бы сейчас вместо реакторов ВВЭР-1200 строили по миру РБМК-2400.


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


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


    Правильный модельно-ориентированный подход.


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


    Управления основными потоками добываемого газа подводой осуществляет гидравлическая подводная арматура. На берегу находится насосная станция, которая обеспечивает давление в гидравлической системе, масло по шлангокабелю подается под давлением под воду. Открытие и закрытие арматуры осуществляют гидроприводы, управления которыми осуществляется с помощью распределенной системы управления. Система состоит из:


    • наземного модуля управления всем месторождением;
    • набора подводных модулей управления (ПМУ) обеспечивающих непосредственное управления арматурой.


    Для удобства установки и обслуживания трубопроводы объединяются в манифольды, где на одной платформе установлена необходимая арматура и модули управления. Если в наземной станции можно использовать стандартные средства SCADA, архивные сервера и ПЛК с операционными системами обычными и (или) реального времени, то подводный модуль управления – это, как правило, безоперационный микропроцессор, управляющий код для которого должен быть разработан отдельно от берегового управляющего ПО. (Никакого С++, только Си, только хардкод) Потом несколько этих ПМУ должны быть интегрированы в общую систему и протестированы. И при этом вся система должна работать как единое целое и обеспечивать открытие и закрытие арматуры в течении 30 лет под водой.


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


    Комплексная модель подводной системы управления


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



    Рисунок 3. Пакет комплексной модели системы управления СПД.


    В данном пакете присутствует проект – модель наземной гидравлической станции (файл 200.prt на рис. 3), обеспечивающий моделирование динамических процессов работы оборудования наземной системы подачи гидравлической жидкости под воду. (см. рис. 4)



    Рисунок 4. Расчетная схема наземной гидравлической станции.


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



    Рисунок 5. Проект системы управления наземным модулем.


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


    Разработка подводных модулей управления (ПМУ) осуществляется на основании проекта разделения основных магистралей течения добываемого газа между манифольдами. Сначала формируются скважины, определяется обвязка трубопроводов и арматуры между скважинами и берегом, потом разрабатывается гидравлическая система управления этой арматурой.


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


    Рассмотрим подводный модуль управления (ПМУ) 502. Здесь используются два проекта:

    • 502.prt – модель гидравлических систем (рис. 6, 7);
    • 502a.prt – проект система управления ПМУ (рис. 8).


    Рисунок 6. Гидравлическая схема ПМУ.


    Данная расчетная схема обеспечивает моделирование поведения гидравлической системы управления и расчет расходов и давлений в системе, управляемой с помощью 502 ПМУ. Расчетная схема гидравлики позволяет задавать воздействия на исполнительные механизмы и получать данные датчиков, рассчитанные в модели физических процессов. Пока у нас нет наземной станции в блок 502 P (левый нижний угол рис. 6), можно задать давление, создаваемое гидростанцией в качестве граничного условия.


    В системе на рисунке изображены 6 гидравлических запорно-регулирующих арматур (ЗРА), каждая из которых по своей сути представляет гидроцилиндр подключенный к двум линиям высокого и низкого давления. Подаем давление большее в верхнюю часть цилиндра, давление двигает шток вниз, подаем больше давление в нижнюю часть цилиндра, шток поднимается вверх.


    За переключение отвечают распределительные клапаны, расположенные внутри белого блока (см. рис. 7).



    Рисунок 7. Блок распределительных клапанов в модели.


    Принцип работы простой: в зависимости от положения золотника камеры цилиндра соединятся с разными линиями. Передвинули золотник – поменяли направление движения штока в цилиндре. (подробнее про моделирование гидравлики можно посмотреть здесь…)



    Рисунок 8. Проект системы управления ПМУ.

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


    Рассмотрим процесс проектирования блока управления запорно-регулирующей аппаратурой. Данный блок в схеме получает 4 входных сигнала и формирует 8 выходных сигналов. (см. рис. 9)



    Рисунок 9. Блок управления ЗРА (Тип 1).


    Внутренняя схема блока состоит из двух листов алгоритмов. Первый лист представлен на рисунке 10а, второй — на рисунке 10b.



    Рисунок 10a. Расчетная схема блока управления арматурой. Лист 1.



    Рисунок 10b. Расчетная схема блока управления арматурой. Лист 2.


    При разработке данного блока используют следующие виды сигналов:

    • сигналы, полученные по линиям связи (голубые блоки);
    • параметры и сигналы, получаемые из базы данных сигналов (бледно-желтые блоки);
    • сигналы, передаваемые в базу данных сигналов (бледно-голубые блоки);
    • сигналы, передаваемые в память (ярко-желтые блоки);
    • сигналы получаемые из памяти (ярко-зеленые блоки).

    Расчетная схема блока управления арматурой является векторной. Это значит, что по каждой линии передается не один сигнал управления, а вектор сигналов, размерность которого соответствует количеству оборудования данного типа, установленного в ПМУ. Для связи между расчетным блоком и сигналами, параметрами и командами для конкретного экземпляра оборудования используются интерфейсные блоки.


    Таким образом, разработав и проверив одну схему управления типовым элементом, на схему можно поместить столько интерфейсных блоков, сколько оборудования данного типа подключено к подводному модулю управления. В рассматриваемом случае в ПМУ находятся два интерфейсный блока для запорно-регулирующей арматуры тип 1 (см. рис. 8).


    Все переменные сигналы и параметры, которые нужны для блока управления, помещаются в соответствующую категорию базы сигналов ZRAT1. Часть категории представлена на рисунке 11.


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



    Рисунок 11. Группа сигналов для блока управления ZRAT1


    Система кодирования в проекте


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


    В рассматриваемом примере на гидравлической схеме мы имеем два экземпляра арматуры, расположенной в системе 502, которая управляется блоком ЗРА ТИП 1. (см. рис. 12.) Их имена в базе данных – 502GTVOO1 и 502GTVOO2. Окно базы данных сигналов представлено на рисунке 12.



    Рисунок 12. База данных сигналов оборудования СУ СПД.


    Система кодирования определяет имена переменных для модулей управляющего программного обеспечения и позволяет автоматизировать процессы наименования сигналов в пределах всего разрабатываемого программного модуля. Любое имя переменной состоит из имени группы сигналов и имени переменной соединенной знаком «_».


    Для любой запорно-регулирующей арматуры, относящееся к тиру «ЗРА Тип1», наименование входных сигналов, переменных состояния, выходных переменных выглядит как «код_арматуры»_«имя_сигнала». Для клапана 502GTV002 в базе данных сигналов находятся 65 переменных, например:


    Команды:
    502GTV002_open_remудаленная команда «открыть».
    502GTV002_close_remудаленная команда «закрыть».
    502GTV002_open_rem_zпредварительная команда «закрыть».

    Переменные состояния арматуры:
    502GTV002_openеdклапан полностью открыт.
    502GTV002_notopenedклапан не открыт.
    502GTV002_notclosedклапан не закрыт.
    502GTV002_losedклапан полностью зарыт.

    Параметры подвода и отвода гидравлической жидкости:

    502GTV002_ХТК1давление в рабочей линии.
    502GTV002_ХТК2давление в напорной линии.
    502GTV002_ХТК3давление в сливной линии.

    Если мы добавим еще одну единицу арматуры на эту схему, то ее имя будет 502GTV003, где по принятой системе кодирования


    502имя модуля.
    GTVтип арматуры.
    003порядковый номер арматуры данного типа в модуле.

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


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



    Рисунок 13. Передача сигналов с датчиков в блок управления ЗРА Т1.

    В результате работы данного блока формируется команда на перемещение золотников в распределительных клапанах, отвечающих за ЗРА с именем 502GTV002.


    Во время совместного расчета значения параметров, рассчитанные в гидравлической модели, передаются в блок обработки показаний датчиков (см. рис. 14), где выполняется анализ полученных данных на достоверность, фильтрация, перевод в требуемые величины измерения.



    Рисунок 14. Расчетная схема обработки датчиков.

    Приведенная на рисунке 14 расчетная схема обработки показаний датчиков также является полностью работоспособной программой. Для переноса данной схемы в реальную аппаратуру управления достаточно, чтобы на такте обмена данными в реальной аппаратуре в переменную «Расчетное значение» было помещено значение, полученное с платы ввода–вывода реального датчика.


    Данная схема также является векторной и обеспечивает обработку всех датчиков, входящих в гидравлическую схема 502.prt


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


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


    • Поместить блок управления оборудованием.
    • Добавить столько интерфейсных блоков, сколько экземпляров оборудования будет подключено у ПМУ.

    Методология ООП в графических языках в действии.


    Верификация управляющего ПО с использованием гидравлической модели.


    Проверенные путем изолированного моделирования расчетные модули управляющего ПО запускаются в расчет совместно с математической моделью гидравлической системы СПД. Рассчитанные значения передаются в блок обработки сигналов датчиков и направляются в алгоритмы обработки. Физическая модель оборудования позволяет оценить работу системы в динамике и проверить принимаемые проектные решения в динамических режимах.


    Такая модель уже вполне может подтвердить выполнения требования к управляющему ПО типа приведенного выше.


    «При превышении давления выше предельного, время открытия (закрытия) предохранительного клапана не должно превышать 5 секунд»


    Например, для гидравлической системы управления подводной добычей важным фактором является сохранение давления в подводных аккумуляторах. Отсутствие давления в гидроаккумуляторе делает невозможным работу гидравлической системы управления. После активного использования гидравлической системы необходимо время для восстановления давления за счет работы наземной гидравлической станции. Модель позволяет оценить снижение и скорость восстановления давления при открытии и закрытии арматуры. Для этого мы выдаем команды на открытие и закрытие и оцениваем переходной процесс. А поскольку мы работаем с графическим языком и визуальной системой моделирования, все, что происходит в управляющем ПО и проектируемой системе, становится наглядно и понятно. Программист может видеть, как работает объект, а инженер-гидравлик видит, как работает программа.


    Расчетное моделирование отображается прямо на расчетной схеме, что позволяет оценить положение запорно-регулирующей арматуры (см. рис. 15).



    Рисунок 15. Отображение положения клапана на расчетной схеме.


    Также можно посмотреть состояния клапанов. Например, распределительные клапаны отображают положение подключения гидравлических линий сравните положения РК9, РК10 и РК7, РК8 (см. рис. 16).



    Рисунок 16. Распределительные клапаны гидросистемы.


    Схема алгоритма при моделировании отображает значения сигналов на линиях связи (см. рис. 17). Управляющее ПО, созданное в графическом виде, понятно даже не программисту. Да и программисту тоже удобнее разбираться с графическим видом, чем с тем, что напрограммировали другие разработчики или он сам несколько лет назад.



    Рисунок 17. Схема алгоритма в режиме отображения параметров.


    Ну, и конечно, проверка соблюдения требования и параметров работы управляющего ПО.


    На графике 18 представлен процесс изменения давления в аккумуляторе и расхода при открытии и закрытии одновременно двух клапанов. Можно оценить просадку давления, расход гидравлической жидкости и время восстановления давления.


    На графике 19 представлен процесс открытия и закрытия одного клапана.



    Рисунок 18. Результаты моделирования работы 2-х ЗРА.



    Рисунок 19. Результаты моделирования работы одной ЗРА.


    Сравнение графиков показывает, что, когда гидравлическая система открывает два клапана одновременно, время открытия увеличивается почти в два раза, и давление в гидроаккумуляторе снижается до 30,5 МПа, а если открывать только один клапан, то давление снижается до 32, МПа.


    На этом графике мы видим очевидную проверку требования типа «При повышении давления предельного значения время закрытия (открытия) предохранительного клапана должно составлять не более 5 секунд»


    На графике видно, что два клапана одновременно открываются за 5 секунд, при полностью заряженном гидроаккумуляторе. Отсюда можно сделать вывод, что для удовлетворения требования «закрытия (открытия) аварийного клапана за 5 сек», мы должны одновременно открывать или закрывать только одну арматуру ЗРА, подключенную к тому же аккумулятору, что и аварийный клапан, и выдерживать после каждой операции не менее 8 секунд (время восстановления давления в гидроаккумуляторе). В противном случае мы можем не обеспечить требуемое время закрытия (открытия аварийного клапана).


    Выводы


    Правильное модельно-ориентированное проектирование систем управления, должно содержать математическую модель объекта!


    Математическая модель объекта значительно повышает качество тестирования управляющего программного обеспечения. Математическая модель позволяет оценить переходные процессы и проверить выполнение требований в различных режимах работы объекта.


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


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


    Пользуйтесь правильным модельно-ориентированным проектированием, и будет вам счастье!


    В качестве бонуса, тем кто дочитал — короткое видео с демонстрацией работы модели.

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

    О чем рассказать дальше?

    Поделиться публикацией

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

      +1

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

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

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


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


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

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

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

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

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

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

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

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

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

                  PS: Я далеко не адепт их продуктов и решений, некоторые из них ужасны, как например переход к бинарному формату для моделей Симулинк и довольно плохо реализованный аппарат для реализации merge при использовании системы контроля версий.
                  Просто нужно знать зону применимости продукта и применять к отраслевым стандартам со знанием дела. Это с опытом обычно приходит.
                    +1
                    Да не вопрос, просто плохо, когда принципиально путаются в показания, используют термины не по назначению, и пользователю приходитя самому доходить, (или не доходить) предполагать (или не предполагать), что «Executable Specification подразумевает под собой наличие пары Plant + Controller.»
                    Об этом собственно и речь в статье.
                    А модель объекта действительно можно и на Си и на Фортране и на ASM писать, главно понимать что она должна быть и видеть где она помогает. Тогда будет счастье.
                      0
                      приходитя самому доходить, (или не доходить) предполагать (или не предполагать)

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

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

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

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

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

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

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

                          Самое читаемое