Pull to refresh
81
6.8
Вячеслав @petuhoff

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

Send message

Так нормальная подрядная организация так и должна работать, сегодня нефтезавод, завтра автоматизации серных ванн в санатории, после завтра очистные сооружения в городе. Там и там трубы задвижки контроллеры и шкафы управления и даже датчики температуры, давления и расхода. Только течет среда разная нефть, миниралка и моча. Какая разница?

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

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

Фотофакт. Провел генерацию кода СИ из скрипа для выражения for (i=1,10) u = u + i; результат:

/* Index=0
   UID=0
   GeneratorClassName=TLanguage
   Name=LangBlock22
   Type=Язык программирования */

l_start_dv0:;
state_vars->dv0i_=(1);
state_vars->dv0i_=(1);
dv0___2:
if(state_vars->dv0i_ > (10))
goto dv0___5;
state_vars->dv0u_=(state_vars->dv0u_+state_vars->dv0i_);
state_vars->dv0i_ = state_vars->dv0i_ + 1;
goto dv0___2;
dv0___5:
;

Для выражения for (i=1,10, 1) u = u + i; результат

{
/* Index=0
   UID=0
   GeneratorClassName=TLanguage
   Name=LangBlock22
   Type=Язык программирования */

l_start_d1v0:;
state_vars->d1v0i_=(1);
state_vars->d1v0i_=(1);
d1v0___2:
if(((1) >= 0)&&(state_vars->d1v0i_ > (10))) {
goto d1v0___5;
} else {
if(((1) < 0)&&(state_vars->d1v0i_ < (10)))
goto d1v0___5;
};
state_vars->d1v0u_=(state_vars->d1v0u_+state_vars->d1v0i_);
if((1) != 0){
state_vars->d1v0i_ = state_vars->d1v0i_ + (1);
goto d1v0___2;
};
d1v0___5:
;
}

Изменяя выражение с помощью синтаксического сахара мы меняем кода СИ который гененрируется из скрипта но для пользователя очевидно что

for (i=1, 10) u = u + i; - проще записать (меньше символов)

for (i=1, 10, 1) u = u + i; - иногда легче прочитать, если в тексте часто используются циклы не с целым инкрементом например если у меня по тексту for (i=1, 10, 0.5)..., for (i=1, 10, 0.1)...., for (i= 0, -10, -0.1).... потом вдуруг for (i = 1 , 5)... то глаз будет спотыкатся и мозг напрягаться, я в этом случае для едионобразия я запишу полную форму for (i=1, 5, 1)... И получу разный код для контроллера. И поведение программы изменится

Понятие ситаскический сахар относится исключительно к описанию алгоритма на языке программирования.

Вот например цикл в SimInTech:

for (i=1,10) s=s+i^2; - цикл от 1 до 10, поскольку шаг не указан внутри будет использоватся стандартное инкрементирования на 1,

for (i=1,10,1) s=s+i^2; - тот же цикл с указание шага, будет добавлено выражение сложение с шагом;

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

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

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

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

Как правило на объект где используется такой софт для управления сложными объектами ездит Технолог и программист и они договариватся на месте.

У нас был реальный случай когдавнедерия SimInTech, программистов брать на объект перестали, потому что технолог сам правил диаграмму и заливал в стойки управления.

Вы не поврите в 1998 году, я на практике в Смоленском учбно тренировочном центре АЭС в качестве работы написал учебное пособие “Реактор РБМК как чайник для чайников”. Вот же были времена, студент мог пойти и ознакомится с любыми чертежами АЭС, а потом еще выложит это все в интернет.  До сих пор лежит, на народе https://reactors.narod.ru/rbmk/index.htm  Сейчас приходя к заказчику, у которого стоит модель, созданная в нашем ПО, мене запрещают фотографировать, хотя она у меня на компьютере есть.

Но тут нет ничего секртетного это же просто регулятор ПИД, просто обвешаный дополнительной логикой и проверками.

 На самом деле оказывается 5 языков и лишь дав из которы текстовые, прочем один из текстовых устарел и не входит в последнюю редакции:

FBD (Function Block Diagram) — графический язык программирования стандарта МЭК 61131-3. Предназначен для программирования программируемых логических контроллеров (ПЛК)

LD (Ladder diagram) — язык релейно-контактной логики.

SFC (Sequential Function Chart) - Последовательностные функциональные диаграммы.

Я вот не увидел ни грамма сложности в ваших схемах ПИДов. Они ОБЪЕКТИВНО НЕ СЛОЖНЫЕ - несколько однотипных блоков, простые операции да соединения. Пройтись по ним с карандашиком и прикинуть логику работы сможет и школьник.

Правильно, именно для этого и создан язык FBD диаграмм, что бы даже школьник мог пройтись с карандашиком и понять логику работы. И сложное становится понятным даже школьнику. Напиши эту логку работы в коде и даже сам разработчик лет через 5 не сможет пнять, кто этот бред написал.

У меня есть личный пример из внедрения, когда в тренажере на объекте у заказчика, логика работы правится коде, поскольку там на месте не средства разработки (и происходит это в Индии). Возратившись обратно разработчик правит диаграммы из которых код генерится автоматически. Я когда увидел удивился:

- А зачем ты правишь эти диаграммы, ты же говорили, что вы уже там на месте в коде все поправили и режим уже работает?

- Да, просто через пол-года или год, опять поедем и я не вспомню что я там руками закодировал. А здесь наглядно и понятно.

Но при этом я совершенно не могу найти в них потенциальные ошибки: например - бесконечные циклы без выхода или блоки, которые никогда не сработают. Такие вещи МНЕ ЛИЧНО гораздо быстрее и понятнее было бы искать в текстовом коде.

Поскльку это FBD диаграмма, то она работает с заданным тактом постоянно по сути это изображение работы одного шага вход получили, прогнали по схеме - получили выход и так пока контроллер работает. Поэтому если на схеме замкнуть связь, то выйдет предупреждение об алгебраической петле. Блоков которые никода не сработают то же нет. Каждый блок выполняется на каждом шаге, (если это не автомат состояний но там даже нотация отличается). Возможна ситуация когда ключ всегда имеет один и тот же выход и логика обработки никогда не применится и мы будем иметь на каждом шаге одно и тоже состояние, но это не критическая ошибка, просто лишние вычисления. При этом такие ошибки логики могут обнаруживатся как канрандашом, так и путем моделирования.

Мне кажется тут проблема вот в чем, то что вам ЛИЧНО легче и быстрее найти ошибке в текстовом виде, как многим программистам (хотя я думаю, искать ошибки всем проще в диаграмме, другое дело писать в виде текста код гораздо быстрее). Для отладки сложных систем, нужен не только и не столько программист, а технолог процесса. Если у меня алгоритм управления ядреным, тепловым или химическим процессом, то абсолютно правильная без бескончных циклов, всегда работающим блоками программа, это не совсем не то что надо. В первую очередь мне надо, что бы программа поддерживала параметры рабочего процесса, и правильно реагировала на отклонения. А здесь нужны занания не кодов, циклов и регулярных выражения, а физики, химии, конструкции и процессов.

Из последнего смешного. АЭС отваливатся по аврийной защите. Гигаваты мощность, куча денег потеряно. Оказывается сработала защита по повышению температуры в подшибнике подпятника главного циркуляционного насоса. Программа сработала иделаьно из без ошибок. Если температура превышена занчит проблемы с подшипником, нужно его выключать. В тексте все правильно и в диаграмее тоже было все правильно. Просто при штатном отключении насоса вал замедляется и перед полной остановкой, пленка масла исчезает и подшипник греется выше температуры уставки. Без знания этого процесса, написать и проверть программу, что в тексте, что в диаграмме невозможно. А поскольку знаниям о процессах обладают технологи, а не программисты, то для них и сделали язык FBD диаграмм, что мы с карандашиком пройтись и проверит.

И с гит интеграция есть прямо в среде

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

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

Графические схемы подходят для небольших линейных моделей, типа тех, которые вы показали. Попробуйте нарисовать на графической диаграмме, скажем, регулярное выражение. Или там - виртуальные конструкторы какие-нибудь. А после того, как нарисовали - попробуйте туда ещё правки вносить регулярно... Не уверен, что вы долго продержитесь 😁

Небольшие линейные модели в статье показаны, как пример модификации диаграмы для удобства читателя. Просто если взять натоящий ПИД регулятор, которые реально используется в ПО для управления АЭС, на него без подготовки, слабонервным, беременным женьщьнам и кормящим матерям лучше не смотреть. Например ПИД реальный с АЭС выглядит так:

ПИД в реальной АЭС
ПИД в реальной АЭС

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

Реуглятор температуры реальный
Реуглятор температуры реальный

Сравните с рисуноком 4 и почувствуйте разницу. И подобных листов в проекте ПО тысячи. Все это автоматической генерацией кода заливается в стойки управления АЭС и управляет ядерным реактором на Гигаваты мощности. После Чернобыля писать код руками и читать его стало как то стремена. А тут ничего работает модифицируется и поддерживается. Чернобыль вроде мы не повторяли. Вот например видео с простой модли системы управления ледоколом. Там одна система Шквал содержит 800 листов алгоритмов. И поддерживается и правки вносятся регулярно, поскольку это реально проектирующая организация и они постоянно дорабатывают проект. И ледоколы плавают.

Так что для меня вопрос како ПО более сложное, написаное на фремворках алфавитным язком СРМ или ПО для управления ядерным реактором с турбиной. Просто цена ошибки в СРМ, наверное меньше чем цена ошибки в САУ реакторного отделения. И тут графические языки выходят на первый план. Даже в стандарте МЭК 61131-3, половина языков - графическая

Если говорить про гидравлику то в трубопроводе, расчетная сетка 1D уравнения сохраннения энергии, массы, и импульса считаются вдоль оси трубопровода. Изменения в сечении игнорируются. Уравнения 1D

Но не всегда это удобно вот пример:

Хотелось бы так: нарисовал схемку - и жмешь кнопку: "дай код js", а рядом с ней "дай код VBA". Как дальнейшее развитие BPMN, только с формированием "всего кода" из схемы.

Так оно и работает, только для кода Си. И железных платформ, выбираешь кодогенератор и говоришь дай код Си под Линукс на АРМ или кода dll под Windows 64. Или дай код для Ардуино. Там список сейчас такой: Milandr, TI, ST Schnaider Electric, Ardiunо, Gigadevice, STM32, MK17 и еще что то постоянно в доработке

выбора таргета для генерации кода из схемы
выбора таргета для генерации кода из схемы

Семантический сахар, - это когда один образ (та же схема), а на выходе - различные вариации созданной логики, т.е. разные синтаксические представления (языки программирования) одного образа из разных компонент, склеенных семантическим сахаром. Например, в части визуализации алгоритмов: разные обертки \ представления \ графические нотации Одного алгоритма, см.

Так пример на рисунках 12 и 16 это и есть разные графические нотации одной и той же логики ПИД регулятора. Если сгенерировать код Си там похоже разницы в коде не будет

Круто напопробовать соорудить такое демо в SimInTech

ну дав то графических описано? Половина получается, сейчас поправлю

Information

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