Pull to refresh
132
417.2
Вячеслав @petuhoff

Моделирование сложных технических систем

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

А расчеты были преведены в статике. В статике стержень вверху тогда когда реактор уже работает и сверху пар. Эфекта разгона при опускании сверху не было.
Потому что модель, легко бы показала, что возможна ситуация когда сверху вода и все стрежни тоже сверху. Это можно было посмотреть на динамической модели.
Все зависит от процесса на самом деле. Цифры взяты с потолка, как средняя темперутра пациентов по больнице, с учетом температуры холодильника морга и температуры печки для сжигания мед отходов.
МОП позволяет сокртатить и больше, если в разработке приходится отлаживать на «живом» объекте или проводить эксперименты. А может просто увеличить трудозатраты, за счет создания модели объекта.
А логика обработки сигнала с датчика, написанная на графическом зыке программирования, разве не является програмной системой?
Тогда разработчика AnyLogic легче, и не нужно все в безопасный Си разбирать обратно.
Ошибки там в принципе не должны быть это же математика. 2+2 равно 4, а не как не 5
AnyLogic тоже генирирует код Си из расчетных схем?
Вот программист и думает в виде расчетных схемы SimInTech и объектов проекта. Хотя в случае АЭС это даже не програмист, а технолог. А программист вообще не нужен.
Меня вообще не учили ООП, программированию меня учили в рамках базового первого курса, чисто решение расчетных задач, циклы, интерполяция, интегрирование. Я по образованию инженер конструктор ядерных реакторов, поэтому не могу иметь притензии к своему ВУЗу. ООП я изучал сам, разрабатывая нативные компоненты к Delphi, в качестве источника данных был пользовательсткий мануал на английском языке. Можт я что то там не так понял, но если обратится к английской википедии, то они так же начинают определение ООП, как объединение данных и методов их обработки, а значит не такая уж это ересь, по мнению большинства англоязычных пользователей wi-ki:
Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects», which can contain data, in the form of fields (often known as attributes), and code, in the form of procedures (often known as methods). A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated (objects have a notion of «this» or «self»). In OOP, computer programs are designed by making them out of objects that interact with one another.[1][2] OOP languages are diverse, but the most popular ones are class-based, meaning that objects are instances of classes, which also determine their types.
en.wikipedia.org/wiki/Object-oriented_programming
Здесь «метод класса» в терминах ООП, это схема внутри блока. В этой схеме можно реализовать любую логику обработки. Сама схема привязана к конкретному наименованному набору данных. Инкапсуляция — блок содержит схемы и набор данных.
Из приведенной схемы управления SimInTech, можно сгенерировать и ST. ООП в графическом языке SimInTech, а код сгенерируем ST.
В системах управления как правило все занчительно проще, с точки зрения типов:
На вход идет число — значение с датчика, на выход тоже число — команда упрвления, все число, даже если это логическое да или нет 0,1. Для упрощения можно считать что все числа — реальные двойной точности.
А «идеи возникшие позже», это разные схемы обработки этих чисел.
Тут дело в том, что схему алгоритма можно запустить на исполнение без генерации года Си. Графический язык SimInTech может выполнять расчеты, сам по себе. А IDE Delphi все переводит в ОО Паскаль, а потом только компилирует и выполняет. Как то так.
И еще, в IDE Delphi функции все таки нужно писать на Паскале. А в графическом языке — не надо, можно все нарисовать.
Я так полагаю, что раз встроенных механизьмов реализции методоллогии ООП нет в С, а нужно делать из костылей и велосипедов, то это не ООП. А если стандратные средства поддерживают методологию ООП из коробки, то ООП. Наверное так как то, но это не точно ;)
С точки зрения пользователя СFront это ООП, а С — нет.
В стандарте MЭК 60880 «Атомные станции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А». Используется понятие
Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
В этом же стандарте есть понятие
Автоматизированная генерация кода (automated code generation): функция автоматизированных инструментов, позволяющая преобразовывать проблемно-ориентированный язык в форму, пригодную для компиляции или выполнения.
Таким образом схему графического языка SimInTech вполне можно рассматривать как программу на проблемно ориентированном языке. (графическом языке программирования)

Information

Rating
2-nd
Location
Москва, Москва и Московская обл., Россия
Registered
Activity