Обзор современных протоколов в системах промавтоматики

    image

    В прошлой публикации мы рассказали о том, как работают шины и протоколы в промышленной автоматизации. В этот раз сфокусируемся на современных рабочих решениях: посмотрим, какие протоколы используются в системах по всему миру. Рассмотрим технологии немецких компаний Beckhoff и Siemens, австрийской B&R, американской Rockwell Automation и русской Fastwel. А также изучим универсальные решения, которые не привязаны к конкретному производителю, такие как EtherCAT и CAN. 


    В конце статьи будет сравнительная таблица с характеристиками протоколов EtherCAT, POWERLINK, PROFINET, EtherNet/IP и ModbusTCP.


    Мы не включали в обзор протоколы PRP, HSR, OPC UA и другие, т.к. по ним на Хабре уже есть отличные статьи наших коллег-инженеров, которые занимаются разработкой систем промавтоматики. Например, «Протоколы «бесшовного» резервирования PRP и HSR» и «Шлюзы промышленных протоколов обмена на Linux. Собери сам».


    Для начала определим терминологию: Industrial Ethernet = промышленная сеть, Fieldbus = полевая шина. В российской промышленной автоматике случается путаница в терминах, касающихся полевой шины и промышленной сети нижнего уровня. Часто эти термины объединяются в единое расплывчатое понятие «нижний уровень», который именуется и полевой шиной, и шиной нижнего уровня, хотя это может быть и не шина вовсе.

    Почему так?
    Такая путаница, скорее всего связана с тем, что во многих современных контроллерах соединение модулей ввода-вывода часто реализуется с помощью объединительной панели (англ. backplane) или физической шины. То есть используются некие шинные контакты и соединители, чтобы объединить несколько модулей в единый узел. Но такие узлы, в свою очередь, могут быть соединены между собой как промышленной сетью, так и полевой шиной. В западной терминологии есть четкое разделение: сеть — это сеть, шина — это шина. Первое обозначается термином Industrial Ethernet, второе — Fieldbus. В статье для этих понятий предлагается использоваться термин «промышленная сеть» и термин «полевая шина» соответственно.

    Стандарт промышленной сети EtherCAT, разработка компании Beckhoff


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


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




    Контроллер Beckhoff с набором модулей ввода-вывода. Источник: www.beckhoff.de

    Спецификация протокола открыта и доступна, но только в рамках ассоциации разработки — EtherCAT Technology Group.


    Вот, как работает EtherCAT (зрелище завораживает, как игра Zuma Inca):




    Высокая скорость обмена в этом протоколе —а речь может идти о единицах микросекунд— реализована благодаря тому, что разработчики отказались от обмена с помощью телеграмм, посылаемых непосредственно конкретному устройству. Вместо этого в сеть EtherCAT направляется одна телеграмма, адресованная всем устройствам одновременно, каждый из подчиненных узлов сбора и передачи информации (их еще часто называют УСО — устройство связи с объектом) забирает из нее «на лету» те данные, которые предназначались ему, и вставляет в телеграмму данные, который он готов предоставить для обмена. После этого телеграмма отправляется следующему подчиненному узлу, где происходит та же операция. Пройдя все УСО, телеграмма возвращается главному контроллеру, который на основе полученных от подчиненных устройств данных, реализует логику управления, опять же взаимодействуя посредством телеграммы с подчиненными узлами, которые выдают управляющий сигнал на оборудование.


    Сеть EtherCAT может иметь любую топологию, но по сути это всегда будет кольцо — из-за использования полнодуплексного режима и двух разъемов Ethernet. Таким образом, телеграмма всегда будет передаваться последовательно каждому устройству на шине.




    Схематичное представление сети Ethercat с несколькими узлами. Источник: realpars.com

    Кстати, спецификация EtherCAT не содержит ограничений физического уровня 100Base-TX, поэтому реализация протокола возможна на основе гигабитных и оптических линий.


    Открытые промышленные сети и стандарты PROFIBUS/NET компании Siemens


    Немецкий концерн Siemens давно известен своими программируемыми логическими контроллерами (ПЛК), которые используется по всему миру.


    Обмен данными между узлами автоматизированной системы под управлением оборудования Siemens реализуется как по полевой шине, которая называется PROFIBUS, так и в промышленной сети PROFINET.


    Шина PROFIBUS использует специальный двужильный кабель с разъемами DB-9. У Siemens он фиолетовый, но мы на практике встречали и другие :). Для связи нескольких узлов разъем может соединять два кабеля. Также в нем есть переключатель для терминального резистора. Терминальный резистор должен быть включен на концевых устройствах сети, таким образом сообщается, что это первое или последнее устройство, а после него уже ничего нет, только мрак и пустота (все rs485 так работают). Если на промежуточном разъеме включить резистор, то следующий за ним участок будет отключен.




    Кабель PROFIBUS с соединительными разъемами. Источник: VIPA ControlsAmerica

    В сети PROFINET используется аналог витой пары, как правило, с разъемами RJ-45, кабель окрашен в зеленый цвет. Если топология PROFIBUS —шина, то топология сети PROFINET может представлять собой что угодно: хоть кольцо, хоть звезду, хоть дерево, хоть все вместе взятое.




    Контроллер Siemens с подключенным кабелем PROFINET. Источник: w3.siemens.com

    Существуют несколько протоколов обмена по шине PROFIBUS и в сети PROFINET.


    Для PROFIBUS:


    1. PROFIBUS DP — реализация этого протокола подразумевает связь с удаленными подчиненными устройствами, в случае с PROFINET этому протоколу соответствует протокол PROFINET IO.
    2. PROFIBUS PA — является по сути тем же PROFIBUS DP, только используется для взрывобезопасных исполнений передачи данных и питания (аналог PROFIBUS DP с другими физическими свойствами). Для PROFINET взрывобезопасного протокола по аналогии с PROFIBUS пока не существует.
    3. PROFIBUS FMS — предназначен для обмена данными с системами других производителей, которые не могут использовать PROFIBUS DP. Аналогом PROFIBUS FMS в сети PROFINET является протокол PROFINET CBA.

    Для PROFINET:


    1. PROFINET IO;
    2. PROFINET CBA.

    Протокол PROFINET IO делится на несколько классов:


    • PROFINET NRT (без реального времени) — используется в приложениях, где временные параметры не критичны. В нем используется протокол передачи данных Ethernet TCP/IP, а также UDP/IP.
    • PROFINET RT (реальное время) — тут обмен данными ввода/вывода реализован с помощью фреймов Ethernet, но диагностические данные и данные связи все еще передаются через UDP/IP. 
    • PROFINET IRT (изохронное реальное время) — этот протокол был разработан специально для приложений управления движением и включает в себя изохронную фазу передачи данных.

    Что касается реализации протокола жесткого реального времени PROFINET IRT, то для коммуникаций с удаленными устройствами в нем выделяют два канала обмена: изохронный и асинхронный. Изохронный канал с фиксированной по времени длиной цикла обмена использует тактовую синхронизацию и передает критичные ко времени данные, для передачи используются телеграммы второго уровня. Длительность передачи в изохронном канале не превышает 1 миллисекунду.


    В асинхронном канале передаются так называемые real-time-данные, которые тоже адресуются посредством MAC-адреса. Дополнительно передается различная диагностическая и вспомогательная информация уже поверх TCP/IP. Ни real-time-данные, ни тем более другая информация, разумеется, не может прерывать изохронный цикл.


    Расширенный набор функций PROFINET IO нужен далеко не для каждой системы промышленной автоматики, поэтому этот протокол масштабируют под конкретный проект, с учетом классов соответствия или классов применения (conformance classes): СС-A, CC-B, CC-CC. Классы соответствия позволяют выбрать полевые устройства и магистральные компоненты с минимально необходимой функциональностью. 




    Источник: PROFINET university lesson

    Второй протокол обмена в сети PROFINET — PROFINET CBA — служит для организации промышленной связи между оборудованием различных производителей. Основной производственной единицей в системах СВА является некая сущность, которая называется компонентом. Этот компонент обычно представляет собой совокупность механической, электрической и электронной части устройства или установки, а также соответствующее прикладное программное обеспечение. Для каждого компонента выбирается программный модуль, который содержит полное описание интерфейса данного компонента по требованиям стандарта PROFINET. После чего эти программные модули используются для обмена данными с устройствами. 


    Протокол Ethernet POWERLINK компании B&R


    Протокол Powerlink разработан австрийской компанией B&R в начале 2000-х. Это еще одна реализация протокола реального времени поверх стандарта Ethernet. Спецификация протокола доступна и распространяется свободно. 


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




    Контроллер B&R с набором модулей ввода-вывода. Источник: br-automation.com

    Изначально протокол был реализован поверх физического уровня 100Base-TX, но позже была разработана и гигабитная реализация.


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




    Схематическое представление сети Ethernet POWERLINK с несколькими узлами.

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


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


    Протокол Ethernet/IP компании Rockwell Automation


    Протокол EtherNet/IP разработан при активном участии американской компании Rockwell Automation в 2000 году. Он использует стек TCP и UDP IP, и расширяет его для применения в промышленной автоматизации. Вторая часть названия, вопреки расхожему мнению, означает не Internet Protocol, а Industrial Protocol. UDP IP использует коммуникационный стек протокола CIP (Common Interface Protocol), который также используется в сетях ControlNet / DeviceNet и реализуется поверх TCP/IP.


    Спецификация EtherNet/IP является общедоступной и распространяется бесплатно. Топология сети Ethernet/IP может быть произвольной и включать в себя кольцо, звезду, дерево или шину.


    В дополнение к стандартным функциям протоколов HTTP, FTP, SMTP, EtherNet/IP реализует передачу критичных ко времени доставки данных между опрашивающим контроллером и устройствами ввода/вывода. Передача некритичных ко времени данных обеспечивается пакетами TCP, а критичная ко времени доставка циклических данных управления идет по протоколу UDP. 


    Для синхронизации времени в распределенных системах EtherNet/IP использует протокол CIPsync, который является расширением коммуникационного протокола CIP.






    Схематическое изображение сети Ethernet/IP с несколькими узлами и подключением Modbus-устройств. Источник: www.icpdas.com.tw

    Для упрощения настройки сети EtherNet/IP большинство стандартных устройств автоматики имеют в комплекте заранее определенные конфигурационные файлы.


    Реализация протокола FBUS в компании Fastwel


    Долго думали, включать ли в этот список российскую компанию Fastwel с ее отечественной реализацией промышленного протокола FBUS, но потом все же решились написать пару абзацев для лучшего понимания реалий импортозамещения.


    Существует две физические реализации FBUS. Одна из них — это шина, в которой протокол FBUS работает поверх стандарта RS485. Кроме этого есть реализация FBUS в промышленной сети Ethernet.


    FBUS сложно назвать быстродействующим протоколом, время ответа сильно зависит от количества модулей ввода-вывода на шине и от параметров обмена, обычно оно колеблется в пределах 0,5—10 миллисекунд. Один подчиненный узел FBUS может содержать только 64 модуля ввода-вывода. Для полевой шины длина кабеля не может превышать 1 метр, поэтому о распределенных системах речь не идет. Вернее идет, но только при использовании промышленной сети FBUS поверх TCP/IP, что означает увеличение времени опроса в несколько раз. Для подключения модулей могут использоваться удлинители шины, что позволяет удобно расположить модули в шкафу автоматики.




    Контроллер Fastwel с подключенными модулями ввода-вывода. Источник: Control Engineering Россия



    Итого: как всё это используется на практике в АСУ ТП


    Естественно, видовое разнообразие современных промышленных протоколов передачи данных намного больше, чем мы описали в этой статье. Некоторые привязаны к конкретному производителю, некоторые, напротив, универсальны. При разработке автоматизированных систем управления технологическим процессом (АСУ ТП) инженер выбирает оптимальные протоколы, с учетом конкретных задач и ограничений (технических и по бюджету).


    Если говорить о распространенности того или иного протокола обмена, то можно привести диаграмму компании HMS Networks AB, которая иллюстрирует доли рынка различных технологий обмена в промышленных сетях.





    Источник: HMS Networks AB

    Как видно на диаграмме, PRONET и PROFIBUS от Siemens занимают лидирующие позиции.


    Интересно, что 6 лет назад 60% рынка занимали протоколы PROFINET и Ethernet/IP.

    В таблице ниже собраны сводные данные по описанным протоколам обмена. Некоторые параметры, например, производительность выражены абстрактными терминами: высокая /низкая. Числовые эквиваленты можно отыскать в статьях по анализу производительности. 



     


    EtherCAT


    POWERLINK


    PROFINET


    EtherNet/IP


    ModbusTCP


    Физический уровень


    100/1000 BASE-TX


    100/1000 BASE-TX


    100/1000 BASE-TX


    100/1000 BASE-TX


    100/1000 BASE-TX


    Уровень передачи данных


    Канальный (Ethernet-фреймы)


    Канальный (Ethernet-фреймы)


    Канальный (Ethernet-фреймы), Сетевой/транспортный(TCP/IP)


    Сетевой/транспортный(TCP/IP)


    Сетевой/транспортный(TCP/IP)


    Поддержка реального времени


    Да


    Да


    Да


    Да


    Нет


    Производительность


    Высокая


    Высокая


    IRT – высокая, RT – средняя


    Средняя


    Низкая


    Длина кабеля между узлами


    100м


    100м/2км


    100м


    100м


    100м


    Фазы передачи


    Нет


    Изохронная + асинхронная


    IRT – изохронная + асинхронная, RT – асинхронная


    Нет


    Нет


    Количество узлов


    65535


    240


    Ограничение сети TCP/IP


    Ограничение сети TCP/IP


    Ограничение сети TCP/IP


    Разрешение коллизий


    Кольцевая топология


    Тактовая синхронизация, фазы передачи


    Кольцевая топология, фазы передачи


    Коммутаторы, топология “звезда”


    Коммутаторы, топология “звезда”


    Горячая замена


    Нет


    Да


    Да


    Да


    В зависимости от реализации


    Стоимость оборудования


    Низкая


    Низкая


    Высокая


    Средняя


    Низкая



    Области применения описанных протоколов обмена, полевых шин и промышленных сетей очень разнообразны. Начиная от химической и автомобильной промышленности и заканчивая аэрокосмическими технологиями и производством электроники. Быстродействующие протоколы обмена востребованы в системах real-time позиционирования различных устройств и в робототехнике.


    А с какими протоколами вы работали и где применяли? Делитесь в комментариях своим опытом. :)

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 54

      +1

      По EtherCAT у вас немного неточная информация:


      Сеть EtherCAT успешно используется в распределенных системах автоматизации, где взаимодействующие узлы разнесены на большое расстояние.

      Скажем так — EtherCAT — это как раз та самая полевая шина, предназначенная для связи центрального контроллера с множеством разнесенных I/O. Это не сеть для равнозначных узлов или распределенных вычислений.


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

      Это очень неоднозначное определение и может привести к непониманию. Во первых инкапсуляция информации в фреймы там да, сделана по стандарту Ethernet и физический уровень там 100Base-TX. Но на этом сходство с Ethernet заканчивается. Вы не можете использовать Ethernet свичи или топологии построения сетей, обычно используемые для Ethernet. Также вы не можете использовать стандартный Ethernet c EtherCAT в одной сети.
      Использование стандарта и физического уровня Ethernet позволит вам использовать обычную PC-шную плату Ethernet контроллера в качестве мастера сети, но не в случае слейвов — там нужен специфичный контроллер с двумя EtherCAT портами.


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


      ПС мы применяем очень серьезно EtherCAT и CANopen. В подстанциях сейчас развивается IEC61850

        0

        Как практически решается задача контроля целостности кадра на лету? Насколько я понимаю, кадр ещё не успевает даже приняться, а его уже надо на лету передавать дальше?

          0

          Да. Но там все просто — каждый кадр сопровождается CRC. Если CRC принятого фрейма в порядке, то ничего не происходит. Если же принятый кадр поврежден, то передаваемый тоже искусственно повреждается путем искажения его CRC. Но искажение CRC делается таким образом, что следующий слейв может определить — именно этот фрейм испорчен, или этот фрейм нормальный, но предыдущий слейв специально испортил кадр. И дальше оно передается по кругу до самого мастера.

          0
          Использование стандарта и физического уровня Ethernet позволит вам использовать обычную PC-шную плату Ethernet контроллера в качестве мастера сети, но не в случае слейвов — там нужен специфичный контроллер с двумя EtherCAT портами.

          Но по идее можно использовать две PC сетевые карты… и на них эмулировать EtherCAT.
            0

            Можно, но так мало кто делает.

              0
              Эмулировать можно, но обычные PC сетевые карты как правило не отдадут пакет пока не примут целиком, что вызовет большие задержки.
                0

                Мало того — они не смогут сгенерировать этот пакет "налету" так как каждый слейв должен поменять как минимум один байт в отдаваемом пакете(т.н. Working Counter — по нему мастер определяет не изменилась ли топология сети) и соответственно пересчитать СRC. Поэтому слейв — это обычно ПЛИС или специализированный ASIC, который может быть отдельно, либо в составе микроконтроллера..

            –1

            OPC UA сейчас мигрирует в сторону поддержки time-sensitive network и претендует постепенно вытеснить powerlink.
            Поддержка кастомных (своих) устройств powerlink есть. Диссектор для wireshark также свободно доступен для скачивания.

              0
              OPC UA протокол прикладного уровня и соответственно не может сравниваться с Пауерлинком и подобными. Все= что противопоставлять HTTP Ethernet'у.
                0

                Про приставку TSN забыли, из-за неё принцип работы совершенно меняется по сравнению с "обычным" OPC UA.

                  0
                  Я забыл???
                  Да и рано про это говорить. Вики
                  Ноябрь 2018: На выставке SPS IPC Drives 2018 представлено первое рабочее устройство на базе технологии OPC UA TSN.
                0

                TSN уже давно развивается и развивается, а все до нормального уровня дойти не может.

                +1

                Кстати в начале статьи обещали CAN — а ведь там много чего интересного есть: DeviceNet, CANopen, а в итоге остановились на Ethernet. Про Profibus вообще забыли.

                  0
                    0

                    Да, модель CANopen много где в основах сидит. В том же EtherCAT о ней много упоминаний.

                    –2
                    Потому что они устаревшие, все эти DataHighway, DeviceNet, ProfiBus; а статья о современных, эти — out of scope.
                    Ethernet/IP — тема не раскрыта.
                    По Ethetcat у infineon мне приглянулся в своё время SDK, там много всего описано. Опять же — habr != rtfm, поэтому по Ecat тут как раз столько, сколько надо для «популяризации».
                    Хочу друга заставить статью написать по Ethernet/IP, уже даже попросил его это сделать несколько дней назад, а тут такая статья как раз :) Думаю — об управлении кинематикой стоит написать. В РФ эта тема не очень популярна, но всё поменяется, я надеюсь.
                      0

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

                        0
                        Много раз видел картину. Есть линия, ее запустили интеграторы с запада. Говорю: «давайте посмотрю, почему не работает». Ответ всегда нет. А потом созвоны, попытки решить своими силами. Линия стоит. Приезжает спец, нажимает пару кнопок. Линия запускается. Сейчас не интеграторы виноваты. А те кто даже линию производства ПРОДАЮТ КАК СЕРВИС.
                          0

                          Ну вы ж хотели как дешевле? А дешевле оно только как сервис и только на проприетарщине. Я много таких распределенных систем видел для покупки. Спрашиваешь:


                          • Что у вас за протокол?
                          • CAN, все чики-пуки
                          • А над CAN что?
                          • Нуу… наш протокол.
                          • Спасибо, до свиданья.

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

                            0
                            В «дешевле» вот такие «командировочки» заложены. С другой стороны, свою цену станок отбивает в первые пару лет, а типичный срок службы электроники в автоматизации — не менее десяти.
                    +4

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


                    Я не знаю на кого это рассчитано, но сопротивление нужно для согласования волнового сопротивления кабеля. Чтобы устранить интерференции. Электрический сигнал не может увидеть физическое сопротивление. И да. 485 линия на расстоянии 100 метров прекрасно работает и без этого сопротивления в начале и в конце. Есть конечно исключения, в виде частотных преобразователей. Но из практики вот так.

                      0

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

                      0
                      Статья настолько же обзорная, как рассказ про пестики-тычинки =) Минус

                      P.S.И даже при такой поверхностности, не коснулись даже всех протоколов из приведенных иллюстраций.
                      P.P.S А еще забыты целые разделы сетей «умного дома» типа BACnet, и новых разработок для IoT
                        0
                        Ребята, подскажите, кто в теме. Есть ли смысл сдавать на CCNA Industrial? Сдавал ли кто-нибудь?
                        Сам работаю Embedded разработчиком и программистом PLC. Думаю, что это хороший вариант для повышения квалификации, так как подобные курсы и сертификация от, например, Siemens стоят в разы дороже.
                          +1

                          Материал, посвящённый протоколу FBUS от Fastwel, мягко говоря, не соответствует действительности


                          Представленная информация об FBUS вроде той, что "подчиненный узел FBUS может содержать только 64 модуля ввода-вывода" вводит в заблуждение непосвященных читателей


                          FBUS это не "отечественная реализация промышленного протокола FBUS", это собственный протокол межмодульной шины для ПЛК Fastwel I/O, который был разработан в 2002 г. задолго до начала импортозамещания и никогда не претендовал на статус "промышленного протокола"


                          Просьба к авторам, перед публикацией не полениться и ознакомиться с предметом публикования, благо в интернете есть практически полное описание того, что такое FBUS https://www.cta.ru/cms/f/352126.pdf

                            0

                            Вспомнился Schneider со своим ERIO — реально это CIP (хоть они и не афишируют). А протоколы и шины самих контроллерных корзин и корзин ввода-вывода — уже коммерческая тайна вендоров.

                              0
                              … Хорошо что в России распространенность протоколов выглядит слегка иным образом…
                                0

                                Почему это хорошо?

                                  0
                                  Это хорошо тем, чо порог вхождения в автоматизацию существенно ниже, ведь в нашей стране абсолютное большинство автоматизации это Modbus и его производные.
                                  Можно долго спорить 80,90 или 95% автоматизации в России это Modbus, но достаточно открыть сайт хэдхантер чтобы понять, что если бы у нас был расклад как на прилагаемой картинке — то в автоматизации было бы от силы человек 300 на всю страну. А так, " автоматизация в каждый дом"
                                    0
                                    Довольно самонадеянное заявление. Хотя бы разделение рынка по производителям знать…

                                    Модбас это конечно как английский язык — все его понимают, но он чаще вторичный протокол, чем основной.

                                    Для Модбаса — реалтайм — нет, синхронизация времени — нет, уведомлений нет, обменной модели тоже нет — довольно таки устарел.
                                      0
                                      Конечно устарел, и Schneider Electric уже вместе со всем западом загнулась в ленту мёбиуса
                                      .
                                      Достаточно странное заявление о знании разделение рынка по производителям.
                                      Для начала надо бы огородить Какого рынка. Какой автоматизации. Потом пойти на сайт хэдхантера и попытаться опровергнуть простым набором букв в поиск. по очереди каждого из протоколов. Не сильно репрезентативная операция, но хотя бы Порядок специалистов с знаниями разных протоколов может дать. И этот порядок говорит о подавляющем доминировании модбаса на нашем рынке.

                                      Интересно, а читать на английском языке крайние спецификации хотя бы 2015 года никто не пытался? Вера совсем не позволяет?

                                      Или как некоторые производители — прочитали стандарт 1996 года. и «не делайте так больше, это устаревшая модель для легаси, дальше поддерживать не надо и даже не пытайтесь, это пришло со времён релейной логики» приняли за " ух ты, а модбас это только так и ни как иначе" (с)
                                        0

                                        Modbus RTU — вполне себе реалтаймовый протокол. Только медленный.


                                        довольно таки устарел

                                        Что предложите взамен на RS485?

                                          +1
                                          Я скорее имел в виду отсутствие реалтаймовых расширений в Modbus TCP.

                                          Для шинных соединений я бы предложил рассматривать CAN bus и его производные — DeviceNet, для телемеханики IEC60870-5-101. Хотя сильно зависит от задачи.
                                            0
                                            … На уровне CAN bus есть даже интересные попытки Российской компании IRIDIUM сделать Универсальный протокол автоматизации зданий — bus77.
                                            (и видимо я один из первых сторонних попытался получить прошивку под модуль интеграции к оному).

                                            А так то рано или поздно взамен физики rs485 придет что-то другое, это очевидно.

                                            Гложат, конечно, сомнения что это что-то будет существенно более сложное чем текущие массовые реализации. Есть склонность считать что маятник прогресса пока движется в сторону упрощения.

                                              0
                                              А так то рано или поздно взамен физики rs485 придет
                                              Все придумано до нас. Ethernet — Оптика на большие расстояния, медь на малые. Но для реалтайма не подходит.
                                                0
                                                взамен физики rs485 придет что-то другое, это очевидно

                                                Тут надо решить — оставаться на шинной архитектуре (т.е. пассивная общая шина, доступная всем узлам в режиме TDM) или переходить на switch-технологии (т.е. посередине активный свитч, занимающийся пересылкой пакетов от узлов, имеющих индивидуальные соединения с ним)
                                                CAN и RS485 относятся к первым. Ethernet — ко вторым. Понятно, что основной фактор — стоимость активных компонентов. В switch-технологии количество трансиверов как минимум в два раза больше. Т.е. она будет как минимум в два раза дороже. Но и скорости можно достичь гораздо более высокие. Но всем ли это нужно?


                                                А физический уровень Ethernet прекрасно подходит для реалтайма, если его правильно использовать — тот же EtherCAT тому пример.

                                                  0
                                                  Что мешает в каждую железку по свичу на 2 порта поставить? Там удорожание то копеечное при современной электронике. У Овна кстати так и сделано.
                                                    0

                                                    Жабка мешает. Железки-то бывают довольно примитивные — например 8 логических входов или выходов. А тут на тебе — свич на два порта с обвязкой.

                                                      0
                                                      Изначально когда писал ТЗ на mx210 то предполагал модули Anybus.
                                                      Удивитесь но это для данного сегмента слишком дорого. Ну и убеждать приходилось чуть ли не полгода, и то не «пробил». В результате они имеют то что имеют и переключатели с хорошей схемой.

                                                      Я это к тому, что Массовое применение сети связи для диспетчеризации и автоматизации это для
                                                      меня скажем примерно в цифрах начинается от 200 000 устройств в месяц плюс-минус. Какого либо рода устройств диспетчеризации и автоматизации
                                                      Если про более менее открытые протоколы — то примерно в 200 интеграций в месяц с Большими системами посредством Modbus.

                                                      При этом читать что — то про EtherCAT Profibus и прочие протоколы мягко говоря немного странно.
                                                        0

                                                        Ничего не понял.

                                                          0
                                                          Видимо витиевато написал, прошу простить.
                                                          первая часть это собственно ответ про Овен, там надеюсь понятно.
                                                          вторая часть — про то, что протоколов и интерфейсов строго говоря Весьма много.
                                                          Если Более развернуто, то
                                                          И если писать про какую-либо часть рынка — надо обозначить какие-либо характеристики — количества устройств, цены устройств.Я примерно обозначил.

                                                          В этих цифрах Если сравнить протоколы по применяемости — то к примеру Два Больших применения KNX и Backnet в Башне Федерации ( крупнейшие в Европе) не дали по сути никакой доли применений в рынок. Потому как они сделаны раз в 10 лет когда рынок Автоматизации и Диспетчеризации ежедневно потребляет тысячи устройств.

                                                          Соответственно основная проблема любых интерфейсов и протоколов — это
                                                          1) цена
                                                          2) наличие компетенций у инсталяторов

                                                          И если с ценой всё ещё решаемо, то с уровнем знаний все не так однозначно. С моей точки зрения, к примеру — есть явная тенденция на упрощение. То-есть интерфейсы и протоколы должны быть проще в применении чем текущие масс-применения.
                                                          ethernet сложнее RS485.
                                                          объективно два провода сложнее 8-и со специальной обжимкой и наконечниками. Про оптику там вообще не массовый сегмент ещё (а жаль).

                                                          Если коротко и объективно — Ethernet лучше 485? да. сложнее? да.
                                                          как скоро Ethernet -а будут протягивать в сетях автоматизации хотя бы примерно столько же сколько «лапши» 485? вопрос интересный и достаточно спорный (ну а вдруг уже больше, кто знает...)
                                                            +1

                                                            Я так понял, что вы из области домашней автоматизации. Здесь же больше обсуждается промавтоматизация. Есть некоторые нюансы.

                                                              0
                                                              Не совсем из умных домов. Я в упомянутом выше Овене собственно я и придумал те модули ввода-вывода, который и стали тем мх210-м который упомянули несколько выше в примере с двумя ethernet-ами.

                                                              Про Промышленную Автоматизацию и Диспетчеризацию. Я имел ввиду Охранно пожарную сигнализацию и автоматику пожаротушения. Странно звучит, но достаточно сложно сказать что пожарная сигнализация это не пром. Диспетчеризация. А противопожарная автоматика не автоматизация. Ну то есть кроме дров с дымоудалением она стоит на всех пром. Производствах и обеспечивает не менее важный для создания добавленной стоимости технологический процесс
                                                              )))

                                                              А этот рынок в моем видении не сопоставим по размерам со всеми вместе ПЛК в нашей стране. После Овена я могу примерно сравнивать.
                                                                0
                                                                опять же до Овена и системных интеграторов работал я в компании plazma-t. Они по минимум выпускают порядка 200 шкафов в месяц. с авр, контакторами, частотниками своими контроллерами в том числе для водопровода водоотведения с канализации.
                                                                И это Весьма Маленькая компания в ОПС, у них и меньше процента рынка. Не на один объект на который выйгран тендер раз в два года, а каждый месяц.

                                                                И эта часть рынка Автоматизации и Диспетчеризации Более упорядочена чем многие другие.
                                                                Центральные пульты и Шкафы автоматизации у них уже подчиняются законодательству, а не " кто как придумал так и сделал". И требования более жесткие и чёткие.

                                                                Ну и как результат — инженеров в этой части рынка Инсталляции систем Автоматизации и Диспетчеризации существенно больше.
                                                                ну как пример — я полагаю на вскидку по стране больше 35 000 инженеров инсталяторов только той компании где я сейчас работаю. это заниженная оценка.
                                                                Это инженеры. Контроллеры программируют каждый день,
                                                                под каждый объект уникальные настройки и программы, в соответствии с нормативами.
                                                      0
                                                      … есть ещё 1-wire… ну и будем наедятся ещё и появиться что-нибудь интересное)

                                                        0
                                                        есть ещё 1-wire
                                                        Язык не поворачивается его промышленным протоколом назвать. Спасибо не надо. Закопайте. Даже для своего участка не подходит. Вижу постоянно как появляется очередная железка из 1-wire в RS-485 modbus.
                                                          0
                                                          Косноязычен, каюсь. Под 1-wire Имелась ввиду среда передачи, а не протокол. Закопать и не выкапывать это в 10-ку.

                                                          Я пытался донести мысль о том, что достаточно интересна идея удаленных модулей, питаемых от интерфейсной линии.

                                                          Это исключительно в плане Фантазии. Представьте, через 5 лет если был бы протокол, обеспечивающий большую скорость, реальное время и прочие прелести жизни, но работающий со модулями ввода-вывода по физике не требующей дополнительного питания — это было бы весьма интересно.
                                                          Бэкхов со сдвиговым регистром, конечно, востребован в быстрых применениях и к примеру в метро, но если бы были модули с другой архитектурой но сопоставимой скоростью — было бы как минимум интересно
                                                          Да, это скорее всего в текущем понимании это не достижимо. Как добиться таких скоростей и задержек непонятно.
                                                          Но, строго говоря — то чего мы не знаем не обязательно не будет существовать когда_либо. Ну или на крайний случай в другой вселенной))). С реальным 1-wire конечно хотелось бы чтобы не в нашей))
                                                          А так то PoE весьма интересен. В пром зону его врятли вставить прямо нормально — но… как описано выше… может быть, когда нибудь…
                                              0
                                              преимущество модбаса в том что они зачастую работает везде и со всем и в некоторых вариантах что 485 что по ethernet'у гораздо дешевле или почти бесплатен, с теми же OPC вариациями, можно весьма интересно провести ночку выясняя почему часть тегов отваливается. А варианты протоколов это просто желание брендов подсадить на конкретно свой продукт… как вон если вспомнить присказку сименс замечательно стыкуется со всем производства сименс.
                                                0

                                                На сколько помню modbus как раз появился в попытке убрать весь зоопарк протоколов. Но он медленный. CAN Интересней. Быстрей. И там заложена самая главная фишка все могут обращаться ко всем при необходимости а не по опросу. Кстати не совсем понимаю в modbus такую вещь есть bypoll а есть onChange но ведь слейв не может инициировать обмен. В чем преимущество?

                                      0
                                      С каких книг можно начать знакомство с промышленными сетями, если даже эта статья является не совсем понятной? Может быть есть современные учебники, в которых рассматриваются наиболее актуальные протоколы? Или же единственный способ разобраться во всей теории — это изучать документацию ко всем протоколам по порядку?
                                        0

                                        Я не знаю опыт остальных, но у меня обычно что дали с тем и работаешь. По этому лучшее что может быть это практика. Вопрос как то не понятно поставлен. Для чего изучать все протоколы? И почему именно протоколы?

                                          +1

                                          Зависит от того, на каком уровне вы хотите эти протоколы использовать — если на прикладном, то нет смысла углубляться в детали имплементации и можно по быстрому изучить несколько самых распространенных. Если же будете сами что-то мутить, то надо выбрать один и уже читать его документацию. Следует отметить, что не все протоколы одинаково открыты для изучения.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое