Тут самое интерсеное было бы - это анализ перекрестный наводок. Согласование дифференциальных пар конечно интересно, но не менее интересна защита от наведенных помех линий I2C (очень чувствительны), I2S, SPI, SDIO и других скоростных линий. Конечно пока пины чипа не смапированы на эти функции разработчик платы может себе позводить не думать об этом. Но если I2C начнет зависать просто потому что SCL и SDA слишком близко друг к другу или проходят под катушкой DC/DC или рядом с полигоном силового ключа. Это к тому что при тассировке модуля надо думать и о конечном приложении. Сомнительно разрабатывать модуль не зная в какой схеме точно он будет применяться.
Ну это, скажет так, просто реверсинжениринг. Хитрыми уловками вы могли просто скомпилить .exe или .dll в Simulink и представить это своим заказчикам, как результат компиляции SimInTech.
Такие вещи скриншотами не доказываются. Тут все потроха надо рассматривать под лупой. Но это не принципиально. И так видно что Simulink пока гораздо сильнее в плане отладочных инструментов и косвенно это подтверждается скоростью ваших моделей.
Этому нет подтверждения. Но здравый смысл говорит, что софт не может отличаться по быстродействию если он принципиально считает одно и тоже.
Сравните компиляторы. Там отличия на проценты. Сравните симуляторы - аналогично. Я вам даже скажу, что ваша модель атомной станции не так сложна по сравнению с моделью обычного Buck-Boost конвертера, если в нем применяют детализацию моделей транзисторов уровня L3.
Давайте я вам дам мою state machine в Similink и сделайте ее сгенерированный код в 5 раз быстрее. (это риторика, конечно вы его быстрее не сделаете, его даже вручную уже несоптимизировать)
Обратите внимание на нули в профилировщике для подблоков модели. Т.е. они считаются вообще мгновенно. Все время уходит на накладные расходы на отладочные фичи.
Словом вы не привели доказательств, да и в модели Simulink применены закрытые блоки, типа модели атмосферы, которые вы врядли могли воспроизвести один в один.
Во-первых, профилировщик сам замедляет работу модели. Покажите для начала такой же мощный профилировщик у SimInTech. Во-вторых реально модель выполняется за 2.7 сек. В третьих, есть еще отладочная информация, это тоже занимает время. И в оригинальной модели графиков гораздо больше чем у вас.
Словом если что-то моделируется в несколько раз быстрее, то ищите проблему в этой самой быстрой модели. Там наверняка будет либо меньше отладочных данных, либо меньше диагностики, либо она будет менее точная (проверьте типы данных)
А, сорри, понял в чем подвох. У вас реальное время с очень длинными тактами. Тогда вопрос снят. Приколько только что вы умудряетесь писать про системы управления и не упоминать длительность такта.
Кстати интересен вопрос выбора масштаба самого реального времени.
У нас SimInTech отмоделируюет все что движется, а что что не движется подвигает и тоже отмоделирует. :))))))
Моделировать то можно, но в HIL модель должна работать в реальном времени. Поэтому я не верю, что вы имеете модель реактора со всей тысячей клапанов работающей в реальном времени. Тема все же не раскрыта.
Simulink то хоть может откомпилировать модель и запустить на специальной RealTime платформе, а не на Windows. А ваш SimInTech чё?
А значит нам нужна такая модель, которая выдаст значения соответсвющие точностями реального измерения, в точнее не надо, система управления и программа управления все равно эту точность не получат, в качестве исходных данных, следовательно для целей тестировани HIL она избыточна
Тут запутали окончательно. Модель в HIL не про точность , а про поведение, как я понимаю эту технологию. И поведение это придумывается чисто умозрительно не опираясь ни на какой опыт. Например придумать сколько датчиков откажет и какого типа отказы будут. Будет ли это дребезг, спорадические выбросы, разрывы, утечки и смещение показаний или прочее. Вот такие сценарии в HIL и отрабатывают. При чем тут технолог? Это комбинаторная задача не уровня технолога.
Вы же не можете создать модель реактора прямо повторяющую физику реактора. Иначе бы в Чернобыле не ставили эксперименты на живом реакторе. Вы можете только моделировать переключатели и простые грубые зависимости типа звеньев второго - третьего порядка. А дальше неизвестность и эвристики.
Про колическтво листов в модели тоже не аргумент в пользу ее полноты и комплексности. Это может быть простое механическое масштабирование, когда вместо одного вентиля моделируют сотню. Вот вам и сотня листов или тысяча если рисовать, как на ваших скриншотах, заполняя все непропорционально большими блоками и рамками.
Т.е. тема адекватности моделей и принципов их создания в HIL не раскрыта.
Если бы существовали "полноценные" модели реакторов никто бы так не боялся их. Тут даже полноценных моделей асинхронных моторов сделать не могут. Потому что полноценные модели либо слишком детализированы и с их расчетом в реальном времени не справляются компьютеры, либо моделируемые системы недостаточно изучены. Неспроста появился AI. Вручную наращивать детализацию люди больше не могут. Программисты критически нужны в обоих случаях. В первом случае чтобы поддерживать модели на нужном уровне производительности и повышать её, во втором чтобы обеспечивать гибкость архитектуры модели. Ну и чтобы уже переходить на AI. Если обходятся одним технологом значит модель морально устарела.
Статью прочитать не смог, невозможный для восприятия стиль. Отдал ChatGPT на анализ. Тот ответил, что в статье утвержадется, что для построения моделей типа HIL обязательно нужен технолог. Я что-то здесь сомневаюсь. В случае HIL не будет построено адекватеной модели. Там в лучшем случае можно помоделировать разные виды аварий и неисправностей на коротких отрезках времени. Зачем там технолог? Другое дело SIL, как вот в этой статье, вот тут технолог бы пригодился со своими эвристиками. Потому что тут реально нужен прошлый опыт технолога при взаимодействии с ситемой. А зачем технолог при моделировании аварий в HIL, о которых технолог даже не подозревает и в жизни не сталкивался?
У теслы реализовано жидкостное охлаждение кабеля. И датчик температуры стоит скорее всего не на разъеме, а в начала ручки. Поскольку кабель зарядки черный, то на солнце он нагревается быстрее всего остального во время зарядки и именно в районе ручки, где нельзя ее сделать сильно блестящей. Поэтому полотенце - это очень правильный и инженерный вариант. Даже светоотражающая фольга была бы тут менее эффективной.
Написал здесь, потому что сегодня в желтой прессе мелькнула статья "можно ли вообще мыть электромобили".
Проблема не столько во Floating capacitance , а в поляризации. Обратите внимание насколько вырастает темновой ток и удерживается с удержанием разницы напряжений. И это данные для дорогих оптронов. У дешевых все гораздо хуже. А еще есть деградация светодиодов.
Все же на CA-IS3720 честно дают 100 kV/us и минимум в вдва раза больший срок службы.
У обычного 3-фазного частотника фронт 50 ns и коммутируемое напряжение около 540 V. Т.е. в частотниках постоянно есть фронты со скоростью 11 kV/us. И они через радиатор и корпус мотора гуляют по всем мелаллу вокруг.
По ходу повествования как-то забывается, что главня цель - изоляция. И вот про нюансы этой изоляции как-то не раскрыто. Создается ложное впечатление будто это идеальная изоляция. Однако если поискать по даташитам всех производителей подобных оптронов, то можно найти такие неприятные эффекты, как ограниченый CMR:
И значительный ток утечки после воздействия скачков напряжения. А ведь в пром.автоматике такие скачки норма. Интересно что в даташите EL3H7 этот эффект не упоминается. Т.е. это даже не тестируют. Я бы не покупался за 2 рубля и брал бы то что выше предложили типа CA-IS3720
Либо точнее в статье определить от чего изолируемся и зачем.
Без разминки всегда опасны. Особенно народу кому за 50. Потому вся силовуха и недоступна многим, потому что надо делать длительную разминку. Я к гирям подхожу после часа разминки. Приколько наблюдать за ЗОЖ пожилыми ютуберами, кторые иногда пропадают из эфира, а потом возвращаются и говорят "сорри, только очухался после травм". Что на нас не убивает - то нас калечит.
Это конечно интересно, когда новичок учит новичков с нуля. Но тут можно попасть в ловушку плохой архитектуры, которая не даст потом уйти дальше двух кнопочек. Посмотрите как сделано в airoc-connect-android. Там BluetoothManager создается в отдельном сервисе. Списки в отдельных фрагментах. Сканирование в отдельных потоках. Из-за плохой архитектуры вам придется все время рефакторить свой код на выском уровне организации лайаутов и классов. Новички за такое спасибо не скажут. Полезнее было бы выложить готовое приложение и уже его объяснять.
А не рассматривали для создания своего приложения просто рефакторинг завершенных приложений типа airoc-connect-android? Там есть вся инфраструктура. И сканирование, и чтение базы GATT, и чтение и запись аттрибутов и пайринг и бондинг. И меню вспомогательные и панели с настройкой параметров. A ChatGPT отлично разбирается во всех нюансах и IDE и языка и библиотек. Весь поток разработки подробно опишет.
Прикольно, что в Android Studio встроен ИИ под название Gemini и он проанализировав airoc-connect-android сказал, что это приложение заказа еды из ресторана. Так что на Gemini я бы надежд не возлагал в изучении проектов.
Такие вентиляторы гарантировано выходят из строя каждый год-два. Каждый раз встривать в них электронику мало смысла. Если только она не будет собирать статистику для ИИ и потом искать корреляции чтобы чуть чуть там сэкономить на электроэнергии и узнать наконец почему они так часто перегорают.
У всех соседей в доме будут стоять точно такие вентиляторы и они будут включены круглые сутки, потому что если их выключить, то возникнет обратный поток воздуха. Тут скорее более важно организовать надежные управляемые клапана для предотвращения обратного потока.
С Avalonia вижу проблему с IDE. Если это просто расширение к VS то будет криво и косо и критически зависеть от качества портирования .NET на конкретном одноплатнике. А в той среде про портирование .NET никто даже не в курсе. А вот отладкчик Android Studio покроет все недостатки понимания его планировщика.
Если открыть сам Visual Studio, том есть много разных вариантов как писать на C# для платформ с Linux и Android. Можно консольного типа приложение писать, как в статье, можно делать Blazor Web App (на Rasperry Pi такое есть), можно делать с использованием .NET MAUI (надо искать подходящий одноплатник). Тут бы анализ не помешал этих вариантов. Но консольное приложение видится худшим из них. Тогда уже лучше Arduino взять.
Но я бы выбрал писать на Java или на C++ под Android в Android Studio. Поскольку будет развитое GUI и главное - мощный отладчик. Поскольку при наличии GPT не важно на каком языке писать. А в качестве одноплатника выбрал бы Banana PI BPI-M5, а не Orange. Поскольку для Banana есть данный момент поддерживаемый Андроид, а для Orange нет.
Тут самое интерсеное было бы - это анализ перекрестный наводок.
Согласование дифференциальных пар конечно интересно, но не менее интересна защита от наведенных помех линий I2C (очень чувствительны), I2S, SPI, SDIO и других скоростных линий. Конечно пока пины чипа не смапированы на эти функции разработчик платы может себе позводить не думать об этом. Но если I2C начнет зависать просто потому что SCL и SDA слишком близко друг к другу или проходят под катушкой DC/DC или рядом с полигоном силового ключа.
Это к тому что при тассировке модуля надо думать и о конечном приложении. Сомнительно разрабатывать модуль не зная в какой схеме точно он будет применяться.
Нет ничего проще. Вот рабочая внедренная в микроконтроллер модель обслуживающая механизм:
Просто сделайте мне из нее исходник на C чтобы он работал быстрее того что сдел Simulink
У модели очень простой интерфейс:
https://drive.google.com/file/d/1JOoBkd7V4P9H1Py4P1usFjJjHu4mh2Df/view?usp=sharing
Ну это, скажет так, просто реверсинжениринг.
Хитрыми уловками вы могли просто скомпилить .exe или .dll в Simulink и представить это своим заказчикам, как результат компиляции SimInTech.
Такие вещи скриншотами не доказываются. Тут все потроха надо рассматривать под лупой. Но это не принципиально. И так видно что Simulink пока гораздо сильнее в плане отладочных инструментов и косвенно это подтверждается скоростью ваших моделей.
Этому нет подтверждения. Но здравый смысл говорит, что софт не может отличаться по быстродействию если он принципиально считает одно и тоже.
Сравните компиляторы. Там отличия на проценты. Сравните симуляторы - аналогично. Я вам даже скажу, что ваша модель атомной станции не так сложна по сравнению с моделью обычного Buck-Boost конвертера, если в нем применяют детализацию моделей транзисторов уровня L3.
Давайте я вам дам мою state machine в Similink и сделайте ее сгенерированный код в 5 раз быстрее. (это риторика, конечно вы его быстрее не сделаете, его даже вручную уже несоптимизировать)
Обратите внимание на нули в профилировщике для подблоков модели. Т.е. они считаются вообще мгновенно. Все время уходит на накладные расходы на отладочные фичи.
Словом вы не привели доказательств, да и в модели Simulink применены закрытые блоки, типа модели атмосферы, которые вы врядли могли воспроизвести один в один.
Это вообще не серьезно.
Во-первых, профилировщик сам замедляет работу модели. Покажите для начала такой же мощный профилировщик у SimInTech. Во-вторых реально модель выполняется за 2.7 сек. В третьих, есть еще отладочная информация, это тоже занимает время. И в оригинальной модели графиков гораздо больше чем у вас.
Словом если что-то моделируется в несколько раз быстрее, то ищите проблему в этой самой быстрой модели. Там наверняка будет либо меньше отладочных данных, либо меньше диагностики, либо она будет менее точная (проверьте типы данных)
А, сорри, понял в чем подвох. У вас реальное время с очень длинными тактами.
Тогда вопрос снят.
Приколько только что вы умудряетесь писать про системы управления и не упоминать длительность такта.
Кстати интересен вопрос выбора масштаба самого реального времени.
Моделировать то можно, но в HIL модель должна работать в реальном времени.
Поэтому я не верю, что вы имеете модель реактора со всей тысячей клапанов работающей в реальном времени.
Тема все же не раскрыта.
Simulink то хоть может откомпилировать модель и запустить на специальной RealTime платформе, а не на Windows. А ваш SimInTech чё?
Тут запутали окончательно.
Модель в HIL не про точность , а про поведение, как я понимаю эту технологию.
И поведение это придумывается чисто умозрительно не опираясь ни на какой опыт. Например придумать сколько датчиков откажет и какого типа отказы будут.
Будет ли это дребезг, спорадические выбросы, разрывы, утечки и смещение показаний или прочее. Вот такие сценарии в HIL и отрабатывают. При чем тут технолог?
Это комбинаторная задача не уровня технолога.
Вы же не можете создать модель реактора прямо повторяющую физику реактора. Иначе бы в Чернобыле не ставили эксперименты на живом реакторе. Вы можете только моделировать переключатели и простые грубые зависимости типа звеньев второго - третьего порядка. А дальше неизвестность и эвристики.
Про колическтво листов в модели тоже не аргумент в пользу ее полноты и комплексности. Это может быть простое механическое масштабирование, когда вместо одного вентиля моделируют сотню. Вот вам и сотня листов или тысяча если рисовать, как на ваших скриншотах, заполняя все непропорционально большими блоками и рамками.
Т.е. тема адекватности моделей и принципов их создания в HIL не раскрыта.
Если бы существовали "полноценные" модели реакторов никто бы так не боялся их.
Тут даже полноценных моделей асинхронных моторов сделать не могут. Потому что полноценные модели либо слишком детализированы и с их расчетом в реальном времени не справляются компьютеры, либо моделируемые системы недостаточно изучены. Неспроста появился AI. Вручную наращивать детализацию люди больше не могут.
Программисты критически нужны в обоих случаях. В первом случае чтобы поддерживать модели на нужном уровне производительности и повышать её, во втором чтобы обеспечивать гибкость архитектуры модели. Ну и чтобы уже переходить на AI.
Если обходятся одним технологом значит модель морально устарела.
Статью прочитать не смог, невозможный для восприятия стиль. Отдал ChatGPT на анализ. Тот ответил, что в статье утвержадется, что для построения моделей типа HIL обязательно нужен технолог.
Я что-то здесь сомневаюсь. В случае HIL не будет построено адекватеной модели. Там в лучшем случае можно помоделировать разные виды аварий и неисправностей на коротких отрезках времени. Зачем там технолог?
Другое дело SIL, как вот в этой статье, вот тут технолог бы пригодился со своими эвристиками. Потому что тут реально нужен прошлый опыт технолога при взаимодействии с ситемой.
А зачем технолог при моделировании аварий в HIL, о которых технолог даже не подозревает и в жизни не сталкивался?
Здесь https://habr.com/ru/articles/581468/ пример как выглядят портируемые модели на ПЛК.
У теслы реализовано жидкостное охлаждение кабеля. И датчик температуры стоит скорее всего не на разъеме, а в начала ручки.
Поскольку кабель зарядки черный, то на солнце он нагревается быстрее всего остального во время зарядки и именно в районе ручки, где нельзя ее сделать сильно блестящей.
Поэтому полотенце - это очень правильный и инженерный вариант. Даже светоотражающая фольга была бы тут менее эффективной.
Написал здесь, потому что сегодня в желтой прессе мелькнула статья "можно ли вообще мыть электромобили".
Проблема не столько во Floating capacitance , а в поляризации. Обратите внимание насколько вырастает темновой ток и удерживается с удержанием разницы напряжений. И это данные для дорогих оптронов. У дешевых все гораздо хуже.
А еще есть деградация светодиодов.
Все же на CA-IS3720 честно дают 100 kV/us и минимум в вдва раза больший срок службы.
У обычного 3-фазного частотника фронт 50 ns и коммутируемое напряжение около 540 V. Т.е. в частотниках постоянно есть фронты со скоростью 11 kV/us. И они через радиатор и корпус мотора гуляют по всем мелаллу вокруг.
По ходу повествования как-то забывается, что главня цель - изоляция. И вот про нюансы этой изоляции как-то не раскрыто. Создается ложное впечатление будто это идеальная изоляция. Однако если поискать по даташитам всех производителей подобных оптронов, то можно найти такие неприятные эффекты, как ограниченый CMR:
И значительный ток утечки после воздействия скачков напряжения. А ведь в пром.автоматике такие скачки норма.
Интересно что в даташите EL3H7 этот эффект не упоминается. Т.е. это даже не тестируют. Я бы не покупался за 2 рубля и брал бы то что выше предложили типа CA-IS3720
Либо точнее в статье определить от чего изолируемся и зачем.
Без разминки всегда опасны. Особенно народу кому за 50.
Потому вся силовуха и недоступна многим, потому что надо делать длительную разминку.
Я к гирям подхожу после часа разминки.
Приколько наблюдать за ЗОЖ пожилыми ютуберами, кторые иногда пропадают из эфира, а потом возвращаются и говорят "сорри, только очухался после травм".
Что на нас не убивает - то нас калечит.
Это конечно интересно, когда новичок учит новичков с нуля.
Но тут можно попасть в ловушку плохой архитектуры, которая не даст потом уйти дальше двух кнопочек.
Посмотрите как сделано в airoc-connect-android. Там BluetoothManager создается в отдельном сервисе. Списки в отдельных фрагментах. Сканирование в отдельных потоках.
Из-за плохой архитектуры вам придется все время рефакторить свой код на выском уровне организации лайаутов и классов.
Новички за такое спасибо не скажут.
Полезнее было бы выложить готовое приложение и уже его объяснять.
А не рассматривали для создания своего приложения просто рефакторинг завершенных приложений типа airoc-connect-android? Там есть вся инфраструктура. И сканирование, и чтение базы GATT, и чтение и запись аттрибутов и пайринг и бондинг. И меню вспомогательные и панели с настройкой параметров.
A ChatGPT отлично разбирается во всех нюансах и IDE и языка и библиотек. Весь поток разработки подробно опишет.
Прикольно, что в Android Studio встроен ИИ под название Gemini и он проанализировав airoc-connect-android сказал, что это приложение заказа еды из ресторана. Так что на Gemini я бы надежд не возлагал в изучении проектов.
Такие вентиляторы гарантировано выходят из строя каждый год-два.
Каждый раз встривать в них электронику мало смысла. Если только она не будет собирать статистику для ИИ и потом искать корреляции чтобы чуть чуть там сэкономить на электроэнергии и узнать наконец почему они так часто перегорают.
У всех соседей в доме будут стоять точно такие вентиляторы и они будут включены круглые сутки, потому что если их выключить, то возникнет обратный поток воздуха.
Тут скорее более важно организовать надежные управляемые клапана для предотвращения обратного потока.
С Avalonia вижу проблему с IDE. Если это просто расширение к VS то будет криво и косо и критически зависеть от качества портирования .NET на конкретном одноплатнике. А в той среде про портирование .NET никто даже не в курсе.
А вот отладкчик Android Studio покроет все недостатки понимания его планировщика.
Если открыть сам Visual Studio, том есть много разных вариантов как писать на C# для платформ с Linux и Android.
Можно консольного типа приложение писать, как в статье, можно делать Blazor Web App (на Rasperry Pi такое есть), можно делать с использованием .NET MAUI (надо искать подходящий одноплатник). Тут бы анализ не помешал этих вариантов. Но консольное приложение видится худшим из них. Тогда уже лучше Arduino взять.
Но я бы выбрал писать на Java или на C++ под Android в Android Studio.
Поскольку будет развитое GUI и главное - мощный отладчик. Поскольку при наличии GPT не важно на каком языке писать. А в качестве одноплатника выбрал бы Banana PI BPI-M5, а не Orange. Поскольку для Banana есть данный момент поддерживаемый Андроид, а для Orange нет.