"Телепорты" они же блоки переноса позволяют выполнить структурирование модели. А для того, чтобы они не мешались в кучу при выполнении копирования \ вставки были придуманы и в Simulink и в SimInTech способы ограничения видимости переноса. В SimInTech это сделано при помощи задания уровня видимости прямо в имени блока переноса в формате количество_уровней_видимости_вверх#имя_переноса ,ну и ещё была сделана возможность динамического именования переносов с привязкой к произвольному параметру в формате {имя_сторокой_переменной_которую_формируем_скриптом_вышестоящего уровня} . Соответственно сейчас соединять что-то с чем-то можно практически как угодно, что и используется в некоторых библиотеках блоков. Шины тоже есть. Для наших потребителей при разработке моделей ядерных энергоустановок графический структурный способ спецификации систем является основным на 99%, а иначе там крупномасштабные модели просто делать невозможно.
Как правило при разработке моделей динамики технических систем применяют и графическую и текстовую спецификацию систем. Задачей графической спецификации является дать возможность предметному пользователю задать структуру системы. Задачей текстовой спецификации как правило является задание системы уравнений, описывающей поведение отдельного структурного элемента системы. У нас в нашей системе SimInTech в принципе вот как-то так и есть. По поводу сложности рефакторинга: вложенная упаковка структур с хранением содержимого в отдельных файлах + возможность синхронизации параметров по шаблону проблему неплохо решает, мы так переживали несколько глобальных переездов для некоторых библиотек блоков при обновлении структур без потери связности моделей. Любой графической спецификации можно сопоставить текстовую (наоборот тоже можно с некоторыми ограничениями). В принципе вообще существует два основных подхода: 1. Структурный (Simulink, SimInTech и некоторые другие отраслевые системы моделирования) 2. Языковой (Modelica, Julia, LISMA ). Они друг другу не противоречат и дополняют.
Ага. Приходит такой айтишник заниматься модным машинным обучением, начинает копаться и обнаруживает чуть ниже питона FORTRAN (иногда даже 77й) и кучу математических библиотек родом из 70х.
Начальный рост связан с установкой начальных условий в модели в первую очередь. В помещении рост температуры может продолжаться за счет остывания батарей постепенного даже при выключенном котле. Причем это зависит от того сколько тепла через окна и стены уходит.
Гистерезис для бойлера выбран 53... 56, можно и другой настроить пошире. Но с такими настройками котел включается редко.
Это сделать тоже можно. При нагреве бойлера в нем за счет тепловой инерции котла температура доходит до 58 в пиках. 70 многовато для того котла будет.
Нет, не синхронно. В модели регулятора это все видно: при переключении в режим нагрева бойлера включается насос, потом через 30 сек котел. При выключении котла он гасится, потом остановка насоса через 5 минут. При работе отопления насос включается за 120 секунд до включения котла, и выключается после выключения котла через час (если не будет команды на повторное включение). На графиках масштаб времени большой просто. Посмотреть и покрутить модель в текущей версии можно вместе с демо примером в дистрибутиве программы.
Оно включается не часто и в точность укладывается. Основной фактор при этом это максимально допустимая температура на выходе котла в режиме нагрева бойлера - она задана у меня 67 градусов, обратно включается при достижении 63 градусов.
Байпас не управляемый, в модели он есть для проверки режима естественной циркуляции. Две задвижки рядом - это на самом деле один трехходовой клапан, просто он так моделируется. Еще две задвижки справа - это имитация смесителя в ванной. Температура контролируется на выходе котла, на выходе бойлера, на выходе системы отопления, в помещении и на улице. Управление идет включением котла и трёхходовым клапаном. Насос рециркуляции гвс всегда включён (хотя можно было бы и ночью выключать).
Используемый подход обусловлен, тем что менять все трубы и котел по дому было дорого и неохота, а обеспечить себя стабильным отоплением и горячей водой нужно. В принципе да самое сложное было это сантехнические работы и как раз смысл был в том, чтобы их было минимальное количество: на месте старого циркуляционника был собран насосно смесительный узел и был выполнен отвод от выхода котла. Все обошлось без сварочных работ по металлу. Моделирование было нужно для оценки будет ли система после модернизации работать как надо. Нестандартный контроллер - опять же потому что система нестандартная. Главное что оно работает сейчас как надо: топит с заданной точностью и воду греет до нужной температуры. В данном конкретном случае задача повышения комфорта была решена.
Ну учитывая, что я являюсь основным автором графической оболочки, ядра автоматики и кодогенератора мне для самого себя по своей же нужде в отпуске написать за час шаблон кода проблемой не является. Да и вообще в Simintech написать новый шаблон кода проблем никаких нет. В модели регулятора там не один интегратор и проще было естественно все посчитать имеющимся под рукой обкатанным инструментом. К слову: моделирование спирто-водяной смеси с неконденсирующимися газами и примесями - это прямой путь к нефтехимии, где есть большая потребность импортозаместить некоторые западные программы.
Это моя дача в г. Раменское. Таки да купленная на зарплату полученную с продажи софта. Дом не новый, котел в нем - старая thermona pb 25 и регистры из труб вместо батарей. Задача была не меняя весь контур и котел обеспечить горячую воду и автоматическое управление котлом и желательно подешевле, но с возможностью модернизации. Соответственно был добавлен трехходовой клапан с приводом и косвенник + соответствующая арматура. Под это все я нагородил блок управления и для того, чтобы посмотреть как оно вообще работать будет сначала провел моделирование, потом сделал шаблон для esp и туда залил код. На самом деле тяжелее всего было арматуру поставить. А дольше всего было ждать запчасти с Алика - у нас были перебои с почтой из-за увольнения сотрудников на почтамте.
Включите в графике опцию использования ступенчатой интерполяции и будут строго вертикальные. А вообще при постоянном шаге интегрирования время когда меандр равен например 0 и время когда он стал например 1 отличается как раз на этот самый шаг интегрирования. При этом если включить метод с переменным шагом и опцию учета формы для источников в настройках то можно снизить шаг в момент переключения меандра до заданного минимума.
Интегратор является линейным звеном поэтому на входе его умножать или на выходе значения не имеет. Ограничение выполняется не просто по выходу а по переменной состояния, что есть правильно. В симулинке был косяк когда делали именно ограничение чисто выхода интегратора и получалось, что когда переменная состояния там не ограничивалась и например при постоянном входном воздействии он выходил на ограничение, но при этом накопление все равно шло. Из за этого там при смене входного воздействия на обратное возникала задержка которой быть не должно. Основное назначение блока интегратора с ограничениями это имитация приводов имеющих конечное положение (например привод клапана с концевыми выключателями) - вот собственно у нас он как положено так и работает.
В SimInTech библиотека "Конечные автоматы" сделана на основе такой штуки как субмодель с условным выполнением - это в чём-то более общая концепция (потому что выполнять одновременно можно и несколько моделей сразу). Смысл именно такой реализации был в том, чтобы обеспечить возможность задания внутренней структуры каждого состояния в виде структурной схемы (и соответственно использовать имеющийся набор вычислительных блоков) и обеспечить сортировку модели до её исполнения, чтобы: 1. исключить неявно заданные алгебраические петли. 2. минимизировать задержки на шаг расчёта. 3. совместить всё с моделью в виде сигнального графа (входо-выходной блочной диаграммой, это основной способ задания моделей для реакторного АСУТП). Т.е. по сути в данной библиотеке используется расширение понятия структурной схемы за счёт усовершенствованной сортировки и переменной структуры, которое позволяет задавать карту состояний.
Вот в этих статьях мы делали сравнение с "ручным" расчётом и с моделью в SimInTech как раз в таком виде и оно у нас совпало:
Шорников Ю. В., Тимофеев К. А. "Событийно-дискретные модели управления движением", Автометрия. Т. 60, № 2. С. 119-127. DOI: 10.15372/AUT20240214. EDN: LTWEUQ
А так вообще если операции внутри состояния не в виде структурной схемы задавать, а в виде текста во встроенном языке программирования есть оператор case.
Ну вот по этой причине сейчас динамическая модель, включая модель АСУТП делается до воплощения станции в железе. А потом после корректируется по ходу реализации проекта.
Ну тут в модели дело у тебя. Тут таймер сбросить надо при выходе по другому событию. Для этого поставь у него на входе блок И и на него сигнал cold заведи. Ну или сейчас можно поставить блок вывода флага входа в состояние и по входу сбросить. Или таймер из сумматора собери.
Мы для немцев из GRS делали работу по использованию simintech для генерации входных файлов для кода athlet и его подсистемы gcsm. У них тогда тоже импортозамещение начальство попросило и мы сделалали версию системы для open suse linux. В результате вся эта деятельность вылилась в то, что описано на Хабре в статье про портирование сложного модульного по на Линукс. Т.е. когда нас заставили поддерживать нативно наши ос мы к этому были готовы.
Ну это вы спросите у заказчиков проекта, почему в итоге оно не пошло в работу (они посчитали что экономии не будет особой на оптимизации вентиляции). А мы как исполнители сделали модель, получили результат и получили за это свою денежку. Это всё вообще в основном один человек делал, ну и я сделал прототип модели, чтобы её можно было масштабировать хорошо. Зато по итогам распараллелили свой теплогидравлический код.
У нас в 3В Сервис из разработчиков нашей системы SimInTech программистов по образованию нет: все инженеры, по ядерным энергоустановкам, баллистике, робототехнике. И людей учить в основном приходится нам лично. Интересно, приходят ли к вам люди с хоть более менее профильной подготовкой после ВУЗа?
"Телепорты" они же блоки переноса позволяют выполнить структурирование модели. А для того, чтобы они не мешались в кучу при выполнении копирования \ вставки были придуманы и в Simulink и в SimInTech способы ограничения видимости переноса. В SimInTech это сделано при помощи задания уровня видимости прямо в имени блока переноса в формате количество_уровней_видимости_вверх#имя_переноса ,ну и ещё была сделана возможность динамического именования переносов с привязкой к произвольному параметру в формате {имя_сторокой_переменной_которую_формируем_скриптом_вышестоящего уровня} . Соответственно сейчас соединять что-то с чем-то можно практически как угодно, что и используется в некоторых библиотеках блоков. Шины тоже есть. Для наших потребителей при разработке моделей ядерных энергоустановок графический структурный способ спецификации систем является основным на 99%, а иначе там крупномасштабные модели просто делать невозможно.
Как правило при разработке моделей динамики технических систем применяют и графическую и текстовую спецификацию систем. Задачей графической спецификации является дать возможность предметному пользователю задать структуру системы. Задачей текстовой спецификации как правило является задание системы уравнений, описывающей поведение отдельного структурного элемента системы. У нас в нашей системе SimInTech в принципе вот как-то так и есть. По поводу сложности рефакторинга: вложенная упаковка структур с хранением содержимого в отдельных файлах + возможность синхронизации параметров по шаблону проблему неплохо решает, мы так переживали несколько глобальных переездов для некоторых библиотек блоков при обновлении структур без потери связности моделей. Любой графической спецификации можно сопоставить текстовую (наоборот тоже можно с некоторыми ограничениями). В принципе вообще существует два основных подхода: 1. Структурный (Simulink, SimInTech и некоторые другие отраслевые системы моделирования) 2. Языковой (Modelica, Julia, LISMA ). Они друг другу не противоречат и дополняют.
Ага. Приходит такой айтишник заниматься модным машинным обучением, начинает копаться и обнаруживает чуть ниже питона FORTRAN (иногда даже 77й) и кучу математических библиотек родом из 70х.
Небольшая ремарка по поводу частоты включений: до модернизации когда котел работал чисто по внутреннему термостату он включался у меня чаще.
Начальный рост связан с установкой начальных условий в модели в первую очередь. В помещении рост температуры может продолжаться за счет остывания батарей постепенного даже при выключенном котле. Причем это зависит от того сколько тепла через окна и стены уходит.
Гистерезис для бойлера выбран 53... 56, можно и другой настроить пошире. Но с такими настройками котел включается редко.
Это сделать тоже можно. При нагреве бойлера в нем за счет тепловой инерции котла температура доходит до 58 в пиках. 70 многовато для того котла будет.
Нет, не синхронно. В модели регулятора это все видно: при переключении в режим нагрева бойлера включается насос, потом через 30 сек котел. При выключении котла он гасится, потом остановка насоса через 5 минут. При работе отопления насос включается за 120 секунд до включения котла, и выключается после выключения котла через час (если не будет команды на повторное включение). На графиках масштаб времени большой просто. Посмотреть и покрутить модель в текущей версии можно вместе с демо примером в дистрибутиве программы.
Оно включается не часто и в точность укладывается. Основной фактор при этом это максимально допустимая температура на выходе котла в режиме нагрева бойлера - она задана у меня 67 градусов, обратно включается при достижении 63 градусов.
Байпас не управляемый, в модели он есть для проверки режима естественной циркуляции. Две задвижки рядом - это на самом деле один трехходовой клапан, просто он так моделируется. Еще две задвижки справа - это имитация смесителя в ванной. Температура контролируется на выходе котла, на выходе бойлера, на выходе системы отопления, в помещении и на улице. Управление идет включением котла и трёхходовым клапаном. Насос рециркуляции гвс всегда включён (хотя можно было бы и ночью выключать).
Используемый подход обусловлен, тем что менять все трубы и котел по дому было дорого и неохота, а обеспечить себя стабильным отоплением и горячей водой нужно. В принципе да самое сложное было это сантехнические работы и как раз смысл был в том, чтобы их было минимальное количество: на месте старого циркуляционника был собран насосно смесительный узел и был выполнен отвод от выхода котла. Все обошлось без сварочных работ по металлу. Моделирование было нужно для оценки будет ли система после модернизации работать как надо. Нестандартный контроллер - опять же потому что система нестандартная. Главное что оно работает сейчас как надо: топит с заданной точностью и воду греет до нужной температуры. В данном конкретном случае задача повышения комфорта была решена.
Ну учитывая, что я являюсь основным автором графической оболочки, ядра автоматики и кодогенератора мне для самого себя по своей же нужде в отпуске написать за час шаблон кода проблемой не является. Да и вообще в Simintech написать новый шаблон кода проблем никаких нет. В модели регулятора там не один интегратор и проще было естественно все посчитать имеющимся под рукой обкатанным инструментом. К слову: моделирование спирто-водяной смеси с неконденсирующимися газами и примесями - это прямой путь к нефтехимии, где есть большая потребность импортозаместить некоторые западные программы.
Это моя дача в г. Раменское. Таки да купленная на зарплату полученную с продажи софта. Дом не новый, котел в нем - старая thermona pb 25 и регистры из труб вместо батарей. Задача была не меняя весь контур и котел обеспечить горячую воду и автоматическое управление котлом и желательно подешевле, но с возможностью модернизации. Соответственно был добавлен трехходовой клапан с приводом и косвенник + соответствующая арматура. Под это все я нагородил блок управления и для того, чтобы посмотреть как оно вообще работать будет сначала провел моделирование, потом сделал шаблон для esp и туда залил код. На самом деле тяжелее всего было арматуру поставить. А дольше всего было ждать запчасти с Алика - у нас были перебои с почтой из-за увольнения сотрудников на почтамте.
Включите в графике опцию использования ступенчатой интерполяции и будут строго вертикальные. А вообще при постоянном шаге интегрирования время когда меандр равен например 0 и время когда он стал например 1 отличается как раз на этот самый шаг интегрирования. При этом если включить метод с переменным шагом и опцию учета формы для источников в настройках то можно снизить шаг в момент переключения меандра до заданного минимума.
Интегратор является линейным звеном поэтому на входе его умножать или на выходе значения не имеет. Ограничение выполняется не просто по выходу а по переменной состояния, что есть правильно. В симулинке был косяк когда делали именно ограничение чисто выхода интегратора и получалось, что когда переменная состояния там не ограничивалась и например при постоянном входном воздействии он выходил на ограничение, но при этом накопление все равно шло. Из за этого там при смене входного воздействия на обратное возникала задержка которой быть не должно. Основное назначение блока интегратора с ограничениями это имитация приводов имеющих конечное положение (например привод клапана с концевыми выключателями) - вот собственно у нас он как положено так и работает.
В SimInTech библиотека "Конечные автоматы" сделана на основе такой штуки как субмодель с условным выполнением - это в чём-то более общая концепция (потому что выполнять одновременно можно и несколько моделей сразу). Смысл именно такой реализации был в том, чтобы обеспечить возможность задания внутренней структуры каждого состояния в виде структурной схемы (и соответственно использовать имеющийся набор вычислительных блоков) и обеспечить сортировку модели до её исполнения, чтобы: 1. исключить неявно заданные алгебраические петли. 2. минимизировать задержки на шаг расчёта. 3. совместить всё с моделью в виде сигнального графа (входо-выходной блочной диаграммой, это основной способ задания моделей для реакторного АСУТП). Т.е. по сути в данной библиотеке используется расширение понятия структурной схемы за счёт усовершенствованной сортировки и переменной структуры, которое позволяет задавать карту состояний.
Вот в этих статьях мы делали сравнение с "ручным" расчётом и с моделью в SimInTech как раз в таком виде и оно у нас совпало:
Шорников Ю. В., Тимофеев К. А. "Событийно-дискретные модели управления движением",
Автометрия. Т. 60, № 2. С. 119-127. DOI: 10.15372/AUT20240214. EDN: LTWEUQ
https://www.elibrary.ru/item.asp?id=65660464
Y.V. Shornikov, K.A. Timofeev, Event-Discrete Traffic Control Models. Optoelectron.Instrument.Proc. 60, 276–283 (2024).
https://doi.org/10.3103/S875669902470033X
А так вообще если операции внутри состояния не в виде структурной схемы задавать, а в виде текста во встроенном языке программирования есть оператор case.
Ну вот по этой причине сейчас динамическая модель, включая модель АСУТП делается до воплощения станции в железе. А потом после корректируется по ходу реализации проекта.
Немцы жмоты.
Ну тут в модели дело у тебя. Тут таймер сбросить надо при выходе по другому событию. Для этого поставь у него на входе блок И и на него сигнал cold заведи. Ну или сейчас можно поставить блок вывода флага входа в состояние и по входу сбросить. Или таймер из сумматора собери.
Мы для немцев из GRS делали работу по использованию simintech для генерации входных файлов для кода athlet и его подсистемы gcsm. У них тогда тоже импортозамещение начальство попросило и мы сделалали версию системы для open suse linux. В результате вся эта деятельность вылилась в то, что описано на Хабре в статье про портирование сложного модульного по на Линукс. Т.е. когда нас заставили поддерживать нативно наши ос мы к этому были готовы.
Я гляну уточню.
Ну это вы спросите у заказчиков проекта, почему в итоге оно не пошло в работу (они посчитали что экономии не будет особой на оптимизации вентиляции). А мы как исполнители сделали модель, получили результат и получили за это свою денежку. Это всё вообще в основном один человек делал, ну и я сделал прототип модели, чтобы её можно было масштабировать хорошо. Зато по итогам распараллелили свой теплогидравлический код.
У нас в 3В Сервис из разработчиков нашей системы SimInTech программистов по образованию нет: все инженеры, по ядерным энергоустановкам, баллистике, робототехнике. И людей учить в основном приходится нам лично. Интересно, приходят ли к вам люди с хоть более менее профильной подготовкой после ВУЗа?
Сейчас мне отдадут все последние разработки по каталогу и я всё выложу
Ну вообще да, надо бы на сайт новости класть нам почаще.