Наверняка многие и вас знают или даже видели, каким образом управляются большие автоматизированные объекты, например, атомная станция или завод со множеством технологических линий: основное действо часто происходит в большой комнате, с кучей экранов, лампочек и пультов. Это комплекс управления обычно называютется ГЩУ — главный щит управления для контроля за производственным объектом.

Наверняка вам было интересно, как это все работает с точки зрения аппаратной и программной части, чем эти системы отличаются от привычных персональных компьютеров. В этой статье мы разберемся, как различные данные попадают на ГЩУ, как подаются команды на оборудование, и что вообще нужно, чтобы управлять компрессорной станцией, установкой производства пропана, линией сборки автомобиля или даже канализационно-насосной установкой.

Нижний уровень или полевая шина — то, с чего всё начинается


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

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


Общая схема автоматизации промышленного объекта

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

Верхний уровень: от гирлянды до целой рабочей станции


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

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



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

Оборудование верхнего уровня обязано взаимодействовать неким образом с микроконтроллером (иначе зачем оно нужно?). Для такого взаимодействия используются протоколы верхнего уровня и некая среда передачи, например,Ethernet или UART. В случае с «ёлкой» таких изощрений, конечно, не нужно, лампочки зажигаются с использованием обычных физических линий, никаких мудреных интерфейсов и протоколов там нет.

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

«Древние» протоколы передачи данных: Modbus и HART


Мало кто знает, но на седьмой день создания мира Бог не отдыхал, а создавал Modbus. Наравне с HART-протоколом, Modbus, пожалуй, самый старый промышленный протокол передачи данных, он появился аж в 1979 году.

В качестве среды для передачи изначально использовался последовательный интерфейс, затем Modbus реализовали поверх TCP/IP. Это синхронный протокол по схеме «мастер-слейв» (главный-подчиненный), в котором используется принцип «запрос-ответ». Протокол довольно тяжеловесный и медленный, скорость обмена зависит от характеристик приемника и передатчика, но обычно счет идет чуть ли не на сотни миллисекунд, особенно в реализации через последовательный интерфейс.

Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности. Хотя Modbus до сих пор повсеместно используется в случаях, когда не нужна высокая скорость обмена и потеря передаваемых данных не критична. Многие производители различных устройств любят расширять протокол Modbus своим исключительным и очень оригинальным образом, добавляя нестандартные функции. Поэтому данный протокол имеет множество мутаций и отклонений от нормы, но все же до сих пор успешно живет в современном мире.
Протокол HART тоже существует с восьмидесятых годов, это промышленный протокол обмена поверх двухпроводной линии токовой петли, в которую напрямую включаются датчики 4-20 мА и другие приборы с поддержкой протокола HART.

Для коммутации линий HART используются специальные устройства, так называемые HART-модемы. Также существуют преобразователи, которые на выходе предоставляют пользователю уже, допустим, протокол Modbus.

Примечателен HART, пожалуй, тем, что помимо аналоговых сигналов датчиков 4-20 мА в цепи передается и цифровой сигнал самого протокола, это позволяет соединить цифровую и аналоговую часть в одной кабельной линии. Современные HART-модемы могут подключаться в USB-порт контроллера, соединяться по Bluetooth, либо же старинным способом через последовательный порт. Десяток лет назад по аналогии с Wi-Fi появился и беспроводной стандарт WirelessHART, работающий в диапазоне ISM.

Второе поколение протоколов или не совсем промышленные шины ISA, PCI(e) и VME


На смену протоколам Modbus и HART пришли не совсем промышленные шины, такие как ISA (MicroPC, PC/104) или PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), а также VME.

Настала эра вычислителей, имеющих в своем распоряжении универсальную шину передачи данных, куда можно подключать различные платы (модули) для обработки некоего унифицированного сигнала. Как правило, в этом случае процессорный модуль (вычислитель) вставляется в так называемый каркас, который обеспечивает взаимодействие по шине с другими устройствами. Каркас, или, как его любят называть трушные автоматизаторы, «крейт», дополняется необходимыми платами ввода-вывода: аналоговыми, дискретными, интерфейсными и т.д., либо все это слепливается в виде бутерброда без каркаса — одна плата над другой. После чего это многообразие на шине (ISA, PCI, etc.) обменивается данными с процессорным модулем, который таким образом получает информацию с датчиков и реализовывает некую логику.


Контроллер и модули ввода-вывода в каркасе PXI на шине PCI. Источник: National Instruments Corporation

Все бы ничего с этими шинами ISA, PCI(e) и VME, особенно для тех времен: и скорость обмена не огорчает, и расположены компоненты системы в едином каркасе, компактно и удобно, горячей замены плат ввода-вывода может и не быть, но пока еще и не очень хочется.

Но есть ложка дегтя, и не одна. Распределенную систему довольно сложно построить в такой конфигурации, шина обмена локальная, нужно что-то придумывать для обмена данными с другими подчиненными или равноправными узлами, тот же Modbus поверх TCP/IP или какой другой протокол, в общем, удобств маловато. Ну и вторая не очень приятная штука: платы ввода-вывода обычно ждут на вход какой-то унифицированный сигнал, и гальванической развязки с полевым оборудованием у них нет, поэтому нужно городить огород из различных модулей преобразования и промежуточной схемотехники, что сильно усложняет элементную базу.


Промежуточные модули преобразования сигнала с гальванической развязкой. Источник: DataForth Corporation

«А что с протоколом обмена по промышленной шине?» — спросите вы. А ничего. Нет его в такой реализации. По кабельным линиям сигнал попадает с датчиков на преобразователи сигналов, преобразователи выдают напряжение на дискретную или аналоговую плату ввода-вывода, а данные с платы уже читаются через порты ввода/вывода, средствами ОС. И никаких специализированных протоколов.

Как работают современные промышленные шины и протоколы


А что теперь? К сегодняшнему дню классическая идеология построения автоматизированных систем немного поменялась. Роль сыграли множество факторов, начиная с того, что автоматизировать тоже должно быть удобно, и заканчивая тенденцией на распределенные автоматизированные системы с удаленными друг от друга узлами.

Пожалуй, можно сказать, что основных концепций построения систем автоматизации на сегодняшний день две: локализованные и распределенные автоматизированные системы.

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

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

Как разработчики выбирают протокол для своего проекта? Все современные протоколы обмена обеспечивают довольно высокое быстродействие, поэтому зачастую выбор того или иного производителя обусловлен не скоростью обмена по этой самой промышленной шине. Не так важна и реализация самого протокола, потому что, с точки зрения разработчика системы, это все равно будет черный ящик, который обеспечивает некую внутреннюю структуру обмена и не рассчитан на вмешательство извне. Чаще всего обращают внимание на практические характеристики: производительность вычислителя, удобство применения концепции производителя к поставленной задаче, наличие нужных типов модулей ввода-вывода, возможность горячей замены модулей без разрыва шины и т.д.

Популярные поставщики оборудования предлагают собственные реализации промышленных протоколов: например, всем известная компания Siemens разрабатывает свою серию протоколов Profinet и Profibus, компании B&R — протокол Powerlink, Rockwell Automation — протокол EtherNet/IP. Отечественное решение в этом списке примеров: версия протокола FBUS от российской компании Fastwel.

Есть и более универсальные решения, которые не привязаны к конкретному производителю, такие как EtherCAT и CAN. Мы подробно разберем эти протоколы в продолжении статьи и разберемся, какие из них лучше подходят для конкретных применений: автомобильной и аэрокосмической промышленности, производства электроники, систем позиционирования и робототехники. Оставайтесь на связи!

Комментарии (30)


  1. nickolas059
    30.05.2019 16:00

    Это комплекс управления обычно называютется ГЩУ — главный щит управления для контроля за производственным объектом.

    В химической и нефтехимической отраслях это называется «Центральный пульт управления» или ЦПУ (прямо как Центр Управления Полетом или ЦУП). Или Объедененная операторная. Или Central control room / Central control facility / Integrated control room


  1. IronHead
    30.05.2019 16:15

    Для заинтересовавшихся советую так же почитать про протоколы МЭК 60870-5, МЭК 61850
    Они так же сильно распространены в современном мире


  1. mcu_by
    30.05.2019 16:41

    Спасибо за статью, но статья содержит некоторое на мой взгляд количество неточностей:
    Общая схема автоматизации промышленного объекта  не имеет отображение исполнительных механизмов, странно так же изображать модуль cpu и писать что это микроконтроллер, в промышленной автоматики на структурных схемах и не только показывают, что модуль cpu, и чаще всего он в одной стойки и имеет общую шину туже что и модули AI/AO/DI/DO, если схема распределенная тогда возможно. Сам модуль cpu может быть как soc, как микроконтроллер, как микропроцессор так и fpga, так же я бы добавил специализированные модули, интерфейсные модули и т. п в общую схему автоматизации промышленного объекта. Странно что в статье нет упоминания scada систем, т. к. за hmi панель точно никто целый день не стоит, и это не предоставляет не удобств, конечно если у вас не ЧПУ тогда все возможно, но все сложные производства управляются через scada системы. «Качество и размер изображения на малоформатных панелях оставляет желать лучшего» достаточно высокого качества изображение возьмите например панели waintek или siemens hmi панели и других производителей. UART не использует такие как он есть, используют rs232 и rs485, внутри да конечно uart. Странно что в статье Modbus и HART старые протоколы а, вот ethernet то нет, хотя ethernet тоже достаточно старый протокол. «Второе поколение протоколов или не совсем промышленные шины ISA, PCI(e) и VME» не вписывается в вашу концепцию описания «Общая схема автоматизации промышленного объекта», либо я что-то не да понял.
    Далее полевые устройства: датчик и исполнительные механизмы, в свою очередь так же имеют уже давно интеллектуальные интерфейсы для передачи данных пусть то (profinet, profibus или т. п.). Так же есть множество компаний который выпускают пром автоматику, где модули di/do/ai/ao и cpu соединены между собой не общей шинной, а посредством ethernet, modbus rtu или modbus tcp/ip. Да и де факто siemens, abb мировые лидеры пром автоматики, поэтому эти компании диктуют условия развития пром сетей и промышленного оборудования. EtherCAT разработан компанией Beckhoff. Beckhoff в первую очередь делали данный протокол под свои ПЛК, и почему в статье нет термина ПЛК(PLC), pac и т. п.?


    1. FDA847
      30.05.2019 17:38

      Причём довольно популярен ещё ModbusTCP. Также есть Modbus over TCP/UDP.
      В ModbusTCP немного другой заголовок, в остальной похоже на обычный Modbus.
      А в Modbus over TCP/UDP по сути просто стандартный пакет Modbus передаётся.
      Таким образом легко интегрируется старое оборудование в новую сеть.
      Да и вообще, мне кажется, классический Modbus тоже помирать не собирается :-)
      Очень много и современных устройств с его поддержкой выпускается.


      1. semen-pro
        01.06.2019 02:08

        Бывает ещё модифицированный Modbus с двухбайтной адресацией, его любят производители электросчетчиков.


  1. bormental
    30.05.2019 22:27

    А почему про M-Bus ни слова?


    1. FDA847
      31.05.2019 00:27

      Кстати, да! Крайне интересная шина. У нас сейчас набирает большую популярность в различных приборах учёта (воды, тепла). К одной двухпроводной шине 250 устройств можно подключить, так по ней же ещё и питание идёт.
      Я как-то преобразователь Ethernet\COM <=> M-BUS делал. Схемотехника там довольно интересная.


      1. bormental
        31.05.2019 13:35

        Я как-то преобразователь Ethernet\COM <=> M-BUS делал. Схемотехника там довольно интересная.

        Что-то типа этого?
        https://github.com/rscada/libmbus/blob/master/hardware/MBus_USB.pdf
        Или совсем оригинальное? Ваши наработки не open source?
        Смотрел на готовые решения, но ценник!
        Мне для хобби, но я, увы, совсем не электронщик :(


        1. FDA847
          31.05.2019 18:17

          Нет, я схему посложнее делал. На 250 устройств. Проект, правда, коммерческий был, поэтому итоговой схемой поделиться не могу. Но тема интересная, может быть по аналоговой части статью напишу как-нибудь.
          Там именно вся сложность как раз в ней. «Цифру» прикрутить дальше элементарно.
          Причём готовая схема есть в ГОСТ Р ЕН 1434-3-2006 (стр. 33):
          www.decast.com/upload/iblock/112/gost_r_en_1434_3_2006_teploschetchiki._chast_3._obmen_dannymi_i_interfeysy.pdf
          Но там имеется ряд неточностей, плюс отсутствует защита ОТ КЗ на выходе.
          Собственно именно от этой схемы я и отталкивался.


          1. bormental
            31.05.2019 20:33

            Ясно. У меня есть дома 1 счетчик на M-Bus, который стоит в очень неудобном месте.
            И есть идея-фикс:) Хочу с него данные передавать по воздуху. И если с последним проблем нет, то вот физически считать с M-Bus — временный затык.
            Из готового "дешевого" нашел только https://ru.aliexpress.com/item/USB-MBUS-M-BUS-10/32854222405.html
            Но мне USB на выходе избыточен, а вот обычный UART на 3-5V для микроконтроллера — нет таких готовых конвертеров :(


            1. bormental
              31.05.2019 21:06

              Хм, еще недавно ничего не находил, а вот только что глянул, что-то похожее на то, что мне надо нарисовалось: https://ru.aliexpress.com/item/100pcs-lot-Free-shipping-SMD-resettable-fuse-SMD1210P100TF-30-1210-1A-1000MA-30V/32806628015.html


        1. Int_13h
          01.06.2019 03:40

          Мы как то, пока ждали заказанного конвертера, спаяли из горсти транзисторов конвертер M-bus to RS232. Еще бы схему найти, 11 лет назад было.


      1. avf1906
        31.05.2019 13:40
        +1

        Дурацкая схемотехника, ИМХО. Если слейв еще более-менее адекватен, то мастер стоит безумных денег или реализуется кучей рассыпухи и компактно не получается в принципе. Медленный. В общем никаких преимуществ перед любыми другими, если нужно по двум проводам — есть 1-wire. Больше похоже что изначально был как проприетарное решение для попила бабла (не только у нас пилят), потом попытались протащить в массы.
        ЗЫ: статья тоже ниачем. Смешались в кучу кони, люди. Если пром шины, то причем тут ISA и иже с ней. Если говорим про шины, причем здесь вообще модбас — это протокол, а не шина.


        1. FDA847
          31.05.2019 14:15

          Схемотехника тут да, тяжёлая. Особенно для мастера. Интегральных решений мне не попадалось. Но в своё время я уместил мастера в корпусе D4MG на DIN-рейку шириной в 4 автомата.
          Учтите, что в M-BUS напряжение на линии доходит до 42 В, а 1-Wire всего 5 В.
          Кроме того, M-BUS поддерживает 250 устройств на линии. У него высокая помехозащищённость и низкие требования к качеству кабеля. Поэтому он и прижился для подключения приборов учёта. Получается простая и надёжная система. Скорость передачи данных тут низкая, но она и не нужна.Показания требуются довольно редко.
          Честно говоря, для собственных нужд мастера можно собрать и на двух транзисторах.
          А вот профессиональные решения для полной шины стоят довольно дорого. Но это не особо популярные вещи, поэтому и цена наверное такая.


          1. avf1906
            31.05.2019 20:25

            D4MG конечно неплохо, мне в свое время нужно было в 5см2 нужно было уложиться, в итоге отказались от поддержки M-BUS.
            Скорее высокая цена и сложность определяет низкую популярность. И еще момент, питание по шине данных при таких напряжениях сильно удорожает питание слэйва. Если слэйв имеет свое питание или питать по отдельной линии с низким напряжением, то никаких преимуществ перед 485 нет. Останусь при своем мнении, M-bus — мертворожденный интерфейс. Впрочем, думаю как и Лора в стратегической перспективе.


            1. FDA847
              31.05.2019 20:34

              Питание, откровенно говоря, организуется очень просто. Я использовать повышающий преобразователь. Из напряжения 15-30В делал 42В. Максимальный ток потребления одного слэйва составляет 1,5 мА (по стандарту). Для 250 устройств получается всего 375 мА.
              Зато вся линия — обычная «лапша» (2 провода). Очень удобно прокладывать. Полярность подключения к шине неважна! Для монтажников эта шина идеальна! :-)
              Для 485 интерфейса потребуется 4 провода (A, B и два провода питания), плюс правильная распиновка.


              1. avf1906
                31.05.2019 20:59

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


            1. bormental
              31.05.2019 20:39

              M-bus — мертворожденный интерфейс

              Только большинство мало-мальски хороших счетчиков тепла, как назло, используют именно его.


              1. avf1906
                31.05.2019 21:02

                Вот у меня как раз обратная ситуация, за все время только два счетчика видел с M-bus. Да и как правило интерфейс — это опция, какой заказали (завезли на склад), тот и будет.


                1. bormental
                  31.05.2019 21:12

                  SHARKY 774 — мне такой вот попался. Но хоть без радио, а с проводным M-Bus.


  1. freemanon
    31.05.2019 07:52

    На смену протоколам Modbus и HART пришли не совсем промышленные шины, такие как ISA (MicroPC, PC/104) или PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), а также VME.

    Бред какой-то. Впрочем как и вся статья.


  1. shadovv76
    31.05.2019 10:11

    старые, но не устаревшие :)
    самые популярные на объектах добычи газа для полевого оборудования в том числе и на тех, что еще только будут вводиться.


  1. andersong
    31.05.2019 11:23

    Статья тянет на реферат для первых курсов, но не больше, чем на 4.
    Но радует факт наличия на Хабре коллег — асушников)))
    Автор, пиши ещё!


  1. CityX
    31.05.2019 12:24

    Протокол довольно тяжеловесный и медленный, скорость обмена зависит от характеристик приемника и передатчика, но обычно счет идет чуть ли не на сотни миллисекунд

    А почему, собственно, тяжеловесный? Помимо переданных 16-и битных регистров, передается header который всегда 7 байт:
    — Transaction ID (2 байта)
    — Идентификатор протокола (2 байта)
    — Длинна пакета (2 байта)
    — Адрес slave устройства (1 байт).
    При этом можно 1 запросом получить (если я не ошибаюсь) 125 регистров.


    1. semen-pro
      01.06.2019 02:11

      Тяжеловесный — скорее всего по архитектуре, т.к. имеет место циклический опрос, на который тратятся ресурсы.


  1. ViacheslavMezentsev
    31.05.2019 14:52

    Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности

    Писать надо: real и lreal (в языках МЭК), либо float и double (C/C++). Сам modbus не ограничивает точность передаваемых данных. Что передаёте — то и получаете.


    1. FDA847
      31.05.2019 17:10

      Именно! Никто не мешает и строки передавать по Modbus'у. Протокол довольно гибкий и легко реализуется даже на слабом «железе». Его спокойно на 8-битном контроллер запрограммировать можно.


  1. lamer84
    31.05.2019 15:12

    Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности.
    Никто не мешает опрашивать блоками по 2 регистра и получить 4 байта, интерпретируемые потом в тот же REAL. Так же, кстати, и со всякими DINT, DWORD и т.д. Более того, часто в средах разработки есть ФБ для работы с модбасом не на уровне протоколов, а на уровне данных, которые позволяют не задумываться, что и как там передается.
    Большим плюсом модбаса является его простота. Когда, например, заказчик вместо какого-нибудь MGate ставит NPort, и приходится самому реализовывать Modbus over TCP. Поэтому, чую, долго он еще проживет!


  1. vortex7
    02.06.2019 01:34

    Если уж EtherCAT «не привязан конкретному производителю», то POWERLINK тем более.
    А так да его разработала изначально B&R, как Beckhoff изначально разрабатывала EtherCAT.


  1. cutnioff
    03.06.2019 12:07
    -1

    Спасибо! Подобных материалов не хватает.