Новости и статьи https://insolsoft.ru ru Wed, 27 May 2026 08:56:56 +0300 Технический семинар в г. Омск 02.04.2026 https://insolsoft.ru/news/tpost/tech_seminar_omsk_02042026 https://insolsoft.ru/news/tpost/tech_seminar_omsk_02042026?amp=true Tue, 17 Mar 2026 14:23:00 +0300 Андрей Казьмин Новости

Технический семинар в г. Омск 02.04.2026

02.04.2026 в г. Омск состоится технический семинар, посвященный новым разработкам в области автоматизации и промышленных сетей на базе Ethernet APL.

Программа семинара:

1.Обзор стандарта 10BASE-T1L (Ethernet APL):
  • Двухпроводной Ethernet на расстояния до 1200 метров.
  • Питание по линии (PoDL) до 15 Вт.
  • Основные мировые производители и области применения в нефтегазовом секторе и промышленности.
2. Обзор стандарта IEC 61499:
  • Сравнение с традиционным МЭК 61131-3.
  • Преимущества распределенных систем управления и компонентно-ориентированного подхода.
3. Продуктовые решения Insol на базе 10BASE-T1L:
  • Неуправляемые коммутаторы Insol Switch V3P/V2P.
  • Медиаконвертеры и решения для систем видеонаблюдения.
  • Специализированный кабель Insol WS для всепогодной прокладки (от -50°C до +85°C).
4. Решения Insol на основе стандарта IEC 61499:
  • Программируемые логические контроллеры (ПЛК) Insol Node.
  • Компактные ПЛК Insol-1000 и Insol-905.5 с поддержкой гирляндного подключения приборов по Ethernet APL.
  • Интеграция SCADA-систем, веб-серверов и баз данных (PostgreSQL).
  • Инструменты конфигурации и компиляции пользовательских модулей (4Diac FORTE).
5. Решения Insol для резервуарного парка:
  • Многофазные радарные уровнемеры Insol-901.
  • Поточные влагомеры нефти Insol-903.
  • Уровнемеры переносные электронные Insol-907.
  • Системы измерений массы и объема нефти и нефтепродуктов в резервуарах Insol-Mass (№ в Госреестре 94658-25).
6. Конфигурация и отладка простого распределенного проекта на реальном оборудовании.

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

Мероприятие будет полезно специалистам ответственным за техническое перевооружение, автоматизацию и повышение эффективности технологических процессов, инженерам АСУ ТП, инженерам КИПиА, руководителям технических отделов и ответственным за резервуарный учёт.

Участие бесплатное. Количество мест ограничено.

Для регистрации просим предоставить сведения о составе участников письмом по электронной почте support@insolsoft.com.

]]> Технический семинар в г. Иркутск 11.03.2026 https://insolsoft.ru/news/tpost/tech_seminar_irkutsk_11032026 https://insolsoft.ru/news/tpost/tech_seminar_irkutsk_11032026?amp=true Tue, 03 Mar 2026 12:29:00 +0300 Андрей Казьмин Новости

Технический семинар в г. Иркутск 11.03.2026

11.03.2026 в г. Омск состоится технический семинар, посвященный новым разработкам в области автоматизации и промышленных сетей на базе Ethernet APL.

Программа семинара:

1.Обзор стандарта 10BASE-T1L (Ethernet APL):
  • Двухпроводной Ethernet на расстояния до 1200 метров.
  • Питание по линии (PoDL) до 15 Вт.
  • Основные мировые производители и области применения в нефтегазовом секторе и промышленности.
2. Обзор стандарта IEC 61499:
  • Сравнение с традиционным МЭК 61131-3.
  • Преимущества распределенных систем управления и компонентно-ориентированного подхода.
3. Продуктовые решения Insol на базе 10BASE-T1L:
  • Неуправляемые коммутаторы Insol Switch V3P/V2P.
  • Медиаконвертеры и решения для систем видеонаблюдения.
  • Специализированный кабель Insol WS для всепогодной прокладки (от -50°C до +85°C).
4. Решения Insol на основе стандарта IEC 61499:
  • Программируемые логические контроллеры (ПЛК) Insol Node.
  • Компактные ПЛК Insol-1000 и Insol-905.5 с поддержкой гирляндного подключения приборов по Ethernet APL.
  • Интеграция SCADA-систем, веб-серверов и баз данных (PostgreSQL).
  • Инструменты конфигурации и компиляции пользовательских модулей (4Diac FORTE).
5. Решения Insol для резервуарного парка:
  • Многофазные радарные уровнемеры Insol-901.
  • Поточные влагомеры нефти Insol-903.
  • Уровнемеры переносные электронные Insol-907.
  • Системы измерений массы и объема нефти и нефтепродуктов в резервуарах Insol-Mass (№ в Госреестре 94658-25).
6. Конфигурация и отладка простого распределенного проекта на реальном оборудовании.

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

Мероприятие будет полезно специалистам ответственным за техническое перевооружение, автоматизацию и повышение эффективности технологических процессов, инженерам АСУ ТП, инженерам КИПиА, руководителям технических отделов и ответственным за резервуарный учёт.

Участие бесплатное. Количество мест ограничено.

Для регистрации просим предоставить сведения о составе участников письмом по электронной почте support@insolsoft.com.

]]> Экономическая эффективность промышленной автоматизации: стратегическая переоценка на основе APL и IEC 61499 https://insolsoft.ru/news/tpost/ekonomicheskaya_effektivnost_promyshlennoi_avtomatizatcii https://insolsoft.ru/news/tpost/ekonomicheskaya_effektivnost_promyshlennoi_avtomatizatcii?amp=true Fri, 23 Jan 2026 10:00:00 +0300 Максим Рафальсон (Инсол) Статьи

Экономическая эффективность промышленной автоматизации: стратегическая переоценка на основе APL и IEC 61499

Данная статья опубликована в СТА №1 / 2026
В промышленной автоматизации, как и в любом другом секторе, последнее слово всегда остаётся за экономикой. Принцип «потребитель голосует рублём» незыблем: итоговая судьба любого инженерного решения определяется его совокупной стоимостью владения. В условиях так называемого «планового охлаждения» экономики, когда предприятия вынуждены балансировать между жёсткой необходимостью снижения затрат и не менее важной задачей сохранения технологической независимости, этот принцип становится основой для стратегических решений.

Вступление

В данной статье мы предлагаем провести объективную оценку архитектурных подходов на базе открытых стандартов APL (Advanced Physical Layer) и IEC 61499 именно с этой, прагматичной точки зрения. Мы намеренно избегаем голословных утверждений о «революционной» экономии, предлагая вместо этого предметный сравнительный анализ с традиционными системами на базе IEC 61131-3, основанный на конкретных цифрах и инженерном опыте.
В качестве сравнительного полигона выбран типовой объект средней сложности – блочно-модульная установка подготовки нефти (УПН). Такой выбор позволяет перейти от абстрактных дискуссий о «цифровизации» к предметному сравнению капитальных (CAPEX) и операционных (OPEX) затрат. Важно подчеркнуть, что предложенная методология носит универсальный характер и применима для анализа абсолютно любых технологических процессов – от конвейерной сборки до металлургических переделов. Общий принцип остаётся неизменным: технологическая цепочка сегментируется на функционально завершённые модули с целью максимальной локализации управления и данных.

Архитектурное сравнение: от кабельных эстакад к сетевым «гирляндам»

Классическая архитектура автоматизации подобного объекта – это монолитная, кабельно-центричная система. Её сердцевину составляют протяжённые эстакады с сотнями контрольных кабелей, сходящихся в операторную, отдельные щиты управления двигателями и исполнительными механизмами, центральный контроллерный шкаф и интеграция в АСУ ТП верхнего уровня.
Архитектура на основе APL меняет эту парадигму кардинально. Вместо паутины индивидуальных кабелей развёртывается единая, отказоустойчивая Ethernet-сеть. В основе её структуры полевой коммутатор с несколькими «гирляндами» – сегментами, каждый из которых обслуживает ключевой технологический модуль (насосная, ТФС, печь). Каждая такая «гирлянда» обладает заложенной расширяемостью, при условии использования соответствующего оборудования (рис. 1).
Совместим данную гирлянду с генеральным планом нашей УПН и сравним кабельные потоки классического и APL решения (рис. 2). Для чистоты анализа мы намеренно исключили из рассмотрения системы противоаварийной защиты (ПАЗ), так как в силу жёсткости нормативных требований их состав и стоимость для обоих вариантов будут идентичны. Для базового сравнения использовались открытые рыночные цены на оборудование.

Анализ капитальных затрат (CAPEX): первое тактическое преимущество

Первичные расчёты для типовой УПН демонстрируют ощутимое сокращение материальной части: экономия на кабельной продукции достигает 34%, а на оборудовании автоматизации – 15%. Рассмотрим детально структуру CAPEX:
  • затраты на проектирование: объём проектной документации и количество спецификаций сокращаются, однако разницей в стоимости этой статьи на первом этапе можно пренебречь;
  • затраты на закуп и СМР: экономия на закупке оборудования составляет около 15%, а на общестроительных работах, связанных с прокладкой и монтажом кабелей, – те самые 35%;
  • затраты на ПНР: затраты здесь сопоставимы, а в варианте с APL, учитывая работы по настройке наружных (уличных) сегментов, могут быть даже несколько выше.
Таким образом, на стартовом этапе общая экономия в пользу решения на APL составляет около 23%. Основной вклад вносит радикальное сокращение кабельного хозяйства. Если для типичного площадочного объекта стоимость системы автоматизации условно делится пополам (50% – кабели и их монтаж, 50% – контроллеры, ПО, шкафы, инжиниринг), то APL сокращает первую половину минимум вдвое, а вторую – ощутимо. Это даёт явное тактическое преимущество на старте проекта.

Главная экономия: не CAPEX, а стоимость изменений и гибкость

Однако возникает резонный вопрос: в чём принципиальная новизна? Распределённый ввод-вывод предлагали и раньше (Siemens, Emerson). Физика интерфейсов, безусловно, ушла вперёд, но суть – локализация управления – осталась прежней.
Ключевое отличие и источник стратегической, долгосрочной экономии раскрывается на этапе модернизации и расширения. Представим оптимистичный сценарий: требуется увеличить нагрузку на площадку из-за новых скважин или роста цен на конечную продукцию (как в той рекламе про «мечты сбываются»). В традиционной архитектуре, где редко закладывают избыточные кабельные трассы, расширение неминуемо ведёт к дорогостоящему «допнику», сложным работам по нарядам-допускам на действующем объекте. Фактически часто проще построить новую параллельную площадку.
В этом сценарии первоначальная экономия меркнет. Затраты на расширение умножаются на коэффициент N (где N – количество новых технологических единиц), а цикл всего проекта от ТЭО до выхода на рассчитанную мощность растягивается на 1,5–2 года – срок, за который рыночная конъюнктура может измениться кардинально.
Архитектура APL меняет правила игры. Добавление нового оборудования зачастую сводится к его подключению к ближайшему полевому коммутатору в существующей «гирлянде». Пропускная способность Ethernet и резерв портов изначально заложены как дешёвый и гибкий ресурс. Основная экономия APL – это радикальное снижение стоимости и сроков любых будущих изменений, что в условиях нестабильности является критическим конкурентным преимуществом.

Третья статья экономии: операционные расходы (OPEX) и человеческий капитал

Наиболее весомая, но часто упускаемая из виду статья экономии – это стоимость обслуживания (OPEX). Корпоративный интернет сегодня доступен на большинстве, даже удалённых объектов. Возможность удалённой диагностики датчика через веб-интерфейс или подключения к контроллеру из офиса для заказчика становится не роскошью, а нормой.
Вместо многодневной командировки специалиста в «места, где волки бегать боятся» – сеанс удалённого подключения. В условиях вечного дефицита квалифицированных кадров это огромная экономия как финансовых, так и человеческих ресурсов. Мы можем подтвердить это практикой: ПНР нескольких площадок были успешно выполнены нашей командой без выезда из офиса. Стоимость человеко-часа в условиях офиса и на технологической площадке отличается кратно. Вопросы информационной безопасности при этом решаемы на организационном, а не на системном уровне.

Вызовы и реалии внедрения: взгляд изнутри

Безусловно, у любого решения есть две стороны. У APL есть свои технические и организационные сложности: недостаточное количество вендоров, предлагающих законченные аппаратно-программные комплексы, как на мировом, так и на российском рынке.
Наша команда в прошлом году проделала значительную работу для преодоления этих барьеров. Были адаптированы программные средства, разработано и произведено сетевое оборудование (коммутаторы, повторители интерфейса, медиаконвертеры). Особой гордостью является разработанный и успешно испытанный кабель Ethernet-APL с сечением жилы 1 мм², стабильно работающий на длине до 1200 метров. Его производство уже налажено на территории РФ (рис. 3). Если хотите исключить «оптику» на ваших объектах (от систем видеонаблюдения до телефонии), заменив их системами, монтируемыми одной отвёрткой – звоните. В ближайших планах – решение задачи резервирования APL-сегментов.

Заключение: APL как стратегический ответ на вызовы времени

В период «планового охлаждения» предприятия, нацеленные на выживание и развитие, вынуждены искать не просто источники сокращения затрат, а стратегические решения, повышающие гибкость и устойчивость. Балансировать между необходимостью технологической независимости (избегая «халтурной русификации» случайных вендоров) и жёстким давлением на OPEX – сложная задача.
Архитектура на основе APL и IEC 61499 предлагает именно такой стратегический ответ. Это не просто замена «железа» или протокола. Это смена парадигмы – переход от жёсткой, кабельно-центричной системы к гибкой, сетевой и программно-определяемой экосистеме. Она обеспечивает:
  • Ощутимую экономию CAPEX за счёт радикального сокращения кабельной инфраструктуры.
  • Стратегическую экономию на изменениях, снижая стоимость и сроки модернизации в разы.
  • Значительное снижение OPEX через удалённое обслуживание и диагностику.
  • Фундамент для технологической независимости, основанный на открытых стандартах и возможности интеграции оборудования различных производителей.
Именно этот комплексный экономический эффект, подтверждённый конкретными расчётами и инженерной практикой, делает подходы на базе APL и IEC 61499 не просто «перспективной технологией», а pragmatic choice для предприятий, планирующих остаться на плаву и выиграть в долгосрочной перспективе.
]]> Развиваем архитектуру АСУ ТП: от стандарта IEC 61499 к готовому решению на платформе 4diac и Ethernet APL https://insolsoft.ru/news/tpost/razvivaem_arhitekturu_asutp https://insolsoft.ru/news/tpost/razvivaem_arhitekturu_asutp?amp=true Mon, 10 Nov 2025 10:00:00 +0300 Максим Рафальсон (Инсол) Статьи

Развиваем архитектуру АСУ ТП: от стандарта IEC 61499 к готовому решению на платформе 4diac и Ethernet APL

Данная статья опубликована в СТА №4 / 2025
В нашей предыдущей статье мы рассмотрели стандарт IEC 61499 и его реализацию в решении 4diac - аппаратной платформе с поддержкой Ethernet APL. В данной статье предлагаю рассмотреть более предметно технические и структурные решения, разрабатываемые компанией Инсол.

Введение

Предлагаемая архитектура, построенная в строгом соответствии со стандартом IEC 61499, фундаментально меняет традиционный подход к построению АСУ ТП (рис. 1). Её ключевая особенность – полное отсутствие централизованных шкафов автоматики. Вместо них интеллектуальные устройства распределяются по объекту, что сокращает затраты на кабельную инфраструктуру и монтаж. В операторной требуется разместить лишь систему бесперебойного питания (ИБП) и коммутаторы для агрегации трафика.
Данная структура является экосистемой для распределённой автоматизации нового поколения.
В разнообразии решений промышленной автоматизации всё острее ощущается потребность в комплексных решениях, которые объединяют вычислительную мощность, сетевое взаимодействие и гибкое уп равление в едином бесшовном пространстве.
Ответом на этот вызов становится связка двух устройств: Insol-Node и Insol-1000 – формирующая готовую экосистему для построения сквозных систем IIoT и Industry 4.0 (рис. 2).

Insol-Node: универсальный вычислительный и сетевой хаб

Что получится, если объединить в одном корпусе полноценный компьютер, управляемый коммутатор 2-го уровня, внешний накопитель на сотни гигабайт, базу данных с OPC UA-сервером на тысячу переменных, среду исполнения для распределённых ПЛК по стандарту IEC 61499 и встроенную веб-SCADA? Ответ – Insol-Node.
Это устройство выполняет роль мощного концентратора и шлюза верхнего уровня. Его ключевые компоненты раскрывают целый спектр возмож ностей.
  • Вычисления и хранение данных: наличие полноценной вычислительной платформы позволяет запускать сложную логику, базы данных исторических трендов и аналитики, что выходит за рамки возможностей типичного программируемого конт роллера.
  • Сетевое ядро: встроенный управляемый коммутатор организует структурированную сетевую топологию, обеспечивая сегментацию трафика, приоритизацию данных и надёжное соединение между всеми элемента ми системы.
  • Полевая сеть: десяток изолированных портов Ethernet-APL с поддержкой питания (PoDL) по каждому каналу – это прямой выход в поле. Технология APL позволяет по двухпроводной линии передавать данные и питание на расстояние до 1500 метров, что критически важно для подключения датчиков и исполнительных механизмов в условиях процессной автоматизации и взрывоопас ных зон.
  • Единая программная среда: интеграция OPC UA-сервера, веб-SCADA и среды выполнения IEC 61499 создаёт целостную среду для разработки, управления и визуализации.
Инженер может в одном веб-интерфейсе настраивать проект как в режиме разработки (develop), так и в режиме исполнения (runtime), без необходимости установки дополнительного ПО.

Insol-1000: интеллектуальный распределённый контроллер

Вторым базовым элементом системы выступает распределённый контроллер Insol-1000. Его архитектура строится на общей шине Insol-Bus, к которой подключаются необходимые модули расширения (дискретные, аналоговые и другие). Адресация модулей задаётся механическим переключателем на лицевой панели, а система их автоматически распознаёт, максимально упрощая процесс конфигурации и замены.
Ключевой особенностью контроллера является присвоение физическим каналам именных алиасов. Вместо работы с малопонятными «сырыми» адресами (вроде addr:0, channel:1, type:dout5) инженер оперирует понятными именами, например «Температура_Реактора_А». Эти алиасы напрямую доступны в среде разработки 4diac (реализация стандарта IEC 61499), что значительно ускоряет программирование и снижает количество ошибок.
Insol-1000 также обладает развитыми коммуникационными возможностями:
  • Modbus-мастер: два порта RS-485 работают в режиме мастера для опроса периферийных устройств (датчиков, частотных преобразователей). Переменные Modbus становятся равнозначными физическим каналам в среде 4diac, а конфигурация интерфейса производится через удобный веб-интерфейс.
  • Modbus TCP-клиент: устройство может выступать в роли подчинённого Modbus TCP-устройства. В этом режиме внешние системы (например, главная SCADA завода) получают доступ как к данным физических входов контроллера, так и к переменным, созданным и вычисленным в логике 4diac.

Единая экосистема: синергия компонентов

Вместе Insol-Node и Insol-1000 образуют мощную и гибкую платформу. На текущий момент серия поддерживает ключевые промышленные про токолы:
  • внутренние протоколы 4diac для рас пределённого управления;
  • проприетарный протокол «Insol-Net»;
  • Modbus TCP для интеграции со сторонними системами.
Находится в стадии разработки поддержка таких высокоскоростных протоколов, как PROFINET и EtherCAT, что ещё больше расширит область применения системы.

4diac: Инструмент для бесшовной разработки распределённых систем управления

Среда разработки 4diac, являющаяся эталонной реализацией стандарта IEC 61499, предлагает интуитивно понятный и дружелюбный интерфейс для проектирования распределённых систем автоматизации.
Основная работа ведётся в System Explorer (рис. 3), который предоставляет доступ к трём ключевым элемен там проекта:
  • Application – создание основной ло ги ки программы.
  • System Configuration – конфигура ция аппаратного обеспечения.
  • Module Library – хранилище программных блоков (как стандартных, так и пользовательских).
Процесс настройки оборудования интуитивно понятен и не требует написания сложных конфигурационных файлов. Инженер просто добавляет на рабочее поле Ethernet-устройства, такие как Insol-Node и Insol-1000, после чего задаёт для каждого из них сетевые параметры: IP-адрес и порт (для Insol-1000 обычно используется порт 61499). Важно отметить, что на Insol-Node можно разместить несколько независимых приложений, работающих на разных портах. Можно распределять нагрузку между приложениями следующим образом: одно выполняет реальные задачи, другое используется для отладки новых компонентов.
Результатом этой настройки становится схематичное изображение всей системы, наглядно отображающее состав оборудования и сетевые связи между компонентами.

Application: визуальное программирование с событийной моделью

Непосредственное создание приложения управления заключается в компоновке программы из готовых блоков, доступных в Библиотеке элементов. Основой для их работы служит событийная модель (Event-Driven) (рис. 4).
Принцип работы событийной модели:
  • Включается по событию: функциональный блок выполняет свою алгоритмическую функцию только при получении сигнала на свой вход события (EI или REQ).
  • Сообщает о завершении: по окончании вычислений блок генерирует выходное событие (EO или CNF), которое, в свою очередь, может запустить следующий блок в цепочке.
Структура функционального блока:
  • Входы/выходы событий определяют, когда блок выполняется и когда он завершает свою работу.
  • Входы/выходы данных отвечают за передачу значений переменных и состояний между блоками.
Итог: среда 4diac позволяет не только визуально сконфигурировать систему, но и создать распределённую программу, где логика чётко разделена и выполняется строго по факту наступления определённых условий, что в полной мере соответствует принципам построения современных АСУ ТП.

Архитектура «Издатель-Подписчик»: простота, скорость и визуальное программирование

В сетевом разделе библиотеки модулей представлены два типа функциональных блоков, заслуживающих особого внимания, – «Издатель» (PUBLISH) и «Подписчик» (SUBSCRIBE).
Логика их работы проста и элегантна: блок Издатель передаёт данные по сети, используя внутренний идентификатор (ID), а неограниченное количество Подписчиков может одновременно получать эти данные. Это формирует основу для построения масштабируемых и гибких решений.
При этом простота не достигается в ущерб производительности. Проведённый стресс-тест, в котором 30 устройств серии 1000 были соединены в последовательную цепочку (каждое устройство выступало и подписчиком, и издателем), показал впечатляющий результат: сквозная задержка распространения данных по всей цепочке не превысила 50 мс. Это доказывает, что данная архитектура идеально подходит для систем управления реального времени.
Разработчику следует помнить, что у высокой скорости передачи есть оборотная сторона медали. 4diac использует UDP-соединение (без подтверждения доставки), и для критически важных событийных сигналов надо разрабатывать триггерную схему передачи данных.
Привязка к «железу» («Map to»): после создания программной логики её необходимо сопоставить с физическими устройствами. Это делается одним щелчком мыши с помощью команды «Map to» в контекстном меню. Элементы приложения автоматически окрашиваются в цвета тех устройств, за которыми они закреплены.
Инициализация и запуск (Deploy): важно подключить программу к инициализирующему событию. После этого выполняется команда «Deploy» – она загружает программу в ОЗУ целевых устройств и немедленно запускает её на выполнение.
Онлайн-отладка: система предоставляет удобные инструменты для отладки в реальном времени. Инженер может вручную инициировать события и в режиме онлайн отслеживать прохождение сигналов между блоками, что делает процесс поиска и исправления ошибок быстрым и наглядным.
Создание автономного образа (Boot File): после полной отладки программы создаётся Boot-файл. По сути, это XML-описание всего приложения: все экземпляры блоков, их параметры и связи. Этот файл записывается во флеш-память устройства и автоматически запускается при каждом его включении, обеспечивая полную автономность работы системы.

Создание собственных функциональных блоков

Любая мощная система должна позволять расширять свой функционал. 4diac обладает комфортным и продвинутым инструментарием для создания пользовательских функциональных блоков (ФБ) (рис. 5).
Процесс их создания выглядит следующим образом.
В интегрированной среде разработки (IDE) создаётся новый типовой ФБ, где описываются все его входные и выходные события и данные.
Типовой ФБ может содержать несколько алгоритмов, разработанных на привычном языке структурного текста (ST) стандарта IEC 61131-3.
Далее графически создаётся ECC-диаграмма (State Machine), которая определяет, какой алгоритм и в какой последовательности будет выполняться в зависимости от того или иного события.
Система автоматически интерпретирует созданный пользовательский блок в код на языке С++.
Полученный C++ файл добавляется через веб-интерфейс Insol-Node, где происходит его фоновая компиляция, полностью скрытая от пользователя.
После этого функционал нового блока становится доступен во всех приложениях Insol-Node.
На данном этапе развития продукта мы убрали возможность создания пользовательских блоков для Insol-1000, чтобы повысить отказоустойчивость, учитывая тот факт, что они находятся «в поле» и оперативный доступ к ним может быть затруднён. Но создание простых ПИД-регуляторов, алгоритмов защиты и прочее доступно пользователю в полной мере.

Интеграция в базу данных и OPC UA сервер

В базовой поставке от компании «ИНСОЛ» доступны специальные функциональные блоки для записи и чтения данных различных типов во встроенную базу данных. Максимальное количество переменных для записи в БД ограничено 5000, при этом гарантированная скорость чтения/записи одной переменной не превышает 50 мс. Интеграция с внешними системами (такими как MES или ERP) осуществляется через OPC UA-сервер, который конфигурируется как отдельное приложение-надстройка над базой данных.

Визуализация: встроенная SCADA-система FUXA

«Вишенкой на торте» всей экосистемы является встроенная SCADA-система на базе FUXA. Это полностью веб-ориентированное решение, работающее как в режиме разработки, так и в режиме runtime. Система поддерживает графическую динамику, построение трендов, имеет собственную базу данных и может подключаться к данным через Modbus TCP или в качестве OPC UA-клиента к серверу, работающему на Insol-Node.
Данный инструмент позволяет быстро, «прямо здесь и сейчас», создавать и вводить в эксплуатацию мнемосхемы и панели оператора, что делает его отличным решением для задач визуализации в составе комплексной платформы.
]]> Обзор решений на базе Ethernet APL https://insolsoft.ru/news/tpost/obzor_resheniy_na_baze_ethernet_apl https://insolsoft.ru/news/tpost/obzor_resheniy_na_baze_ethernet_apl?amp=true Tue, 29 Jul 2025 10:00:00 +0300 Максим Рафальсон (Инсол) Статьи

Обзор решений на базе Ethernet APL

Данная статья опубликована в СТА №3 / 2025
Ethernet Advanced Physical Layer – технология, которая обеспечивает усовершенствованный физический уровень передачи данных в сетях Ethernet. Технология Ethernet APL предназначена для автоматизации технологических процессов в сложных производственных средах, таких как химическая, нефтегазовая, фармацевтическая и другие отрасли. Для реализации технологии Ethernet APL используются совместимые устройства: полевые устройства (датчики, исполнительные механизмы) и коммутаторы Ethernet APL для сетевой коммуникации.

Ethernet APL на базе стандарта 10BASE-T1L

Прежде чем перейти к описанию стандарта Ethernet APL, позволим небольшую предысторию.
Это был 2021 год. Время, когда трава казалась зеленее, мы – моложе, а ковид и прочие напасти ещё не успели прочно поселиться в наших буднях. Где-то далеко за Полярным кругом шёл запуск очередной версии уровнемера. Если не вдаваться в технические детали, то ключевым «апгрейдом» модели стал разъём RJ-45.
Обратная связь от специалиста КИП, который в –40°C на 15-метровой высоте пытался обжать этот разъём, была… скажем так, особо выразительной. Настолько, что вопрос поиска более надёжного решения для промышленной связи показался крайне важным.
К счастью, в тот момент Analog Devices, Inc., американская компания, специализирующаяся на технологиях преобразования данных, обработки сигналов и управления питанием, как раз представила свой чип ADIN1100 – и перед нами открылись новые горизонты.
Чип ADIN1100 представляет собой специально разработанный для промышленного применения малопотребляющий приёмопередатчик Ethernet 10BASE-T1L, соответствующий стандарту IEEE 802.3cg для передачи данных на большие расстояния со скоростью 10 Мбит/с по одной паре проводов.
Итак, давайте начнём с определения Ethernet APL.
Ethernet-APL (Advanced Physical Layer) – это стандарт физического уровня Ethernet (IEEE 802.3cg), разработанный для промышленной автоматизации. Он обеспечивает:
  • двухпроводную передачу данных (10BASE-T1L) со скоростью 10 Мбит/с;
  • питание через линию связи Power over Data Line (PoDL);
  • расстояние передачи данных до 1200–1500 метров;
  • искробезопасность во взрывоопасных зонах (Ex ia-защита) в соответствии со стандартом IEC 60079-11:2011.
Структурная схема стандарта Ethernet APL представлена на рис. 1. В качестве хоста может быть использован любой процессор, поддерживающий RMII (RGMII), в качестве микросхемы физики SPE PHY используется чип ADIN1100 или его аналог DP83TD510E (производства Texas Instruments).
Разработчикам остаётся лишь рассчитать и продумать необходимую систему фильтров в зависимости от поддерживаемого регламентированного стандарта мощности в диапазоне от искробезопасной до 70 Вт.
Сам стандарт Ethernet APL поддерживает искробезопасное подключение датчиков. Следует отметить, что на текущий момент все ведущие производители КИП практически лавинообразно расширяют свою продуктовую линейку датчиками с поддержкой Ethernet APL. Могу предположить, что в перспективе ближайших 5-10 лет произойдёт плавное вытеснение датчиков 4-20 мА (HART).
На рис. 2 представлена структура сенсора типового датчика с поддержкой Ethernet APL. С точки зрения энергопотребления он практически ничем не отличается от привычных 4…20 мА (HART), но отсутствие необходимости задумываться о полярности и скорость соединения сильно и приятно удивят пользователей «современных» AMS систем.
Что касается правой части рис. 2: помимо наших собственных разработок, на рынке стали появляться Ethernet APL - коммутаторы производства Stahl, Phoenix, Siemens и пр., причём разработанные именно для полевого использования.
Основным преимуществом стандарта Ethernet APL является то, что объединение производственных и административных объектов в единую сеть Ethernet создаёт возможность IP-адресации для любого конечного узлового устройства из любой точки мира в любое время.
Прозрачная IP-адресация каждого устройства полевого уровня значительно упрощает установку, настройку и обслуживание решений, подключённых к сети 10BASE-T1L. Стандарты Ethernet гарантируют, что все устройства 10BASE-T1L могут использовать промышленные протоколы связи, такие как PROFINET, EtherNet/IP, HART/IP, OPC UA или MODBUS/TCP, и поддерживать протоколы IoT.

Стандарт IEC 61499 и 4diac

Давайте попробуем смешать стандарт IEC 61499 и 4diac и хорошенько взболтать, и чтоб разобраться, что за напиток у нас получается, более подробно остановимся на основных ингредиентах.
В сущности, основные ингредиенты – стандарт и программный продукт, – это две абсолютно разные вещи, но в нашем случае для более лёгкого понимания удобно рассматривать их вместе.
На просторах всемирного разума достаточно информации касательно стандарта IEC 61499. Он фактически является продолжением стандарта IEC 61131 и придуман для построения распределённых систем управления.
На рис. 3 продемонстрирована принципиальная разница между стандартами IEC 61131 и IEC 61499. Стандарт IEC 61131 имеет строго иерархическую структуру построения: один процессор (дублированный или нет), на который по цифровым каналам и/или по физическим сигналам корзины попадает вся информация о процессе. Далее различным инструментарием вендора на одном из 5 языков программирования происходит разработка цикличного приложения.
Уверен, у большинства читающих этот текст имеется огромный опыт построения различных систем в данном формате в различных отраслях народного хозяйства.
В чём же принципиальное отличие стандарта IEC 61499? Вследствие прогресса в развитии промышленных сетей, сделавшего огромный скачок за последние 10–15 лет, вполне логично возник вопрос о возможности построения систем управления с распределённым центром на несколько процессоров, причём работающих под различными операционными системами, от FreeRTOS до Windows.
Основными принципами стандарта IEC 61499 являются:
  • распределение задач автоматизации посредством Ethernet соединения на неограниченное количество процессоров. Таким образом вы можете распределять вычислительную нагрузку на систему целиком, например, простейшую логику управления алгоритмом на месте делает локальный контроллер, а оптимизацию параметров – установок регуляторов, интервальных задержек и прочие алгоритмы посложнее – вычисляет более производительная машина;
  • событийная модель реализации алгоритма. То есть блоки выполняются не по циклу, а когда это необходимо (например, пришёл сигнал – сработал блок);
  • блочная структура написания кода управления (с диаграммной моделью управления событиями). В данной структуре код управления может задаваться каждому блоку по отдельности.
Работа по разработке стандарта IEC 61499 велась в рамках международной электротехнической комиссии МЭК (IEC, International Electrotechnical Commission) в рабочей группе WG63 технического комитета TC65. Обсуждение будущего стандарта IEC 61499 началось в октябре 1990 года, активная работа над ним – в марте 1992 года, период апробации подготовленного проекта стандарта – в марте 2001 года и, наконец, завершение разработки – в 2005 году.
Основной целью разработки стандарта IEC 61499 была необходимость решить проблемы гибкости и создания распределённой системы в автоматизации. Но долгое время он оставался «на бумаге», на взгляд автора, по ряду причин. Вот основные из них:
  • отсутствие нормальных распределённых Ethernet-сетей. В реалиях того времени тянуть витую пару дальше 100–150 метров не представлялось возможным. В то же время устанавливать кучу процессоров для промышленных объектов в одном помещении, согласитесь, выглядит несколько странно. С учётом гонки производительности Intel, AMD и прочих брендов было удобнее оставаться в рамках стандарта EIC 61131;
  • консервативность ведущих вендоров. Зачем что-то менять в процессе, если и так всё работает?

С последней проблемой блестяще справилась команда разработчиков (включая авторов стандарта!), создав 4diac – бесплатную «open source» платформу, которая показывает, как стандарт IEC 61499 должен работать в реальной жизни, и сделала её доступной для производителей «железа», таких как мы.

Практическое применение стандарта IEC 61499, 10BASE-T1L и 4diac

Давайте познакомимся с 4diac поближе. 4diac состоит из двух программных модулей – это 4diac IDE на базе Eclipse и 4diac Forte.
4diac Forte – исполнительная часть программы, работающая на удалённых машинах.
4diac IDE – среда разработки для моделирования распределённых приложений управления.
В качестве «Hello World» предлагаю рассмотреть проект железной дороги. Что нам понадобится:
  • 4diac;
  • коммутатор Insol-Node – 1 шт.;
  • удалённые модули Insol-1000 – 3 шт.;
  • модель железной дороги от Piko (рис. 4) – 1 шт.
Структурная схема железной дороги с указанием функциональных блоков представлена на рис. 5, где (1) – коммутатор Insol-Node, (2) – удалённые модули Insol-1000.
Каждый удалённый модуль Insol-1000 является функциональным блоком управления скоростью поезда на определённом сегменте железной дороги. Общий вид функционального блока с описанием алгоритма действий представлен на рис. 6.
В результате мы имеем программу управления распределённую между четырьмя устройствами (рис. 7).
Как же это работает? Территориально железную дорогу разбили на 3 сегмента, каждому сегменту соответствует свой контроллер, который отвечает за сенсоры и исполнительные механизмы на его сегменте. Первый контроллер отвечает за стрелку въезда в депо и съезда с нефтебазы, второй контроллер – за скорость поезда, направление движения и освещение железной дороги, третий – за стрелку въезда на нефтебазу и кнопки команд, расположенные в правом нижнем углу на рис. 5. Коммутатор реализует общий алгоритм движения.
В сущности, в данной распределённой системе есть всё необходимое для комфортной работы, а именно:
  • возможность отладки в режиме онлайн как всей системы целиком, так и на каждого отдельно стоящего конт роллера;
  • онлайн-наблюдения за прохождени ем сигналов;
  • развёртывание всей системы целиком и каждого отдельно стоящего контроллера.
В описании стандарта IEC 61499 упоминалось, что он использует блочный принцип создания программ. Суть этого принципа с точки зрения исполнительной системы заключается в том, что набор доступных FB (функциональных блоков) в 4diac IDE и в исполнительной машине одинаков. После компиляции 4diac IDE генерирует XML-файл, в котором описывается, какие экземпляры функциональных блоков используются и как они связаны между собой.
Согласимся, что отличия в работе по сравнению с софтом на базе стандарта IEC 61131 вызывают некоторое замешательство для бывалых и не очень «асушников» и требуют ряда перестроек внутреннего алгоритма мышления при написании программ, но, на взгляд автора, общая структура более прозрачна и несёт огромное количество преимуществ, например:
  • открытость системы, изначально заточенной под разработчиков «железа»;
  • масштабируемость;
  • переносимость системы вашего кода на разные платформы;
  • совместимость с протоколом Ethernet APL (10Base-T1L).

Решения и продукты ООО «Инсол»

Основным направлением разработки продуктов «Инсол» является производство оборудования, «заточенного» под требования IEC 61499 и 4diac, это, в том числе производство сетевого оборудования с поддержкой Ethernet APL. Примеры сетевого оборудования производства ООО «Инсол» приведены в табл. 1.
Внешний вид сетевого оборудования приведён на рис. 8.
В чём же преимущества сетевого оборудования производства «Инсол»? Рассмотрим пример типового решения для камер видеонаблюдения (рис. 9) и решение с удлинителем Ethernet APL (рис. 10).
Мы видим, что благодаря сетевым решениям на основе Ethernet APL есть возможность без дополнительных затрат увеличить расстояние между камерами видеонаблюдения до 1000 метров.

Оборудование для реализации стандарта IEC 61499

Мы разобрались с тем, что IEC 61499 – это неограниченное множество вычислительных узлов, объединённых в одну сеть. Мы разобрались, как строить сети на базе Ethernet APL. Давайте рассмотрим решения по этим узлам и как их можно структурировать на технологической площадке (рис. 11).
Начнём рассмотрение структуры снизу вверх. Основным «кирпичиком» нашей системы является процессорный модуль Insol-1000. Внешний вид модуля Insol-1000 представлен на рис. 12.
Модуль Insol-1000 является базовым модулем контроллера и представляет собой пластиковый корпус с печатными платами с внешними разъёмами и интерфейсами, а также жидкокристаллическим дисплеем. Основные технические характеристики модуля указаны в табл. 2. Также важными компонентами системы являются модули расширения Insol-100X. Описание модулей расширения приведено в табл. 3.
Одной из главных «фишек» 1000-й серии является то, что контроллеры можно соединять последовательно парой проводов, и эта «гирлянда» будет представлять единую локальную сеть с максимальной длиной одного сегмента до 1500 метров и внутренней скоростью передачи данных до 10 Мбит/с. Подключаете её к вашему компьютеру через медиаконвертер, и весь функционал 4diac в вашем распоряжении. На практике мы подключали контроллеры на расстоянии 3 км с заданными характеристиками.
Контроллер Insol-1000 – это сетевое устройство, предназначенное для подключения различных видов датчиков в общую систему управления через сеть Ethernet, удалённого сбора и обработки информации с подключённых датчиков, и управления ими путём передачи данных через соответствующие интерфейсы для выработки управляющих воздействий.
Контроллер применяется в различных системах сбора данных и управления, АСУ ТП промышленных предприятий, в системах безопасности и видеонаблюдения.
Контроллеры в пластиковом корпусе рекомендованы к применению в помещениях, пространствах электротехнических шкафов и отсеках промышленного оборудования вне взрывоопасных зон. Во взрывоопасных зонах применяется контроллер Insol-1000 Ex во взрывозащищённом корпусе (рис. 13).
Отличительными особенностями применения контроллера Insol-1000 являются:
  • работа в сети Ethernet по протоколу 10BASE-T1L;
  • возможность последовательного и закольцованного подключения коммутаторов с расстоянием между устройствами до 1,5 км и скоростью передаваемых данных до 10 Мбит/с;
  • использование технологии PoDL (Power over Data Line – Питание по линиям данных), то есть передача данных и питания по однопарному кабелю, что обеспечивает экономичное использование кабельной продукции;
  • модульная конструкция, увеличение количества каналов путём присоединения модулей расширения (модулей ввода-вывода).
Питание контроллера может осуществляться:
  • от удалённого источника номинальным напряжением 48 В посредством PoDL (Power over Data Line – питание по линиям данных), то есть непосредственно по витой паре, через которую передаются данные;
  • от локальных источников 24...48 В при помощи модуля питания Insol-1051;
  • по PoDL и от локального источника одновременно (комбинированная схема подключения питания).
Обмен информацией между контроллером и сторонним оборудованием осуществляется по протоколам Modbus RTU (интерфейс RS-485), Modbus TCP, внутреннему протоколу INSOL NET.
Контроллер имеет встроенное программное обеспечение Insol-Net и предустановленную исполнительную среду системы 4diac Forte. Программное обеспечение поставляется предустановленным в контроллер, имеет встроенный веб-интерфейс для удалённой настройки и диагностики через любой браузер и не требует для своего функционирования предустановки дополнительного программного обеспечения. Контроллер Insol-1000 в сборе с модулями расширения представлен на рис. 14.
Итак, далее поднимаемся по структуре (рис. 11). То, что у нас называется «уровнем транспорта», представлено как в виде упомянутого в начале неуправляемого сетевого оборудования с поддержкой Ethernet APL (неуправляемые коммутаторы Insol-Switch и медиаконвертеры MC3X), так и в виде управляемых коммутаторов Insol-Node.
Insol Node – это управляемый коммутатор, предназначенный для объединения в единую сеть устройств, построения распределённых систем сбора данных и управления АСУ ТП.
Внешний вид Insol Node представлен на рис. 15, а основные технические характеристики Insol Node указаны в табл. 4.
Кроме непосредственного запуска приложения 4diac Forte, причём сразу нескольких экземпляров, коммутатор имеет возможность отладки и компиляции пользовательских функциональных блоков. Структура формирования, отладки и компиляции функциональных блоков представлена на рис. 16.
Этот инструментарий делает систему 4diac полнофункциональным инструментом АСУ ТП, позволяя конечному пользователю сэкономить время на разбирательстве с внутренними процедурами оборудования и системы, сосредоточившись непосредственно на разработке прикладного программного обеспечения.
Одним из важнейших по значимости инструментарием Insol-Node является опрос по протоколам, сбор данных от устройств (HTTP, ModBus/TCP и т.п.) и сохранение в базе данных c предоставлением в формате данных OPC UA.
В функции программного обеспечения интегрирована SCADA-система от Инсол (на базе FUXA), что c минимальными затратами позволяет делать как визуализацию на простых HMI-панелях с поддержкой WEB, так и создание полноценной клиент-серверной структуры.

Заключение

Новые стандарты позволили автоматизации стать более гибкой в стремительно изменяющемся мире бизнеса. Использование оборудования и продуктов производства «Инсол» позволяют заказчикам экономить на капитальных затратах (CAPEX), а также существенно снизить операционные расходы (OPEX).
]]> Распределённый ПЛК без шкафов автоматики: собираем АСУТП на 4diac FORTE, PostgreSQL и FUXA SCADA https://insolsoft.ru/news/tpost/raspredelyonniy-plk-bez-shkafov-avtomatiki https://insolsoft.ru/news/tpost/raspredelyonniy-plk-bez-shkafov-avtomatiki?amp=true Tue, 26 May 2026 14:19:00 +0300 Максим Рафальсон (Инсол) Статьи

Распределённый ПЛК без шкафов автоматики: собираем АСУТП на 4diac FORTE, PostgreSQL и FUXA SCADA

Классическая АСУТП - это шкаф с центральным контроллером в операторной, к которому стягиваются километры кабелей с полевых датчиков. Это работает, но дорого, неудобно при расширении и плохо ложится на современные объекты, где «полевая» часть размазана по большой территории. Стандарт IEC 61499 в этом месте предлагает другую модель: программа описывается как сеть функциональных блоков, и одна и та же программа распределяется сразу по нескольким независимым устройствам в сети - без центрального ПЛК.
В этой статье я покажу, как это выглядит на практике. Соберём небольшую распределённую систему на двух устройствах: ПЛК Insol-1000 (Рис. 1) (FreeRTOS, STM32H) занимается полевым уровнем - опрашивает дискретные входы, считает 4...20 мА, рулит OLED-дисплеем; шлюз Insol-Node (Рис. 2) (Linux) - это «верх» с PostgreSQL, встроенным OPC UA сервером и SCADA-платформой FUXA. Между ними - UDP multicast по схеме PUBLISH/SUBSCRIBE. Среда разработки одна - 4diac IDE, runtime один - 4diac FORTE, программа одна, но разрезанная между устройствами.

TL;DR

  • 4diac - open-source реализация IEC 61499 от Eclipse Foundation. IDE + лёгкий C++ runtime FORTE.
  • Логика - это сеть функциональных блоков (FB), соединённых по событиям и данным. Блоки выполняются только при получении события - никаких циклов сканирования в стиле классического IEC 61131-3.
  • Программа описывается один раз, потом распределяется на нужные устройства через маппинг. Деплой - по сети, в RAM устройства; для автономной работы создаётся *.fboot файл, который runtime подхватывает при старте.
  • Сетевая интеграция между устройствами - через блоки PUBLISH_N / SUBSCRIBE_N (UDP multicast). Без брокера, без центрального сервера.
  • На Insol-Node поверх этого работает PostgreSQL (архивирование), OPC UA-сервер (для SCADA и MES) и FUXA - веб-SCADA с редактором мнемосхем прямо в браузере.
Дальше - как это собрать с нуля.

Часть 1. Что такое IEC 61499 и чем он отличается от привычного IEC 61131

Если коротко: классический IEC 61131-3 - это про сканирующий цикл одного устройства. Программа лежит в одном контроллере, циклически читает входы, считает логику, пишет выходы. Когда нужно «разнести» систему - между ПЛК ставятся отдельные шлюзы, Modbus-мосты и прочее склеивающее железо.
IEC 61499 переворачивает модель:
  • Программа независима от железа. Сначала вы описываете всё приложение целиком - как сеть функциональных блоков. На каком устройстве что будет выполняться - решается позже, в System Configuration.
  • Событийная модель. У каждого блока есть отдельные входы для событий (тонкие красные линии в редакторе) и для данных (синие линии). Блок исполняется в тот момент, когда на событийный вход пришёл триггер - не раньше и не позже. Цикл опроса организуется явно - обычно блоком E_CYCLE с заданным периодом.
  • Распределение приложения. Через маппинг одна и та же сеть блоков «разрезается» между устройствами. Часть блоков уезжает на Insol-1000, часть - на Insol-Node.
  • Прямая связь между устройствами. PUBLISH/SUBSCRIBE - это UDP multicast: издатель льёт пакеты на групповой адрес, подписчики ловят. Никакого центрального брокера, никакого посредника.
Где это особенно полезно: распределённые объекты - нефтегазовая телеметрия, ЖКХ, протяжённые объекты вроде водоканалов, фабрики с разбросанной по корпусам автоматикой. Всё, где централизованный шкаф управления - это либо длинные дорогие кабельные трассы, либо вообще нерешаемая задача.
! Важный нюанс: UDP не гарантирует доставку. Для критичных управляющих сигналов нужна триггерная схема с подтверждением - SUBSCRIBE отправляет назад «эхо», PUBLISH повторяет, если эхо не пришло за таймаут. Это вы строите сами поверх стандартных блоков. Для телеметрии/архивирования штатного multicast обычно достаточно.

Часть 2. Что в наборе

Аппаратная часть для примера:
Insol-1000 - модульный ПЛК с шиной I-BUS: к базовому модулю слева цепляются модули питания, справа - модули расширения (I1001 8DO, I1002 8DI, I1003 / I1004 аналог 4–20 мА с HART, I1005 для термопар/RTD). Между ПЛК в сети - однопарный Ethernet 10BASE-T1L (до 1500 м между устройствами, скорость 10 Мбит/с, питание PoDL прямо по той же витой паре).
Полевой уровень распределяется прямо по объекту (Рис. 4). На верхнем уровне - обычная Ethernet/Gigabit-сеть до SCADA.
В этой статье сеть нас интересует постольку-поскольку — всё, что нужно знать, что устройства просто находятся в одном сегменте Ethernet сети.
Из софта:
  • 4diac IDE - на ПК разработчика. Сборка от Insol лежит на их сайте, основана на Eclipse, в неё уже добавлены .fbt-типы под Insol-Node и Insol-1000 - иначе пришлось бы вручную подкладывать библиотеку.
  • 4diac FORTE - прошитый на устройствах runtime. На Insol-1000 - внутри FreeRTOS, на Insol-Node - поверх Linux. Поддерживает все элементарные типы IEC 61131-3 рев. 2, базовые/составные/интерфейсные FB, адаптеры, online-реконфигурацию приложений без остановки.
  • На Insol-Node поверх FORTE работает экосистема верхнего уровня: PostgreSQL, OPC UA сервер (open62541), Modbus TCP клиент (libmodbus), и FUXA SCADA.
Качаем дистрибутив 4diac IDE и тестовый проект с insolsoft.ru → «Техподдержка» → «ПО 4diac». Тестовый проект — это .zip с уже готовой структурой Type Library (блоки INSOL_IO, I1000_4_20MA_IN/OUT, I1000_DISPLAY, I1000_PID, SQL_SET_*, SQL_GET_VAL) и парой Application-схем.
Дальше - раскручиваем по шагам.

Часть 3. Подготовка устройств через web-интерфейс

Прежде чем запускать IDE, нужно подготовить устройства. У обоих - встроенный web на стандартных портах.

3.1. INSOL-1000: проверка прошивки и алиасы каналов

Открываем http://192.168.0.132 (адрес виден на встроенном OLED). В разделе «Прибор → О системе» - текущая версия прошивки. Если она старее, чем на сайте - обновляем через web. Если web-интерфейс не отзывается - есть аварийный режим: удерживаем две вертикальные кнопки на лицевой панели до подачи питания, тогда контроллер стартует в bootloader.
Дальше - самое важное: алиасы каналов. Алиас - это понятное имя физического канала, которое потом будет указываться в параметре PARAMS функциональных блоков IB / QB / IW / QW в 4diac. Это удобно: вы пишете 'ain0' вместо адреса вида «addr:0,channel:1», и эти же алиасы используются всеми верхнеуровневыми компонентами - PostgreSQL, OPC UA, FUXA.
Каждому физическому каналу даётся короткое имя, под которым он будет виден из 4diac (Рис. 5).
Алиасы чувствительны к регистру. Значение в PARAMS блока должно совпадать с web-интерфейсом байт в байт - 'AIN0' и 'ain0' это разные каналы, и runtime молча подсунет «не тот». В разных прошивках префиксы могут отличаться (di0/din0, do0/dout0) - сверяйтесь с тем, что реально показано в таблице.

3.2. INSOL Node: запуск сервиса FORTE

Тоже web-интерфейс. Идём в раздел Forte → Сервисы Forte 3, нажимаем «Добавить сервис», задаём порт (в примере 60001), выбираем сборку (на первый запуск - заводская, например test31). На первом запуске оставляем Forte bootfile пустым - иначе при старте FORTE подхватит старую программу из .fboot и проигнорирует то, что вы хотите задеплоить из IDE.
Запускаем сервис кнопкой ▶. Всё - устройства готовы принимать программу.

Часть 4. Проект в 4diac IDE

Создаём проект: File → New → 4DIAC Project, имя test33, выбираем рабочую папку - Finish. В System Explorer появляется дерево проекта с пустым System и Type Library.

4.1. Подкладываем библиотеку блоков INSOL

В Type Library создаём подпапки 1000, inode, userblock и складываем туда .fbt файлы. В сборке IDE от Insol они уже включены, но если вы ставили оригинальный 4diac с Eclipse.dev, придётся скачать библиотеку отдельно с insolsoft.ru в рамках предложенного дистрибутива.
Минимальный набор для нашего демо:
  • В 1000/: INSOL_IO, I1000_4_20MA_IN, I1000_4_20MA_OUT, I1000_DISPLAY, опционально I1000_PID
  • В inode/: SQL_SET_BOOL, SQL_SET_INT, SQL_SET_REAL, SQL_SET_LONG, SQL_SET_STRING, SQL_GET_VAL
  • В userblock/ - пока пусто, сюда положим свой кастомный блок чуть позже.

4.2. System Configuration - где какое устройство

Дважды кликаем на System. Правой кнопкой → New Device для каждого из двух устройств. Задаём имена и MGR_ID:
С этого момента IDE знает, кто на проводе, и может туда деплоить.

4.3. Application для Insol-1000

Создаём Application с именем PLC132 - это сеть блоков, которая поедет на полевой контроллер (Insol-1000). Ключевые элементы схемы:
  • INSOL_IO - обязательно первый блок. Инициализирует шину I-BUS. Параметр QI = 1 (включено). Все остальные I/O-блоки запустятся только после события CNF от INSOL_IO.
  • E_CYCLE (DT = T#50ms) → IB (PARAMS = 'di0' … 'di3') - циклический опрос дискретных входов с периодом 50 мс. Каждый IB отдаёт на выходе OUT булеву переменную текущего состояния входа.
  • IW ('ain0' … 'ain2') → I1000_4_20MA_IN → F_REAL_AS_WSTRING → I1000_DISPLAY - аналоговые входы 4...20 мА, перевод в REAL (масштабирование), форматирование в строку и вывод на OLED.
  • QB ('do0' … 'do3') - дискретные выходы.
  • I1000_4_20MA_OUT → QW ('aout0') - аналоговый выход 4–20 мА. Уставка для него приходит сверху от INSOL Node.
  • PUBLISH_3 (ID = "239.0.0.1:13201") - публикует три значения ain0..ain2 в multicast.
Application PLC132 (Рис. 7): INSOL_IO инициализирует I-BUS, E_CYCLE крутит опрос, аналоговые входы идут через масштабирование на OLED, дискретные выходы - на полевые реле. SUBSCRIBE_1 ловит уставку aout0 с верхнего уровня.
Адрес 239.0.0.x - это IANA-зарезервированный диапазон для административно-локального multicast, роутер за пределы локального сегмента такие пакеты не выпустит. Порт можно выбирать любой свободный - в примере 13201 для аналога, 13202 для обратного канала.

4.4. Applications для INSOL Node

На стороне Node делаем два Application - для разделения по смыслу:
Node1 (Рис. 8) - приём аналоговых значений и публикация уставки:
  • SUBSCRIBE_3 (ID = "239.0.0.1:13201") ловит то, что опубликовал PLC132. На каждое полученное событие IND выходят три значения RD_1..RD_3.
  • SQL_SET_REAL (по одному на каждый канал, параметр NAME = 'ain0', 'ain1', 'ain2') пишет значения в PostgreSQL. Если переменная в БД ещё не существует - она будет создана автоматически при первом вызове. Если задать HIST = TRUE, блок начнёт ещё и архивировать историю в tag_archive.
  • Обратный путь: E_CYCLE (T#1s) → SQL_GET_VAL (NAME = 'aout0') → F_STRING_AS_REAL → PUBLISH_1 (ID = "239.0.0.1:13202"). Раз в секунду читаем уставку из БД (туда её положит оператор через FUXA), конвертируем строку в REAL и публикуем в сеть. PLC132 подписан на этот же multicast и применит её к aout0.
Node2 - приём дискретных сигналов: SUBSCRIBE_4 (ID = "231.0.0.1:60002") → SQL_SET_BOOL для di0..di3. Отдельный multicast-канал для дискретки.

4.5. Маппинг и деплой

Возвращаемся в System Configuration. Перетаскиваем (маппим) PLC132 Application на устройство PLC132, Node1 и Node2 - на node. Элементы окрашиваются в цвет соответствующего устройства. Это и есть маппинг.
Дальше - Online → Connect to System. Если устройства живы и порты совпадают, индикаторы у обоих горят зелёным. Жмём Deploy → Start (▶). Программа улетает в RAM устройств. С этого момента IDE в Online-режиме показывает текущие значения на каждой линии связи в реальном времени - это, пожалуй, самая удобная штука в 4diac: вы буквально видите, как событие пробежало по схеме и какие данные где сейчас лежат.
Пока программа в RAM - после reboot устройства её там не будет. Это нормальный режим отладки. Финальное развёртывание - через Boot-файл, разберём ниже.

Часть 5. Кастомный блок: ST-алгоритм, отладка, экспорт в C++

Базовых блоков обычно не хватает, и стандарт позволяет писать свои. Типов несколько: Basic FB (с алгоритмом на ST и собственным конечным автоматом - ECC), Composite FB (собранный из других FB), Service Interface FB (для нативного взаимодействия с runtime - обычно C++), Simple FB. Самый частый случай - Basic FB.
Сделаем учебный блок NewBlock, который принимает три REAL и возвращает их сумму, среднее, минимум и максимум.

5.1. Интерфейс блока

Правой кнопкой на Type Library/userblock → New → Basic Function Block. Имя - NewBlock. Во вкладке Interface:
  • Входное событие: REQ, с ассоциированными переменными ri1, ri2, ri3 (тип REAL).
  • Выходное событие: CNF, с переменными rmin, rsumm, rmax, rmidl (тип REAL).

5.2. Алгоритм на ST

Создаём алгоритм MATH2 (вкладка Algorithms). Реальный код, который попадает в кодогенерацию FORTE:
Структурированный текст здесь - обычный IEC 61131-3 рев. 2. Полная спецификация - на сайте PLCopen, конкретные ограничения runtime FORTE - в eclipse.dev/4diac/doc.

5.3. ECC - конечный автомат блока

Во вкладке ECC рисуем минимальный автомат с двумя состояниями (Рис. 10):
  • START (начальное) - пустое, ничего не делает.
  • State - выполняет MATH2 и эмитит CNF.
Переходы:
  • START → State по событию REQ.
  • State → START по безусловному условию 1 - то есть сразу после выполнения алгоритма возвращаемся в начальное состояние, готовы ловить следующий REQ.

5.4. Отладка локально

Самое полезное в 4diac IDE - это локальная отладка FB без устройства. Правый клик по типу блока в дереве → Debug As → 1 Debug FB Type запускает runtime прямо на машине разработчика и подключает блок к нему (Рис. 11).
Что доступно:
  • Watch Variables - текущие значения всех переменных блока. Любую можно вручную поменять «на лету».
  • Force Event - отправить REQ руками и посмотреть, что блок выдаст на CNF. Без всякого внешнего железа.
  • Точки останова на переходах ECC - выполнение приостанавливается на переходе, пошагово смотрим, что и почему сработало.
  • Debug Stack - порядок вызовов алгоритмов и событий.
  • Подсветка текущего состояния ECC в реальном времени - то самое визуальное «глаза-смотрят-как-программа-бежит», ради которого многие в IEC 61499 и пришли.

5.5. Экспорт созданного модуля в C++ и сборка под Linux

Чтобы наш блок поехал на Insol-Node, нужно сгенерировать его C++ исходники и подложить в сборку FORTE на устройстве.
В IDE - правой кнопкой на NewBlock → Export, в визарде выбираем 4diac IDE → 4diac IDE Type Export, экспортер 4diac FORTE 3.x, целевая папка - рабочий каталог сборки. На выходе получаем два файла: NewBlock.cpp и NewBlock.h.
Дальше - web-интерфейс INSOL Node → Forte → Сборки Forte3 → выбираем активную сборку → Сборка. Включаем чекбокс рядом с NewBlock в списке «Использовать ФБ при компиляции», сохраняем, жмём «Компилировать». Статус сменится на «Скомпилирован» - это значит, что блок собран в новый бинарник FORTE и зарегистрирован в реестре типов. Перезапускаем сервис ▶ - и NewBlock теперь доступен в IDE наравне со стандартными библиотечными блоками. Можно перетаскивать на схему.

Часть 6. Верхний уровень: PostgreSQL → OPC UA → FUXA

Это та часть, ради которой Insol-Node, собственно, и существует. В типичном проекте АСУТП «верхним уровнем» обычно занимается отдельный сервер с разнородной обвязкой: лицензионная SCADA ( WinCC, MasterSCADA и пр.), отдельный OPC-сервер вроде KEPServerEX, historian, СУБД, веб-сервер для удалённого доступа к HMI, плюс прослойка пользователей и прав, средства мониторинга, отчётный модуль. Каждый компонент - свой инсталлятор, своя лицензия, свой формат конфигурации, свой канал техподдержки. Половину времени проекта уходит на то, чтобы все эти кусочки начали разговаривать друг с другом.
Insol-Node - это всё то же самое, но в одной коробке, под одной web-консолью. На Linux-устройстве уже предустановлено и работает:
  • 4diac FORTE runtime - собственно среда исполнения IEC 61499. То, ради чего мы и пришли.
  • PostgreSQL - встроенная промышленная СУБД. Переменные создаются автоматически блоками SQL_SET_*; ничего заранее настраивать не нужно. Архивные данные, журналы событий, конфигурации - всё здесь.
  • OPC UA сервер (open62541) - самый распространённый промышленный стандарт интеграции. Автоматически экспонирует всё, что есть в PostgreSQL. Поддерживает Historical Access - внешняя SCADA или MES получат и реальное время, и историю.
  • FUXA SCADA - open-source веб-SCADA/HMI. Редактор мнемосхем работает прямо в браузере, никакого Windows-клиента ставить не нужно. Доступ с планшета, телефона, любой машины в сети.
  • Modbus TCP-клиент (libmodbus) - для интеграции с полевыми устройствами сторонних производителей: частотными приводами, счётчиками электроэнергии, расходомерами и прочей классикой.
  • Web Server Insol-Node - единая web-консоль, в которой управляется всё сразу: пользователи и права доступа, сервисы FORTE и их сборки, настройки OPC UA, доступ к SCADA, отчёты, диагностика сети, обзор подключённых устройств.
Под капотом - open-source стек везде, где это возможно: PostgreSQL, open62541, FUXA, 4diac FORTE. Никаких подписок «за каждый тег», лицензий на клиентские подключения и и на хранение архивов (истории). Один разовый платёж за железо - и интеграционный слой собран.
Что важно для проектировщика: компоненты уже сшиты между собой по реальным шинам, а не по бумажным схемам. Блок SQL_SET_REAL положил значение → PostgreSQL немедленно отдал его в OPC UA → подписанный клиент SCADA получил уведомление → точка на тренде нарисовалась. Все три шага происходят без вашего участия и без единой строчки кода.
Минимальный проект АСУТП, который раньше требовал сервера с Windows, SCADA-лицензии, KEPServerEX, отдельной СУБД и недели настройки сетки между ними - здесь собирается за пару часов и помещается в DIN-реечный модуль.
Дальше - что именно даёт каждый компонент.

6.1. PostgreSQL

В Node предустановлен PostgreSQL и небольшая обвязка над ним. Блоки SQL_SET_* сделаны так, что они сами создают переменную в БД при первом обращении - не нужно заранее лезть в PostgreSQL и делать CREATE TABLE.
Раздел «Источники» в Insol NET (Рис. 12): ain0..ain2 (Float, добавлены автоматически блоком SQL_SET_REAL), aout0 (Float, добавлен вручную как уставка), di0..di3 (Bool, тоже автоматически). Колонка «Обновлено» показывает реальный темп прихода данных.
Поддерживаемые блоки:
Обратите внимание: уставки оператора (то, что не приходит из 4diac, а вводится в SCADA) добавляются в БД руками - через web-интерфейс Insol-Node, который под капотом просто пишет в ту же таблицу. А потом 4diac читает их обратно через SQL_GET_VAL.

6.2. OPC UA - без настройки

Всё, что лежит в PostgreSQL, автоматически публикуется встроенным OPC UA сервером (open62541) на стандартном порту 4840. Пространство имён и политику безопасности можно подкрутить в web, но для старта достаточно дефолтов: Security Mode: None, endpoint opc.tcp://192.168.0.176:4840.
Архивные данные для переменных с HIST=TRUE отдаются через OPC UA Historical Access - это значит, что SCADA сможет рисовать тренды не только по «живым» данным, но и по истории.

6.3. FUXA - мнемосхема в браузере

FUXA - это open-source веб-SCADA/HMI на Angular (есть на GitHub: frangoteam/FUXA). Поддерживает OPC UA, Modbus TCP/RTU, MQTT, прямой коннект к PostgreSQL/SQLite/InfluxDB. На Insol-Node она уже установлена и запущена - открываем http://192.168.0.176:1881.
Шаги настройки выглядят так:
Подключение OPC UA. В режиме Editor → шестерёнка → Connections → + → OPC UA:
Name:
opcnode
Endpoint URL:
opc.tcp://192.168.0.176:4840
Security:
None
Connect → статус Connected → Save.
Теги. В разделе Tags добавляем по тегу на каждую переменную, выбирая узлы из дерева OPC UA.
Browse Tags in Server в FUXA (Рис. 13): под Objects → opcserver видны ain0..ain2 (Float, R, R) и aout0 (Float, R/W, R/W). Атрибуты доступа берутся прямо из OPC UA - FUXA понимает, какие переменные можно писать, а какие только читать.
Имя тега обычно совпадает с алиасом канала на INSOL-1000 - так проще трассировать:
Мнемосхема. В Pages создаём страницу MainView. Из палитры тянем элементы:
  • Gauge для ain0 - диапазон 4...20 (если в «сырых» миллиамперах) или 0...100 (в физических единицах, если конвертация уже сделана на стороне 4diac). Цветовые зоны зелёная/жёлтая/красная - норма/предупреждение/авария.
  • Switch для do0. Поскольку тег R/W, при клике FUXA пишет новое значение в OPC UA. Дальше оно попадает в PostgreSQL, оттуда SQL_GET_VAL забирает его на Insol-1000 и переключает физический выход. Логически - обычное «нажал кнопку - лампа загорелась», но цепочка под капотом длинная: браузер → OPC UA → БД → FORTE на Node → publish → subscribe → FORTE на PLC132 → QB → реле.
  • Chart для трендов. Источник - либо OPC UA Historical Access (если переменная заведена с HIST=TRUE), либо встроенный DAQ в FUXA (она сама может писать значения тегов в SQLite и строить тренды из него). Второе удобнее, когда нужен быстрый дашборд без перенастройки 4diac.
Финальный вид мнемосхемы в режиме просмотра (Рис. 14). aout0 = 4.589 mA - это уставка, заданная оператором; ain0..ain2 - аналоговые входы с физического Insol-1000. Цветовые зоны 4...20 мА с переходом красный/жёлтый/зелёный.
Сохраняем (Save), переключаемся в режим View. Частота обновления - по умолчанию 1 секунда, настраивается per-tag. Готовую мнемосхему можно открыть напрямую по http://192.168.0.176:1881/lab - например, с планшета в полноэкранном режиме.

Часть 7. Boot-файл - переходим в режим «работает само»

Пока мы всё деплоили в RAM. Чтобы система оживала сама после reboot устройства, нужен *.fboot файл. XML структура описывающая все используемые блоки в проекте и связи между ними.
В IDE: правой кнопкой на Application → Create Boot File. Для каждого устройства генерируется свой .fboot. Дальше:
  1. Insol-1000: web-интерфейс → «Сервисы» → загружаем *.fboot для PLC132.
  2. Insol-Node: настройки сервиса 4diac FORTE → в поле Forte bootfile выбираем загруженный *.fboot для node, включаем «Автозапуск».
  3. Перезагружаем оба устройства.
Runtime при старте обнаруживает .fboot и поднимает приложение. Подключение IDE больше не требуется - система автономна.
! На этапе отладки всегда удаляйте Boot-файл с устройства перед очередным Deploy. Иначе FORTE поднимется с .fboot-версии, проигнорирует только что задеплоенную из IDE, и вы будете долго ловить «фантомные» отличия.

Часть 8. Что в итоге

Что получилось из коробки:
  • Распределённая система без центрального ПЛК. Полевая логика (опрос I/O, отображение на OLED, аналоговый выход) живёт на STM32H с FreeRTOS. Архив, SCADA и интеграционный слой - на Linux-шлюзе. Связь - UDP multicast в одном Ethernet-сегменте.
  • Одна программа на все устройства. Описана один раз в 4diac IDE, разрезается через маппинг. Online-отладка показывает значения на всех линиях схемы в реальном времени - без отдельных средств трассировки.
  • Стандартизованный верх. OPC UA сервер с историческим доступом, готовый к подключению любой нормальной SCADA или MES. FUXA встроена как референсный HMI, но никто не мешает подключить ту же условную МастерСкаду или WinCC.
  • Расширяемость через свои блоки. Удобный инструмент компиляции собственных наработок. Basic FB → ST → отладка локально → экспорт в C++ → сборка на устройстве → доступен в IDE. Цикл «придумал блок - встроил в библиотеку» - минут за двадцать.
Где это не "серебряная пуля":
  • IEC 61499 всё ещё непривычен - инженеров, которые уверенно его читают, на порядок меньше, чем спецов по классическому 61131-3.
  • Multicast накладывает требования на сеть: managed-коммутаторы с поддержкой IGMP snooping, никаких «домашних» свитчей в продакшене.
  • Гарантированной доставки нет - для критичных сигналов управления вы строите свой ACK-протокол поверх PUBLISH/SUBSCRIBE.
  • Online-реконфигурация - мощная штука, но требует дисциплины: «горячую подмену» работающего алгоритма легко превратить в недокументированный инцидент.

Полезные ссылки

  • Сборка 4diac IDE с библиотекой Insol и тестовый проект - insolsoft.ru → Техподдержка → ПО 4diac
  • Оригинальный 4diac - eclipse.dev/4diac
  • Концепция IEC 61499 в документации Eclipse - eclipse.dev/4diac/doc/intro/iec61499.html
  • FUXA SCADA - github.com/frangoteam/FUXA
  • Спецификация ST - plcopen.org
]]>