книги / Микропроцессорные средства автоматизации энергетических систем. Сети автоматизации

устройства не имеют МАС-адресов), прикрепленных к одному порту коммутатора, вместе образуют EtherCAT-сегмент, который либо адресуется при помощи его MAC-адреса, либо через порт на основе VLAN. Начиная с 100BASE-TX Ethernet физического уровня расстояние между любыми двумя узлами может составлять до 100 м. До 65 535 устройств может быть подключено к сегменту. Если сеть EtherCAT соединена кольцевой конфигурацией (требуется два порта на главном устройстве), это может привести к избыточности проводных каналов.

Для синхронизации применяется механизм распределенных часов, что приводит к очень низкой частоте дрожания, значительно меньшей, чем 1 мкс, даже если коммуникационный цикл колеблется, что эквивалентно IEEE 1588 Precision стандартным протоколам времени. В связи с этим сеть EtherCAT не требует специального оборудования в master-устройстве и может быть реализована в программном обеспечении на любом стандартном Ethernet-устройстве с MAC-адресом, даже без специализированного сопроцессора связи. Типичный процесс создания распределенных часов запускается главным устройством, отправив широковещательно всем ведомым устройствам определенный адрес. После получения этого сообщения все ведомые устройства будут фиксировать значение их внутренних часов дважды: один раз – при получении сообщения и один раз – когда сообщение возвращается (EtherCAT имеет кольцевую топологию). Ведущее устройство может читать все зафиксированные значения и вычислить задержки для каждого ведомого устройства. Этот процесс можно повторять столько раз, сколько необходимо для уменьшения дрожания и вычисления средних выходных значений. Всего задержки рассчитываются для каждого ведомого устройства в зависимости от их положения в ведомом кольце и загружаются в регистр сдвига. После проведенных операций ведущее устройство разрешает широковещательное чтение (запись) на системных часах, что делает первое ведомое устройство эталонными часами и заставляет все другие ведомые устройства установить их внутренние часы с надлежащим, сейчас известным смещением.

171

Чтобы сохранить часы синхронизированными после инициализации, ведущее или ведомое устройство должно регулярно посылать широковещательный запрос еще раз, чтобы компенсировать любые последствия разницы в скорости между внутренними часами каждого. Каждое ведомое устройство должно регулировать скорость спомощью внутренних часов или запускать внутренний механизм коррекции всякий раз, когда ведомое устройство должно установить актуальное значение. Системные часы описаны как 64-битный счетчик с базовым блоком1 нсначинаяс1 января2000 г. 0:00.

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

Для систем повышенной безопасности (fail-safety) в EtherCAT создан специализированный профиль Safety-over-EtherCAT. Он позволяет реализовать в одной сети как решение обычных задач управления, так и выполнение задач систем повышенной безопасности. Протокол безопасности реализуется на уровне приложений EtherCAT, не затрагивая нижних уровней. Он разработан в соответствии с требованиями стандарта IEC 61508 и удовлетворяет требованиям SIL4. Протокол имеет переменную длину дейтаграммы, что делает возможным использование различных устройств вводавывода, а также частотно-регулируемых приводов с поддержкой профиля безопасности. Туннелирование профиля безопасности, равно как и других данных EtherCAT, не требует применения специализированных коммутаторов или шлюзов.

Ассоциация разработчиков и производителей, поддерживаю-

щих EtherCAT, называется EtherCAT Technology Group. Она явля-

ется партнером МЭК (IEC).

Типичными областями для применения EtherCAT являются машины управления, например: полупроводниковые инструменты, обработка металлов давлением, упаковка, литье под давлением, сборочные системы, печатные машины, робототехника.

172

2.6.4. Протокол Ethernet Powerlink

Ethernet Powerlink – это открытый протокол передачи данных в реальном времени для использования в сетях Ethernet, соз-

данный группой Ethernet Powerlink Standardization Group (EPSG),

основанной в июне 2003 года. Технология была разработана австрийской компанией B&R в 2001 году. Несмотря на сходство названий, этот протокол не относится к передаче электроэнергии через

Ethernet-кабели (технологии Power over Ethernet, PoE) и связи через электропроводку.

Рабочие группы сосредоточили внимание на таких задачах, как безопасность, технологии, маркетинг, сертификация и конечные пользователи, EPSG сотрудничает со стандартизирующими организациями и ассоциациями, такими как CiA и IEC.

Ethernet Powerlink расширяет стандарт Ethernet механизмами смешанного опроса и технологией Time Slicing:

–гарантируется передача срочных данных в очень короткие изохронные интервалы с настраиваемым временем отклика;

–осуществляется высокоточная синхронизация времени для всех узлов в сети (точность порядка микросекунд);

–передача некритичных данных, для которых не требуется гарантий обработки в реальном времени, осуществляется в отдельном асинхронном канале.

В современных реализациях длительность интервалов может быть менее 200 мкс, джиттер (точность синхронизации) – менее 1 мкс.

Изначально протокол определялся для физического уровня на

основе 100BASE-TX (Fast Ethernet, 100 Мбит/с по витой паре).

В конце 2006 года был разработан вариант Ethernet Powerlink для

Gigabit Ethernet (1 Гбит/с).

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

173

руководства IAONA (Industrial Ethernet Planning and Installation Guide) в части прокладки кабелей. В качестве разъемов применяются как распространенные Ethernet-разъемы 8P8C (RJ-45), так и М12.

Канальный уровень Ethernet расширяется дополнительным механизмом планирования обмена на шине. Вводятся выделенные промежутки времени, в которые доступ к шине разрешен только одному из устройств. Все время работы шины делится на изохронные и асинхронные фазы. Во время изохронной фазы передаются данные, критичные к времени доставки. Асинхронная фаза позволяет передавать значительные объемы данных, для которых не требуются гарантии времени доставки. Управляющий узел (managing node, MN) распределяет время доступа к среде путем рассылки специальных управляющих сообщений. В результате в каждый момент времени только один узел (называемый CN) имеет доступ к сети. Такая система управления позволяет избежать коллизий, которые могли происходить на более старых сетях Ethernet, использующих концентраторы, а не коммутаторы, как в более современных сетях.

Ethernet Powerlink не использует алгоритм разрешения коллизий CSMA/CD, так как он приводил бы к недетерминированности времени доставки пакетов.

Кадры, показанные над линией (рис. 2.9), отправляются с MN, а под линией – различными CN.

Рис. 2.9. Основной цикл

174

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

Основной цикл состоит из следующих фаз:

1.Начальная фаза (start phase): управляющий узел рассылает сообщение синхронизации на все узлы, которое называется SoC (Start of Cycle – начало цикла) и имеет размер в один фрейм Ethernet.

2.Изохронная фаза (isochronous phase): управляющий узел опрашивает каждый из узлов для передачи данных, критичных к времени доставки, отправляя запрос PREQ (poll request). Запрошенный узел отвечает пакетом PRES (poll response). Общая схема реализует

алгоритм «производитель – потребитель». Период времени, когда пересылаются сообщения PREQ-n и PRES-n для n-го узла, называется слотом для адресуемого узла.

3. Асинхронная фаза (asynchronous phase): управляющий узел дает одному из узлов право отправки асинхронных данных, посылая ему пакет SoA (Start of Asynchronous). Узел отвечает пакетом ASND. В этой фазе используется стандартный стек протоколов IP.

Конкретные гарантии реального времени зависят от точности выполнения основного цикла. Длины каждой из фаз могут варьироваться (рис. 2.10). Соотношение между изохронной и асинхронной фазами в определенных пределах может настраиваться.

Рис. 2.10. Слоты (временные интервалы) для каждого из узлов и асинхронные фазы

175

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

Рис. 2.11. Временные слоты EPL в режиме мультиплексирования

В робототехнике и крупных системах используется специальная техника сцепления откликов (poll response chaining).

2.6.5. Интерфейс SERCOS III

SERCOS (Serial Real-time Communication System) – это циф-

ровой интерфейс, оптимизированный для связи между контроллером и преобразователями частоты и использующий волоконнооптическое кольцо. Он был разработан в первоначальном виде группой компаний еще в конце 1980-х годах. Работа в реальном времени достигается при помощи механизма TDMA (Time Division Multiplex Access – мультиплексный доступ с временным уплотнением). SERCOS III является последней версией этого интерфейса и базируется на Ethernet. Цикл SERCOS III представлен на рис. 2.12.

Рис. 2.12. Стандартный цикл SERCOS III

176

Связь в сети SERCOS III осуществляется по жестко фиксированным циклическим интервалам. Время цикла определяется пользователем в зависимости от применения и должно находиться в диапазоне от 31,25 мкс до 65 мс. В каждом цикле происходит обмен данными между узлами SERCOS III при помощи телеграмм двух типов: MDT и AT. После передачи всех телеграмм узлы SERCOS III позволяют использовать оставшееся время цикла как NRT-канал (non-real time – нереального времени), который может быть использован для обмена данными с помощью иных форматов, например, таких как IP.

Сеть продолжает быть доступной для передачи данных NRT до момента начала следующего цикла, когда все узлы SERCOS III закрывают обмен по NRT снова. Это является важной отличительной особенностью. SERCOS специально разработан с целью обеспечения открытого доступа ко всем портам для других протоколов между циклическими посылками реального времени. Таким образом, туннелирование не требуются. Благодаря этому обеспечивается преимущество доступности любого из узлов SERCOS III для других протоколов, таких как TCP/IP, независимо от того, находится ли SERCOS III в циклическом режиме или нет, и без необходимости использования дополнительного оборудования для обработки туннеллирования. Узлы SERCOS установлены на обеспечение буферизации методом сохранения и пересылки неSERCOS-сообщений, поступающих в узлы при активной связи в циклическом режиме.

2.6.6. Стандарт LAN LXI

LXI (LAN eXtensions for Instrumentation) – коммуникаци-

онный стандарт для промышленной сети на базе стандартных сетей Ethernet, разработанный и поддерживаемый некоммерческой организацией LXI Consortium. Предполагается, что стандарт призван заменить интерфейс GPIB и менее известные попытки стандартизации доступа к измерительным приборам, такие как VXI и PXI. LXI является торговой маркой LXI Consortium.

Консорциум был образован в 2004 году компаниями Agilent Technologies и VTI Instruments. В 2005 году вышла черновая специ-

177

фикация 1.0, в 2011 году – первая рабочая версия спецификации 1.4, актуальная и сейчас.

Стандарт открыт и бесплатен. Его можно скачать с сайта организации.

Стандарт предусматривает подключение к беспроводным, кабельным или оптическим сетям Ethernet. Для кабельных сетей требуется поддержка Gigabit Ethernet 1000BASE-T. Рекомендуются стандартные Ethernet-разъемы: RJ-45 на 8 контактов или M12 на 4 или 8 контактов.

Стандарт использует в качестве транспорта протокол TCP/IP с обязательным IPv4 и опциональным IPv6. Предлагаются три обязательных метода установки IP-параметров: DHCP, Auto IP и вручную. Параметры сети по умолчанию устанавливаются кнопкой. Управление устройством осуществляется через веб-интерфейс.

Устройство обязано поддерживать протоколы Multicast DNS, DNS Service Discovery и VXI-11, иметь файл с параметрами устройства в XML-формате. Состав тегов и их назначение определяются стандартом (LXI XSD Schema).

Стандарт не специфицирует конкретного протокола и набора команд для непосредственного управления прибором. Вместо этого стандарт требует четкой реализации API-драйверов устройства в соответствии с правилами IVI Foundation. Конкретный протокол управления разработчик прибора может выбрать на свой вкус. Тем не менее в рамках IVI Foundation существует рекомендуемый про-

токол HiSLIP (High Speed LAN Instrument Protocol), который может быть использован для связи с устройством.

Много внимания стандарт уделяет вопросам работы устройств в системах управления реального времени. Для этого предусмотрены следующие механизмы:

1. Синхронизация устройств через Ethernet на базе стандарта IEEE 1588-2008 либо синхронизация прямым кабельным соедине-

нием с физическим уровнем LVDS (LXI Device Wired Trigger Bus).

Для IEEE 1588 допускается как аппаратная, так и программная реализации.

178

2. Для передачи сообщений о событиях предусмотрены специальные сообщения в сети (LXI Event Messages) поверх протоколов UDP (широковещательные) или TCP (адресные). Для них заре-

зервированы Multicast IP-адрес 224.0.23.159 и порт сервера 5044.

Подробно рассматриваются вопросы временных задержек.

LXI Event Messages делятся на три группы: определяемые стандартом, определяемые разработчиком прибора и определяемые инсталлятором системы (пользователем).

Стандарт требует соответствия API-драйверов устройств спецификациям IVI Foundation. Драйверы устройств должны быть сертифицированы этой организацией. Документация на драйверы должна быть доступна с веб-сервера устройства.

Стандарт рекомендует или обязует выполнять ряд конструктивных требований, например: наличие, расположение и маркировка разъемов питания и интерфейсов, выключателей питания и кнопок начальной конфигурации, индикаторов питания, сети, статуса, MAC-адреса, логотипа и других обозначений консорциума.

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

2.6.7. Технология Modbus TСP

Протокол Modbus TCP (или Modbus TCP/IP) используется для того, чтобы подключить устройства с протоколом Modbus к сетям

Ethernet или Internet. Он использует кадры Modbus RTU на 7-м (при-

кладном) уровне модели OSI, протоколы Ethernet на 1 и 2-м уровнях модели OSI и TCP/IP на 3 и 4-м уровнях, т.е. Ethernet TCP/IP исполь-

зуется для транспортировки модифицированного кадра Modbus RTU. Формат кадра Modbus RTU рассмотрен в гл. 4.

На сайте modbus.org опубликовано руководство Modbus Messaging on TCP/IP Implementation Guide V1.0b. Вместо трехуров-

невой модели, которая существует в Modbus для передачи данных по последовательной линии связи, в Modbus TCP используется принятая для Интернета пятиуровневая модель, представленная в табл. 2.4.

179

Вместо пространного обсуждения вопросов физического и канального уровней в стандарте дается ссылка на 1500-страничный стандарт IEEE 802.3. В данном сетевом стандарте говорится только о том, как Modbus PDU (содержащий код функции и данные) встроен в протокол более высокого уровня. Шина Modbus фактически является шиной IP (рис. 2.13).

Рис. 2.13. Технология «клиент – сервер» в модели Modbus TCP

При этом физический и канальный уровни не конкретизируются. Вместо привычного ведущего устройства, к которому подключено множество ведомых устройств, используются термины «клиент» и«сервер». В качестве клиентов могут выступать устройства SCADA

180