Выходной пост, который станет продолжением про Архитектуру ППО.
Сегодня представлю, как я, в первом приближении вижу обработку входного сигнала. Предназначение ФБ входного сигнала - это получить сигнал с «модуля», провести валидацию этого сигнала, сделать минимальные преобразования и выдать его дальше. Я считаю, что на выходе сигнал должен остаться сигналом. Проще всего это объяснить на примере аналогового сигнала.
Если на вход у нас поступают значения от АЦП, а это мы будем получать либо число от 0 до 65535, либо микроампера или милливольты, что не играет роли, то и на выходе мы должны получить что-то что будет связано с сигналом. Это может быть начальное значение, которое мы просто проверили или произошло линейное преобразование в проценты от 0 до 100, но никак не готовое значение давления/расхода/уровня(нужное подчеркнуть).
За сам процесс проверки и преобразования отвечают следующие поля
Signal - забирается с «модуля». На каждый сигнал есть структура Settings, которая будет храниться в Retain памяти ПЛК и иметь возможность ее изменения пользователем.
Далее у нас идет
Control - это тоже структура, которая содержит поля, необходимые для управления ФБ обработки сигнала. Сейчас я туда отношу симуляцию и маскирование, но не уверен, что им там самое место с точки зрения безопасности технологического процесса.
Последнее поле
Состояние «модуля», которое нам необходимо для небольшого контура безопасности, чтобы не обрабатывать заведомо мусорные значение и не пустить их в технологический процесс. Тут будут все наши обрывы линии связи, ошибки протоколов и т.д.
И на выходе остается
InputDataState - структура, которая содержит в себе информацию, необходимую и достаточную для информирования пользователя о состоянии входного сигнала. Value, в свою очередь, - готовый сигнал, которые прошел преобразование, валидацию, и является безопасным для логики системы. Его мы передаем в отдельную структуру для устройства, учавствующего в технологическом процессе.
#АСУТП #ППО #ПЛК #Архитектура
"Я вам че - Автоматизатор?!"
Сегодня представлю, как я, в первом приближении вижу обработку входного сигнала. Предназначение ФБ входного сигнала - это получить сигнал с «модуля», провести валидацию этого сигнала, сделать минимальные преобразования и выдать его дальше. Я считаю, что на выходе сигнал должен остаться сигналом. Проще всего это объяснить на примере аналогового сигнала.
Если на вход у нас поступают значения от АЦП, а это мы будем получать либо число от 0 до 65535, либо микроампера или милливольты, что не играет роли, то и на выходе мы должны получить что-то что будет связано с сигналом. Это может быть начальное значение, которое мы просто проверили или произошло линейное преобразование в проценты от 0 до 100, но никак не готовое значение давления/расхода/уровня(нужное подчеркнуть).
За сам процесс проверки и преобразования отвечают следующие поля
VAR_INPUT
Signal: TYPE;
Settings: TYPE;
END_VAR;Signal - забирается с «модуля». На каждый сигнал есть структура Settings, которая будет храниться в Retain памяти ПЛК и иметь возможность ее изменения пользователем.
Далее у нас идет
VAR_INPUT
Control: TYPE;
END_VAR;Control - это тоже структура, которая содержит поля, необходимые для управления ФБ обработки сигнала. Сейчас я туда отношу симуляцию и маскирование, но не уверен, что им там самое место с точки зрения безопасности технологического процесса.
Последнее поле
VAR_INPUT
ModuleState;
END_VAR;Состояние «модуля», которое нам необходимо для небольшого контура безопасности, чтобы не обрабатывать заведомо мусорные значение и не пустить их в технологический процесс. Тут будут все наши обрывы линии связи, ошибки протоколов и т.д.
И на выходе остается
VAR_OUTPUT
InputDataState
Value
END_VAR;InputDataState - структура, которая содержит в себе информацию, необходимую и достаточную для информирования пользователя о состоянии входного сигнала. Value, в свою очередь, - готовый сигнал, которые прошел преобразование, валидацию, и является безопасным для логики системы. Его мы передаем в отдельную структуру для устройства, учавствующего в технологическом процессе.
#АСУТП #ППО #ПЛК #Архитектура
"Я вам че - Автоматизатор?!"
👍4🤔2🏆1
19–21 ноября 2025 года в Санкт-Петербурге, в рамках Российской недели роботизации-2025 состоится VII Международный форум роботизации, который представляет собой уникальную российскую площадку, демонстрирующую передовую робототехническую продукцию, системы программирования и управления высокотехнологическим оборудованием, в том числе с использованием систем искусственного интеллекта.
Место проведения: Санкт-Петербург, КЦ «ПетроКонгресс», Лодейнопольская ул., д. 5 (метро «Чкаловская»).
Формат: очный.
Посещение форума — бесплатное, обязательна предварительная регистрация на сайте.
#роботы #форум
"Я вам че - Автоматизатор?!"
Место проведения: Санкт-Петербург, КЦ «ПетроКонгресс», Лодейнопольская ул., д. 5 (метро «Чкаловская»).
Формат: очный.
Посещение форума — бесплатное, обязательна предварительная регистрация на сайте.
#роботы #форум
"Я вам че - Автоматизатор?!"
Telegram
"Я вам че - Автоматизатор?"
Об OT, новых технология и подходах в АСУТП, интересные новости из мира автоматизации и личный взгляд на все это.
Сайт: https://blog.engcore.ru/
Сотрудничество: info@engcore.ru
Сайт: https://blog.engcore.ru/
Сотрудничество: info@engcore.ru
🔥3
Давайте немного разгоним по одной теме.
Эволюция и стандартизация виртуальных ПЛК
Прошу ознакомиться с оригинальным постом и еще со статьей, а я просто вставлю свои 5 копеек.
Тут первый вопрос, а вы часто сталкивались с Docker и системой виртуализации? Запустить просто образ на локальной машине дело вполне простое, но вот написать конфиг для запуска уже сложнее, а если мы говорим про какие-нибудь pipeline, то сложность будет возрастать. В целом рекомендую ознакомиться с технологией как таковой.
Вот здесь соглашусь. Виртуальный ПЛК - это про портативность и гибкость, а также чуть больше свободы от аппаратной платформы, но мы платим за это надежностью и скоростью работы.
Docker, K8S, pipeline, ingress контролеры... Сомнительно...
Вот это, кмк, самая хорошая сторона виртуальных ПЛК - модернизация производства. И тут как раз и требуется перекидать логику на новые рельсы, чтобы отвязаться от старых решений.
А вообще мы уже с одним решением поигрались, можете ознакомиться.
Эволюция и стандартизация виртуальных ПЛК
Прошу ознакомиться с оригинальным постом и еще со статьей, а я просто вставлю свои 5 копеек.
Стандартизация образов сред выполнения. Ключевым сдвигом стало создание стандартизированных, предварительно сконфигурированных образов Docker, содержащих среду выполнения ПЛК. Это устраняет необходимость вручную настраивать операционные системы, патчи и зависимости, сокращая время развертывания и потенциальные ошибки.
Тут первый вопрос, а вы часто сталкивались с Docker и системой виртуализации? Запустить просто образ на локальной машине дело вполне простое, но вот написать конфиг для запуска уже сложнее, а если мы говорим про какие-нибудь pipeline, то сложность будет возрастать. В целом рекомендую ознакомиться с технологией как таковой.
Разделение аппаратного и программного обеспечения. Виртуальные ПЛК позволяют отделить логику управления от физического контроллера. Один и тот же проект ПЛК может быть запущен на разных вычислительных платформах — от локального сервера до облака или промышленного ПК, обеспечивая портативность и гибкость.
Вот здесь соглашусь. Виртуальный ПЛК - это про портативность и гибкость, а также чуть больше свободы от аппаратной платформы, но мы платим за это надежностью и скоростью работы.
Снижение порога входа для виртуального инжиниринга. Ранние решения требовали глубоких знаний в IT. Современные стандартизированные инструменты делают технологии виртуализации доступными для инженеров-автоматизаторов без специализированной IT-подготовки.
Docker, K8S, pipeline, ingress контролеры... Сомнительно...
Модернизация: Перенос устаревших систем управления на современные виртуальные платформы без переписывания логики.
Вот это, кмк, самая хорошая сторона виртуальных ПЛК - модернизация производства. И тут как раз и требуется перекидать логику на новые рельсы, чтобы отвязаться от старых решений.
А вообще мы уже с одним решением поигрались, можете ознакомиться.
Telegram
Канал Открытые системы автоматизации
Эволюция и стандартизация виртуальных ПЛК
Основной тезис статьи: Виртуальные ПЛК эволюционировали из инструмента для нишевых задач в стандартизированную технологию, доступную для массового применения благодаря развитию контейнеризации и унификации образов…
Основной тезис статьи: Виртуальные ПЛК эволюционировали из инструмента для нишевых задач в стандартизированную технологию, доступную для массового применения благодаря развитию контейнеризации и унификации образов…
👍2🤔1
Продолжая нашу историю про архитектурные разборки в ППО. Ну уж много я пишу однотипных программ в последнее время, так что есть время подумать и попробовать.
Заметил, что в целом существует два основных вида функциональных блоков:
🛠️Сервисный/Утилитарный
🏭Технологический
Сервисный/Утилитарный
Не имеет входов и выходов или имеет только выход с какой-то диагностической информацией, но обращается напрямую к глобальным переменным. Вызывается в теле программы.
В основном служит для организации или подготовке данных.
Технологический
Может вызываться в сервисном или другом технологическом блоке. Не использует глобальные переменные, все необходимые данные передаются через переменные входа и выхода. Непосредственно используется в обработке входов/выходов, оборудования и технологического процесса.
Пока видеться это так. Есть ли какие то другие виды фб, которые вы можете выделить в своих проектах?
#АСУТП #ППО #Архитектура
Заметил, что в целом существует два основных вида функциональных блоков:
🛠️Сервисный/Утилитарный
🏭Технологический
Сервисный/Утилитарный
Не имеет входов и выходов или имеет только выход с какой-то диагностической информацией, но обращается напрямую к глобальным переменным. Вызывается в теле программы.
В основном служит для организации или подготовке данных.
Технологический
Может вызываться в сервисном или другом технологическом блоке. Не использует глобальные переменные, все необходимые данные передаются через переменные входа и выхода. Непосредственно используется в обработке входов/выходов, оборудования и технологического процесса.
Пока видеться это так. Есть ли какие то другие виды фб, которые вы можете выделить в своих проектах?
#АСУТП #ППО #Архитектура
🔥5⚡1
Я вам тут на обед почитать решил занести.
Корпоративные стандарты автоматизации технологических процессов
Выражаю свое спасибо автору этой статье. Интересный обзорный материал по различным корпоративным стандартам и обзором, что они стандартизируют. Есть ссылки на стандарты, что есть в открытом доступе.
Захотелось немного погрузиться в этот мир стандартизации.
#АСУТП #Стандарт
"Я вам че - Автоматизатор?!"
Корпоративные стандарты автоматизации технологических процессов
Выражаю свое спасибо автору этой статье. Интересный обзорный материал по различным корпоративным стандартам и обзором, что они стандартизируют. Есть ссылки на стандарты, что есть в открытом доступе.
Захотелось немного погрузиться в этот мир стандартизации.
#АСУТП #Стандарт
"Я вам че - Автоматизатор?!"
Хабр
Корпоративные стандарты автоматизации технологических процессов
Если посмотреть на ведущие промышленные компании от машиностроения до нефтегаза, то становится ясно, что многие из них давно и плотно занимаются разработкой собственных, внутренних стандартов по...
🔥6👍4
Habr решил провести опрос среди инженеров. Прям всех инженеров, а не только в сфере IT.
Так что если есть интерес, то можете пройти.
https://u.habr.com/jPMgk
Так что если есть интерес, то можете пройти.
https://u.habr.com/jPMgk
Typeform
Исследование от Хабра
Мы делаем исследование о том, кто такие современные инженеры в России
🔥7👍4
Корпоративные стандарты АСУ ТП в пищевой, энергетической и горнодобывающей отраслях
И еще немного корпоративных стандартов, теперь со стороны других отраслей.
Оставлю это здесь, завтра после прочтения присоединюсь к обсуждению
#АСУТП #стандарты
"Я вам че - Автоматизатор?!"
И еще немного корпоративных стандартов, теперь со стороны других отраслей.
Оставлю это здесь, завтра после прочтения присоединюсь к обсуждению
#АСУТП #стандарты
"Я вам че - Автоматизатор?!"
Хабр
Корпоративные стандарты АСУ ТП в пищевой, энергетической и горнодобывающей отраслях
Пищевая промышленность (Nestlé, PepsiCo и др.) Программное обеспечение и стандарты кодирования Крупные пищевые компании внедряют унифицированные подходы к программированию ПЛК и SCADA, чтобы...
👍9
Forwarded from Max Knyazev is typing… (MaxiEnergy)
Всем привет 👋
Помните, я относительно недавно писал, что Qualcomm купила Arduino? Так вот, у нас подъехали подробности по самой интересной новинке — Arduino Uno Q. На Хабре вышел объемный разбор, рекомендую прочитать целиком, кому интересно. Здесь пробежимся кратко по основным приколам платы, чтобы понять, что за зверь и зачем он нужен💀
Из интересного, плата — гибрид: одноплатник на Linux + классическая Arduino в форм-факторе Uno R3. Пины на местах, шилды совместимы, но под капотом совсем другой мир. За «верх» отвечает SoC Qualcomm Dragonwing QRB2210: четыре 64-битных ядра (архитектура уровня Cortex-A53), графика Adreno 702 с поддержкой OpenGL ES/Vulkan/OpenCL, плюс DSP/Hexagon для обработки видео и ML-ускорения. За «низ» — микроконтроллер STM32U585 (ARM Cortex-M33 @160 МГц) с TrustZone и Zephyr RTOS
По железу все выглядит классно: LPDDR4 2 ГБ, eMMC 16/32 ГБ (льётся Debian 13), Wi-Fi 5 + BT 5.1, видеовывод через SlimPort-мост, питание и вся периферия через один-единственный USB-C🪄
У платы есть два режима работы. «Desktop»: подключили хаб, грузится Debian, дальше из App Lab собираете гибридные проекты — CPU-часть крутится в Docker-контейнере, MCU-часть как скетч на STM32. Минус — старт не мгновенный (первые прогоны могут быть ощутимо длиннее ардуиновской «залил-и-поехал»). «Classic»: подрубили к ПК как обычную Arduino, заливаете скетчи из Arduino IDE напрямую и живёте спокойно. Обратная совместимость с шилдами сохранена
Что мне здесь нравится концептуально. Uno Q закрывает вечную дилемму «взять микроконтроллер и навтыкать шилдов» или «тащить Raspberry Pi ради одного HTTP-клиента и GPIO». Теперь верхнеуровневую логику (HTTP, MQTT, UI, ML) мы отдаем CPU с Linux, а управление драйверами, опрос датчиков в RTOS — микроконтроллеру. По моим ощущениям, это отличный кандидат для не слишком сложных мобильных роботов, где критичны стабильные приводы и сенсоры внизу, а сверху логика, навигация, детекция объектов и тд. Задача Uno Q в том, чтобы максимально упростить старт в таких проектах. Arduino же изначально было про образовательные цели, а тут как раз все это делает плату пригодной для обучения школьников, потому что порог вхождения ниже, а вау-эффект выше, чем раньше😅
Короче, если вы когда-то упирались в пределы Uno/ESP и одновременно не хотели тащить целый SBC ради сети/видео — почитайте статью на Хабре, она снимает многие вопросы по практическому использованию Uno Q
P.S. Если наставите лайков этому посту, я куплю себе Arduino Uno Q и на своем примере покажу, какие кейсы можно на ней реализовать))
#интернет_вещей
Помните, я относительно недавно писал, что Qualcomm купила Arduino? Так вот, у нас подъехали подробности по самой интересной новинке — Arduino Uno Q. На Хабре вышел объемный разбор, рекомендую прочитать целиком, кому интересно. Здесь пробежимся кратко по основным приколам платы, чтобы понять, что за зверь и зачем он нужен
Из интересного, плата — гибрид: одноплатник на Linux + классическая Arduino в форм-факторе Uno R3. Пины на местах, шилды совместимы, но под капотом совсем другой мир. За «верх» отвечает SoC Qualcomm Dragonwing QRB2210: четыре 64-битных ядра (архитектура уровня Cortex-A53), графика Adreno 702 с поддержкой OpenGL ES/Vulkan/OpenCL, плюс DSP/Hexagon для обработки видео и ML-ускорения. За «низ» — микроконтроллер STM32U585 (ARM Cortex-M33 @160 МГц) с TrustZone и Zephyr RTOS
По железу все выглядит классно: LPDDR4 2 ГБ, eMMC 16/32 ГБ (льётся Debian 13), Wi-Fi 5 + BT 5.1, видеовывод через SlimPort-мост, питание и вся периферия через один-единственный USB-C
У платы есть два режима работы. «Desktop»: подключили хаб, грузится Debian, дальше из App Lab собираете гибридные проекты — CPU-часть крутится в Docker-контейнере, MCU-часть как скетч на STM32. Минус — старт не мгновенный (первые прогоны могут быть ощутимо длиннее ардуиновской «залил-и-поехал»). «Classic»: подрубили к ПК как обычную Arduino, заливаете скетчи из Arduino IDE напрямую и живёте спокойно. Обратная совместимость с шилдами сохранена
Что мне здесь нравится концептуально. Uno Q закрывает вечную дилемму «взять микроконтроллер и навтыкать шилдов» или «тащить Raspberry Pi ради одного HTTP-клиента и GPIO». Теперь верхнеуровневую логику (HTTP, MQTT, UI, ML) мы отдаем CPU с Linux, а управление драйверами, опрос датчиков в RTOS — микроконтроллеру. По моим ощущениям, это отличный кандидат для не слишком сложных мобильных роботов, где критичны стабильные приводы и сенсоры внизу, а сверху логика, навигация, детекция объектов и тд. Задача Uno Q в том, чтобы максимально упростить старт в таких проектах. Arduino же изначально было про образовательные цели, а тут как раз все это делает плату пригодной для обучения школьников, потому что порог вхождения ниже, а вау-эффект выше, чем раньше
Короче, если вы когда-то упирались в пределы Uno/ESP и одновременно не хотели тащить целый SBC ради сети/видео — почитайте статью на Хабре, она снимает многие вопросы по практическому использованию Uno Q
P.S. Если наставите лайков этому посту, я куплю себе Arduino Uno Q и на своем примере покажу, какие кейсы можно на ней реализовать))
#интернет_вещей
Please open Telegram to view this post
VIEW IN TELEGRAM
👍32🔥12
Иногда хочется переложить с больной головы на здоровую) А раз меня сегодня мучает этот вопрос, то посмею его задать и вам.
Коллеги, как вы думаете, а каким образом можно поднять общий инженерный уровень инженеров-программистов АСУТП в отдельном трудовом коллективе?
Коллеги, как вы думаете, а каким образом можно поднять общий инженерный уровень инженеров-программистов АСУТП в отдельном трудовом коллективе?
Теперь немного подробнее. Пару дней развлекался с 4diac. 4diac - это среда разработки и исполнения, которая реализует стандарт IEC61499.
Из особенностей, которые я для себя понял, это распределенность системы, можно прям точно указывать какой FB в какой среде исполнения будет крутиться, также есть ориентированность на событийность.
В этом стандарте уже технология становиться на первом месте.
Сильно в теорию не погружался, но с наскока реализовать простой проект не вышло, пришлось читать мануал, только он для версии 1.0, а сейчас 3.0, так что надо адаптировать,кстати свой фб тоже не смог сразу создать.
Будет разбираться по ходу.
Если вы вдруг решите сами поиграться с этой средой, то первый квест - это собрать среду исполнения)) Там прям действительно собирать. Разобрался с самым простым вариантом - это CMake + VisualStudio.
Дальше затестирую докеровские контейнеры.
Первый взгляд - мне понравилось.
#АСУТП #4diac
Из особенностей, которые я для себя понял, это распределенность системы, можно прям точно указывать какой FB в какой среде исполнения будет крутиться, также есть ориентированность на событийность.
В этом стандарте уже технология становиться на первом месте.
Сильно в теорию не погружался, но с наскока реализовать простой проект не вышло, пришлось читать мануал, только он для версии 1.0, а сейчас 3.0, так что надо адаптировать,кстати свой фб тоже не смог сразу создать.
Будет разбираться по ходу.
Если вы вдруг решите сами поиграться с этой средой, то первый квест - это собрать среду исполнения)) Там прям действительно собирать. Разобрался с самым простым вариантом - это CMake + VisualStudio.
Дальше затестирую докеровские контейнеры.
Первый взгляд - мне понравилось.
#АСУТП #4diac
👍9
Forwarded from СЭТА Современная электроника и технологии автоматизации
Институт РАН оштрафован на 89 млн рублей за почти годовую задержку разработки ключевых технологий микроэлектроники
Министерство промышленности и торговли России оштрафовало Институт нанотехнологий микроэлектроники РАН на 89,3 млн руб. за срыв сроков разработки перспективных технологий в области радиолокации, диагностики, фотоники и производства полупроводников. Речь идет о задержке почти на год выполнения одного из этапов крупного госконтракта стоимостью 2,89 млрд руб.
Читать подробнее: https://www.cta.ru/news/cta/182667.html
Министерство промышленности и торговли России оштрафовало Институт нанотехнологий микроэлектроники РАН на 89,3 млн руб. за срыв сроков разработки перспективных технологий в области радиолокации, диагностики, фотоники и производства полупроводников. Речь идет о задержке почти на год выполнения одного из этапов крупного госконтракта стоимостью 2,89 млрд руб.
Читать подробнее: https://www.cta.ru/news/cta/182667.html
🔥2
СЭТА Современная электроника и технологии автоматизации
Министерство промышленности и торговли России оштрафовало Институт нанотехнологий микроэлектроники РАН на 89,3 млн руб. за срыв сроков разработки перспективных технологий в области радиолокации, диагностики, фотоники и производства полупроводников.
Немного менеджерского в ленте.
Как говорилось в одном фильме про Питера Паркера: "Я тоже своего рода ученный", но у меня ситуация, что я тоже задержал проект по разработке оборудования на 6 месяцев.
При чем очень полезно проводить ретроспективный анализ ситуации и искать причины таких задержек.
Начиная с того, что я совсем не представлял с какой стороны начинается разработка электроники и через какие этапы должен этот процесс проходить, к тому же отсутствие наработок и опыта похожих задач очень сказывается на оценке сроков.
Также еще стоит учитывать в таких делах продуктивность каждого сотрудника команды и его коэффициент оценки времени на решение задачи. Можно сказать, что неделя у всех разная.
Потом еще можно обратить внимание, что бывают подрядчики и поставки, которые тоже могут задержать производство.
Так что не всегда можно оценить правильно сроки выполнения проекта, особенно когда нет релевантного опыта, так еще, скорее всего, давление со стороны заказчика.
Как говорилось в одном фильме про Питера Паркера: "Я тоже своего рода ученный", но у меня ситуация, что я тоже задержал проект по разработке оборудования на 6 месяцев.
При чем очень полезно проводить ретроспективный анализ ситуации и искать причины таких задержек.
Начиная с того, что я совсем не представлял с какой стороны начинается разработка электроники и через какие этапы должен этот процесс проходить, к тому же отсутствие наработок и опыта похожих задач очень сказывается на оценке сроков.
Также еще стоит учитывать в таких делах продуктивность каждого сотрудника команды и его коэффициент оценки времени на решение задачи. Можно сказать, что неделя у всех разная.
Потом еще можно обратить внимание, что бывают подрядчики и поставки, которые тоже могут задержать производство.
Так что не всегда можно оценить правильно сроки выполнения проекта, особенно когда нет релевантного опыта, так еще, скорее всего, давление со стороны заказчика.
1👍12
Доброе утро, коллеги. Вот теперь, действительно, с новой годой! 🎅 🎅
Продуктивного спокойствия, адекватных заказчиков, вменяемых сроков, чтобы интересные и рутинные задачи были в балансе и вы всегда с успехом доходили до финиша)
Продуктивного спокойствия, адекватных заказчиков, вменяемых сроков, чтобы интересные и рутинные задачи были в балансе и вы всегда с успехом доходили до финиша)
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡18👍12🎉7🔥5
В июне 2022 года я задал вопрос о стандарте IEC 61499, сталкивался ли кто с ним, но тогда ответ был только один.
В конце 2025 года было немного времени, чтобы собрать рантайм для Windows и чуть-чуть поработать в IDE 4diac и создать просто проект со счётчиком срабатываний, а вот собственный ФБ сделать , с первого раза, не вышло.
В чем же отличие от IEC 61131?
Первое и основное событие - переход от циклического выполнения ППО к событийному. Стандартная таска с циклическим выполнением, в стандарте IEC 61499 является периодическим событием.
Из-за событийно-ориентированного подхода меняется и логика написания ППО.
Второй момент - это то, что приложение может быть развернуто на нескольких устройствах, для его выполнения. Правда данные между устройствами передаются не автоматом, там необходимо самому все прописать, напоминает PUT/GET в PCS7 и S7-400.
Ну и третий пункт - больше видов организационных единиц программы.
Так что в этом году постараюсь изучить эту тему подробнее.
ОАСУТП строится на основе этого стандарта, первые физические ПЛК от РГ будут в 2028 году, так что есть немного времени изучить инструмент)
#ОАСУТП #АСУТП #4diac #iec61499
В конце 2025 года было немного времени, чтобы собрать рантайм для Windows и чуть-чуть поработать в IDE 4diac и создать просто проект со счётчиком срабатываний, а вот собственный ФБ сделать , с первого раза, не вышло.
В чем же отличие от IEC 61131?
Первое и основное событие - переход от циклического выполнения ППО к событийному. Стандартная таска с циклическим выполнением, в стандарте IEC 61499 является периодическим событием.
Из-за событийно-ориентированного подхода меняется и логика написания ППО.
Второй момент - это то, что приложение может быть развернуто на нескольких устройствах, для его выполнения. Правда данные между устройствами передаются не автоматом, там необходимо самому все прописать, напоминает PUT/GET в PCS7 и S7-400.
Ну и третий пункт - больше видов организационных единиц программы.
Так что в этом году постараюсь изучить эту тему подробнее.
ОАСУТП строится на основе этого стандарта, первые физические ПЛК от РГ будут в 2028 году, так что есть немного времени изучить инструмент)
#ОАСУТП #АСУТП #4diac #iec61499
👍16