Сети Real-Time Ethernet: от теории к практической реализации

Сети Ethernet уже более 30 лет эффективно решают задачи по высоко-скоростной передаче данных. Ethernet как стандарт за это время стал самым распространённым в мире и проник во многие области повседневной жизни, в том числе в промышленность. Сегодня в промышленной автоматизации распределённые системы управления постоянно усложняются и объединяются в общую технологическую сеть предприятия. Однако если в административной части сети Ethernet уже стал стандартом де-факто, то в технологической части преимущественно господствуют различные полевые шины, имеющие мало общего с Ethernet. Причиной этого служит один из основных недостатков сетей Ethernet, проявляющийся при адаптации их к автоматизации производственных процессов – невозможность функционирования в режиме так называемого реального времени. И дело отнюдь не в аппаратной среде передачи: даже при использовании Gigabit Ethernet, тщательно выверенной топологии, управляемых коммутаторов с настроенными приоритетами для трафика нет чёткого регламента на время доставки конкретного пакета данных от отправителя к получателю.

«Необязательность» сетей Ethernet, сокрытая внутри его базового протокола IEEE 802.3, так или иначе нивелирована в ряду протоколов Real-Time Ethernet, являющихся своего рода производными и физически совместимыми с Ethernet-протоколами. О них и пойдёт речь далее.

Что такое ­Real-Time Ethernet?

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

Принцип работы системы реального времени проиллюстрирован на рисунке 1.

Готовность системы – момент, с которого система реально начинает выполнять полученную задачу. Задача должна быть закончена до наступления крайнего срока. Соответственно, время с момента получения задачи до выполнения считается временем отклика системы.

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

Привлекательность Ethernet для сетей реального времени связана с его основными преимуществами. В техническом плане это прежде всего скорость: стандарты Fast и Gigabit Ethernet (100 Мбит/с и 1 Гбит/с) многократно обгоняют самую быструю полевую шину PPOFIBUS (12 Мбит/с), функционирующую в реальном времени. Другая причина в самом протоколе: он сертифицирован по IEEE и ISO, использует стек протоколов TCP/IP, имеющий широкую аппаратную и программную поддержку.

Однако Ethernet, определённый в стандарте IEEE 802.3, не может обеспечить функционирование системы в реальном времени. Причина находится внутри протокола IEEE 802.3. На канальном уровне в нём заложен механизм доступа CSMA/CD (множественный доступ с контролем несущей и обнаружением коллизий), описывающий поведение участника сети при отправке и приёме данных. Начать передачу данных конкретная станция может, только когда дождётся окончания передачи данных другими участниками. Интервал ожидания зависит от целого ряда причин и является величиной произвольной. Соответственно, рассчитать гарантированную длительность цикла передачи данных практически не представляется возможным. Схематично этот процесс показан на рисунке 2.

Основное достоинство CSMA/CD – регулировка загруженности канала. При возрастании загруженности число коллизий увеличивается, также увеличивается и интервал задержки. Последний, собственно, и является той самой неопределённостью, недопустимой для функционирования в реальном времени.

Таким образом, чтобы Ethernet функционировал в реальном времени, необходимо ввести дополнительный механизм, позволяющий избежать коллизий. Такие механизмы есть в Ethernet-совместимых протоколах реального времени EtherNet/IP, PROFINET, EtherCAT, Powerlink. Отдельного упоминания также заслуживает стандарт IEEE1588, позволяющий синхронизировать таймеры абонентов сети с высокой точностью.

Что такое EtherNet/IP?

EtherNet/IP (Ethernet Industrial Proto-col) – это открытый протокол уровня приложений, разработанный совместно международными ассоциациями ControlNet International, Open DeviceNet Vendors Association, Industrial Ethernet Association. Если обращаться к 7-уровневой модели OSI/ISO, на первых четырёх уровнях (физическом, канальном, сетевом и транспортном) изменений в структуре нет. Используется та же физическая среда 802.3, MAC-адреса, протокол IP, протоколы TCP и UDP. На прикладном уровне (с 5-го по 7-й) используется уже специальный объектно-ориентированный протокол CIP (Common Industrial Protocol), применяемый также в сетях ControlNet и DeviceNet. Функционирование в режиме реального времени обеспечивается специальным расширением протокола CIP – CIPSync, основанным на протоколе временной синхронизации IEEE 1588.

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

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

• каждый сегмент (группа участников, обменивающихся данными в реальном времени) сети EtherNet/IP должен находиться в собственной виртуальной сети VLAN;

• функции резервирования линий связи (RSTP – Rapid Spaning Tree Protokol – и прочие) должны быть отключены;

• каждый сегмент должен иметь топологию «звезда» с управляемым коммутатором 2-го уровня OSI. На коммутаторе нужно задействовать режим IGMP Snooping, отфильтровывающий паразитные широковещательные сообщения в сети;

• в ряде случаев для функционирования сегментов EtherNet/IP в реальном времени необходимо применение коммутаторов 3-го уровня, реализующих функцию TTL (Time-to-Live). Данная функция позволяет отфильтровывать нежелательные многоадресные пакеты данных, например, при трансляции IP-видеосигнала.

Все эти меры направлены на максимальное устранение любого постороннего трафика в сети. При несоблюдении данных мер в сети могут возникать дополнительные неопределённые задержки передачи данных.

Использование в EtherNet/IP протокола UDP для передачи критичного ко времени доставки трафика вносит определённую погрешность и непредсказуемость в режим передачи. Несмотря на это EtherNet/IP условно можно назвать протоколом реального времени для тех случаев, где максимальная погрешность для времени доставки данных удовлетворяет условиям технологического процесса. Например, для сегмента сети с топологией «звезда», где данные от 8 источников собираются одним клиентом, гарантировано время доставки 7 мс.

Для множества «нежёстких» временных процессов (HMI и пр.), сетей, cопряжённых с DeviceNet, EtherNet/IP является оптимальным решением. Использовать Ethernet/IP для сетей жёсткого реального времени, например, отвечающих за контроль вращения приводов, можно в случае применения сете-вого оборудования с поддержкой синхронизации часов по протоколу РТР (Precision Time Protocol). О таких коммутаторах Ethernet будет рассказано далее.

EtherCAT: немного о «кошках»

EtherCAT (вопреки заголовку расшифровывается как Ethernet for Control Automation Technology) – протокол, изначально разработанный компанией Beckhoff для контроля движения по сети Ethernet реального времени. Сеть EtherCAT базируется на архитектуре Master-Slave, может сосуществовать с cетью Ethernet (также с EtherNet/IP). Протокол EtherCAT требует режима Full-duplex, зато может быть некритичным по отношению к топологии (звезда, кольцо, шина).

EtherCAT может работать в режиме как реального, так и недетерминированного времени. Первый режим, называемый EtherType, работает только в EtherCAT-сегменте, не использует IP-протокол и, следовательно, несовместим с Ethernet. Второй использует для передачи трафика протоколы UDP/IP, совместим с Ethernet, но уже не в полной мере удовлетворяет условиям реального времени.

Мастер сети (ведущее устройство) организует обмен данными циклично. Данные EtherCAT передаются в виде кадров, упакованных в стандартные телеграммы Ethernet, но с большим приоритетом. Ведомые устройства в сети только выполняют команды ведущего. Формат данных в EtherCAT представлен на рисунке 3.

Телеграммы Ethernet от мастера сети последовательно обходят все ведомые устройства, каждое из которых на лету находит свой адрес в кадре, считывает или вставляет данные (от 2 бит до 64 кбайт) и отправляет телеграмму дальше. Процесс чтения/записи в ведомых устройствах выполняется с помощью специального контроллера EtherCAT аппаратно, благодаря чему занимает несколько наносекунд. Для внутренней синхронизации в EtherCAT используется упрощённая версия протокола IEEE 1588.

Быстродействие EtherCAT позволяет опрашивать 1000 ведомых устройств ввода/вывода с циклом в 30 микросекунд. При контроле вращения частота контроля 100 приводов может достигать 10 кГц.

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

Powerlink – «мощный» Ethernet

Протокол Powerlink был разработан австрийским производителем коммуникационного оборудования Bernecker & Rainer. Принцип организации сетей с использованием протокола Powerlink основан на разделении сети на сегменты недетерминированного и реального времени. Последний необходим, как правило, на машинном уровне промышленной сети, который и так выделяется в отдельный сегмент в целях защиты от внешних данных. На физическом уровне модели OSI в сегменте Real-Time используются стандартные IP-пакеты данных, архитектура клиент-сервер, обычные кабели согласно IEEE 802.3. Для обеспечения условий реального време-ни в рамках протокола Ethernet цикл передачи данных в сети по методу, называемому Slot Communication Network Ma-nagement (SCNM), осуществляется по строгому графику в 2 приёма: первый – для критичных ко времени доставки данных и второй для трафика с низким приоритетом. Ведущее устройство определяет график этих фаз и передачи данных всем участникам (ведомым устройствам) сегмента Real-Time, что заодно исключает образование коллизий в сети. Такая организация делает упомянутый в начале статьи метод CSMA/CD протокола Ethernet ненужным для данного сегмента и, соответственно, исключает его влияние на детерминизм сети.

Powerlink использует 2 типа данных: PDO (Process Data Objects) для передачи высокоприоритетных данных, тактируемых по времени, и SDO (Service Data Objects) для низкоприоритетных данных, некритичных ко времени доставки. Физически же профиль устройства представляет собой электронную XML-совместимую таблицу, находящуюся в памяти устройства в файле с расширением EDS.

Функционирование Powerlink-совместимых устройств может происходить в трёх режимах: базовом, подготовительном и рабочем. Первый режим используется для конфигурирования устройства, включается вместе с устройством и позволяет передавать только данные с низким приоритетом. При подготовительном режиме происходит инициализация подключенных ведомых сетевых устройств или загрузка конфигурации. Непосредственно рабочий режим делится на три фазы: старт цикла (синхронизация по времени ведомых устройств с ведущим), изохронная (циклическая) фаза (для передачи данных с высоким приоритетом), асинхронная фаза (данные Ethernet).

Схематично этот процесс представлен на рисунке 4.

Реализация протокола Powerlink в сети в принципе не требует разграничения с остальной сетью Ethernet. Сам протокол также не нуждается в специальном аппаратном обеспечении. Однако применение активных устройств в сегменте Powerlink не рекомендовано. Даже самый простой коммутатор будет вносить неконтролируемые задержки и противоречить требованиям реального времени. Также для повышения стабильности работы сети рекомендовано отделение сегмента сети с Powerlink от основной сети Ethernet маршрутизатором. В последней версии протокола (Powerlink V3) стала возможна синхронизация сразу нескольких распределённых сегментов по протоколу IEEE 1588. Тем не менее, даже в этом случае жёсткая детерминированность обеспечена лишь для каждого сегмента в отдельности.

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

PROFINET – «профи» в Ethernet

PROFINET – наиболее известный стандарт Ethernet реального времени, совместимый со стеком TCP/IP. Его называют Ethernet-версией протокола PROFIBUS, поскольку у них много общего и они легко сопрягаются через шлюз. Протокол изначально разработан компанией Siemens, стандартизован по IEC 61158 и сейчас находит применение в устройствах целого ряда производителей.

Существуют две концепции применения протокола PROFINET: PROFINET IO (распределённые системы ввода-вывода) и PROFINET CBA (модульные системы управления, объединение сетей PROFINET). Более распространённым случаем является PROFINET IO, предполагающий непосредственное подключение к сети устройств полевого уровня.

Все устройства в сети PROFINET IO можно разделить на 3 типа: IO Controller (ПЛК или иной контроллер, мастер сети), IO Supervisor (станция оператора, HMI, станция управления), IO Device (распределённые датчики, исполнительные механизмы полевого уровня, ведомые устройства в сети).

В PROFINET существует три режима работы протокола, каждый со своей степенью детерминированности: PROFI-NET V1, PROFINET SRT и PROFINET IRT. Первый вариант обеспечивает время ответа системы в пределах 10–100 мс и используется преимущественно для администрирования устройств сети. PROFINET SRT работает на порядок быстрее: 5–10 мс, реализован целиком на программном уровне, в качестве транспортного протокола использует стек TCP/IP. PROFINET IRT является третьей «итерацией», именно он используется в системах жёсткого реального времени.

PROFINET IRT на порядок быстрей второй версии и гарантирует время цикла 1 мс с точностью 1 мкс. Конечно, для такой скорости работы уже потребовалась аппаратная реализация. Поэтому каждый участник сети имеет встроенный контроллер, ответственный за синхронизацию (используется видоизменённый протокол IEEE 1588) и обмен данными по PROFINET.

В PROFINET IO используются режимы реального времени PROFINET SRT и PROFINET IRT, но чаще последний.

Организация обмена данными в жёстком реальном времени чем-то схожа с Powerlink: обмен данными происходит жёсткотактируемыми циклами, в которых есть фаза изохронной (критичной ко времени доставки) передачи данных и фаза передачи данных в формате TCP/IP.

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

Чтобы минимизировать потребность в промежуточных коммутаторах, у каждого устройства PROFINET, как правило, имеется 2 сетевых порта и более. В случае использования внешнего коммутатора заявленное время цикла увеличится. Коммутаторы должны быть управляемыми с поддержкой виртуальных сетей VLAN и управлением качеством обслуживания QoS.

IEEE 1588 – микросекундная точность

Синхронизация системных часов – дело не новое. Уже давно известны протоколы NTP (Network Time Protocol) и его производная SNTP (Simple Network Time Protocol), однако их точность синхронизации (несколько миллисекунд) далеко не всегда достаточна в современных системах. Более точный метод – синхронизировать системные часы через спутник по GPS, однако этот способ часто невыгоден ввиду высокой стоимости оборудования, интеграции и обслуживания. Достигнуть высокой точности синхронизации при относительно простой реализации удалось в протоколе IEEE 1588.

Протокол IEEE 1588, также известный как РТР (Precision Time Protocol), определён как «Протокол для высокоточной синхронизации независимых часов различных устройств в распределённых системах измерения и контроля». Используется (или может использоваться) во всех перечисленных протоколах реального времени в качестве механизма синхронизации. Кроме сетей Ethernet, применяется и в других областях, например в радиорелейной связи.

Для работы в реальном времени каждый абонент должен иметь аппаратные часы реального времени. Алгоритм синхронизации следующий. Все ведущие часы периодически рассылают телеграммы (Sync message) с указанием расчётного времени покидания этими телеграммами своего источника. Ведомые часы сохраняют соответствующее время получения этих телеграмм. Ведущие часы сверяются с мастер-часами и рассылают следующие телеграммы (Follow-up message) с точным временем посылки. Ведомые часы сравнивают время посылки с временем получения и корректируют своё время. Мастер-часы выбираются протоколом автоматически, исходя из их точности, разрешения и пр. Они могут быть специальным внешним устройством со спутниковой синхронизацией.

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

Протокол IEEE 1588 часто применяется в точных измерительных системах, в энергетике для оперативного контроля величин токов и в других системах жёсткого реального времени.

Реальное оборудование для реального времени

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

Одним из «паровозов» в реализации полевых шин и систем реального времени можно назвать немецкую компанию Hilscher. Вот уже более 20 лет эта компания занимается разработкой интегральных схем и чип-контроллеров всех известных стандартов полевых шин. В первую очередь, компания известна крупным производителям средств автоматизации, применяющим OEM-модули Hilscher в своих изделиях (ABB, GE Fanuc, Honeywell, Bosch, Moeller, Schneid Electric, WAGO и др.). Однако Hilscher серьёзно занимается и производством готовой продукции, которую мы рассмотрим.

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

Чип NetX содержит ARM-процессор, память SDRAM, 2 интерфейса (Ethernet и Fieldbus), таймер реального времени IEEE 1588, и шины USB, UART, I2C, GPIO. Обмен данными может осуществляться в режимах Dual-Port-Memory (DPM) или Direct-Memory-Access (DMA). Достоинство чип-контроллера NetX в том, что он является универсальной платформой для протоколов EtherCAT, EtherNet/IP, Powerlink, PROFI-NET, Modbus TCP/IP, SERCOS III. То есть для реализации выбранного протокола достаточно загрузить соответствующую готовую прошивку в контроллер и сконфигурировать его в сети. Этот чип нашёл применение в линейке Hilsher CifX.

Серия Hilscher CifX – это интерфейсные платы и модули различных форм-факторов:

• PCI, PCI Express x1, MiniPCI-платы;

• плата CompactPCI 3U;

• модуль формата PCI-104+;

• встраиваемые микромодули с интерфейсом USB или UART/I2C;

• комплекты для самостоятельной разработки коммуникационных средств Real-Time Ethernet;

• платы-анализаторы сетей Real-Time.

Самое распространённое устройство – PCI-плата Hilscher CifX 50-RE, которую можно видеть на рисунке 6.

В основе оборудования серии CifX лежит упомянутый чип-контроллер Hilscher NetX. Благодаря NetX устройства серии CifX просты и универсальны в применении. Плата или модуль содержит 2 порта RJ-45 и при включении конфигурируется для работы по выбранному протоколу с помощью прилагаемых утилит. На поставляемом с устройством диске содержатся стеки протоколов EtherCAT, EtherNet/IP, Powerlink, PROFINET, Modbus TCP/IP, SERCOS III. Каждый контроллер может свободно использоваться как ведомое устройство для любого из этих протоколов. Функционирование в режиме мастера сети также доступно для большинства протоколов при приобретении единой лицензии от Hilscher.

Интерфейсные платы и модули Hilscher серии CifX применяются для интеграции локальных рабочих мест оператора, панелей визуализации и пр. Однако встраиваемые модули помогут объединить в сеть реального времени гораздо больший круг устройств, от контроллера до сканера штрих-кодов.

Кроме специального аппаратного обеспечения, для реализации сети реального времени требуется программная среда, позволяющая на-строить коммуникационные параметры участников сети. Компания Hilscher прилагает к своим изделиям специальную программу-конфигуратор Sycon.net. Она позволяет загрузить в плату прошивку нужного протокола, «понимает» стандартные конфигурационные файлы-профили оборудования (с расширением EDS, GSD, XML и пр.) для конфигурирования оборудования сторонних производителей, поддерживает технологии FDT/DTM. Все операции проводятся в визуальном режиме, что повышает информативность и снижает требования к квалификации настройщика.

От полевых шин к Ethernet реального времени

Не менее важной задачей при внедрении сетей Ethernet реального времени является их сопряжение с имеющимися полевыми шинами. Например, если нижний уровень систем автоматизации исправно работает на PROFIBUS, а сеть новых ПЛК подразумевает PROFINET, то нужен шлюз, обеспечивающий «бесшовное» соединение обеих сетей. Компания Hilsher предлагает универсальное решение подобных проблем – шлюз NetTAP 100.

В основе его – тот же универсальный чип NetX. Устройство подключается к шинам PROFIBUS, CANopen, Device-Net и CC-Link с одной стороны, и к сетям Real-Time Ethernet с протоколами EtherCAT, EtherNet/IP, Powerlink, PROFINET и SERCOS III с другой стороны. Тип полевой шины выбирается изначально (разная аппаратная часть), тип Ethernet-протокола определяется загруженной прошивкой.

Диагностика и конфигурирование NetTAP 100 осуществляются по USB-интерфейсу с помощью специального ПО (утилита Sycon.net). Конфигурация сохраняется на SD/MMC-карте памяти и может быть загружена на любой другой NetTAP 100.

Корпус NetTAP 100 крепится на DIN-рейку, что позволяет применять устройство в типовых системах АСУ ТП. На корпусе имеется разъём для подключения внешнего питания (18–30 В, пост. ток), USB, панель адреса, индикаторы, разъём D-Sub для Fieldbus и 2 коннектора RJ-45 для Ethernet-соединения по линейной топологии.

Коммутаторы в сетях Ethernet реального времени

Как уже упоминалось ранее, несмотря на совместимость протоколов Real-Time Ethernet со стандартным IEEE 802.3 Ethernet, первую сеть рекомендуется максимально отделять от второй и по возможности вообще не использовать коммутаторы и активное оборудование. Внешняя сеть может вносить много паразитного трафика, который будет отрицательно сказываться на времени доставки критичных ко времени данных. Сегмент сети реального времени хорошо отделить маршрутизатором, фильтрующим всякий широковещательный трафик. Если сеть реального времени физически является частью общей сети, то она должна находиться в одном сегменте внутри виртуальной сети VLAN.

Раньше мы всегда различали коммутаторы и концентраторы. В сегменте сети реального времени предпочтительнее использовать именно концентраторы (hub), а не коммутаторы (switch), но сейчас первые уже канули в лету. Преимущество коммутаторов (интеллектуальное распределение пакетов данных) перед концентраторами является их же недостатком в случае с Real-Time Ethernet. Архитектура Store and Forward, в отличие от концентраторов, передающих пакеты данных на лету, сначала сохраняет пакет в памяти, затем передаёт дальше, внося дополнительную задержку. Размер этой задержки чётко не определён и зависит от множества факторов. В частности, в незагруженной сети у стандартного коммутатора для пакета данных длиной в 64 байта задержка Fast Ethernet составляет порядка 10 мкс, а для самого большого пакета длиной 1518 байт – уже до 150 мкс. Но даже при незначительной загрузке сети эти значения могут неконтролируемо возрастать. Таким образом, сохранение режима реального времени для сети, включающей коммутаторы, зависит от величины максимального времени доставки данных (определяется технологическим процессом) и проверяется на практике.

Поэтому в целом протоколы Ethernet реального времени не требуют специальных коммутаторов. Используются управляемые коммутаторы с поддержкой VLAN и IGMP Snooping, с управлением Multicast, QoS. Однако есть коммутаторы с дополнительной аппаратной поддержкой протоколов реального времени. Их применение позволяет кардинально сократить максимальное время доставки данных, что важно в сетях, обслуживающих системы измерения, позиционирования и другие высокоскоростные процессы.

Аппаратную поддержку протокола реального времени демонстрируют немецкие коммутаторы производства Hirsch-mann, бренда с мировой известностью, входящего в группу Belden. Hirschmann, будучи передовым разработчиком решений для Industrial Ethernet, совместно с Институтом прикладных наук Цюриха (Швейцария) был первым, кому ещё в 2004 году удалось реализовать поддержку протокола IEEE 1588 в серийных моделях промышленных коммутаторов Ethernet.

С точки зрения реализации РТР в сети, все системные часы делятся на конечные (часы у конечных устройств с одним сетевым портом) и пограничные часы (у коммутаторов и т.п.). Синхронизация часов происходит с одними мастер-часами в сети по схеме ведущий–ведомые. Таким образом, при построении сети с коммутаторами их восходящие порты будут в структуре граничными ведомыми часами, а нисходящие порты – граничными ведущими часами.

В 2008 году была принята вторая версия протокола IEEE 1588-2008, которая предполагает новый тип «сквозных» часов вместо пограничных. Сквозные часы исключают промежуточную синхронизацию (этап Follow-up message) и позволяют тем самым повысить точность.

Суть аппаратной доработки такова, что параллельно микросхеме, реализующей MAC-адрес порта, ставится схема аппаратной синхронизации по протоколу PTP (IEEE 1588). Последняя соединена с часами точного времени, выполняющими функцию ведомых пограничных часов в структуре РТР. Аппаратная реализация протокола в коммутаторах Hirschmann позволяет повысить точность синхронизации часов до долей микросекунд – порога, недостижимого для стандартных коммутаторов, даже с использованием предшественников PTP, протоколов NTP и SNTP. Более того, на сегодняшний момент компания Hirschmann реализовала поддержку РТР версии 2, вышедшей в 2008 году. Для этой версии точность синхронизации составляет ± 60 наносекунд. В практических реализациях цепочка из 30 коммутаторов позволяет синхронизировать системные часы с точностью ± 200 нс.

Протокол PTP (первая и вторая версии) интегрирован в старшие модели оборудования Hirschmann. Он поддерживается следующими коммутаторами:

• модульные коммутаторы серии MICE-RT. Состоят из базового модуля с «горячей» установкой до 6 интерфейсных модулей – всего до 24 портов Fast+Gigabit Ethernet. Компактны, устанавливаются на DIN-рейку;

• компактные моноблочные коммутаторы Gigabit Ethernet серии RS40. Имеют 9 портов RJ-45, 4 из которых комбинированы с оптическим портом SFP;

• стоечные коммутаторы формата 19" 1U серии MACH1040. Содержат 16 комбинированных (RJ-45/SFP) портов Gigabit Ethernet. Серия сертифицирована по IEC 61850 для применения в электрических подстанциях. Коммутатор представлен на рисунке 7;

• коммутаторы со степенью защиты IP68 серии OCTOPUS. Выполнены в литом металлическом корпусе с герметичными винтовыми разъёмами М12. Выдерживают погружение в воду, пыленепроницаемы. Содержат до 24 портов Fast+Gigabit Ethernet. Соответствуют нормам EN 50155 для подвижных железнодорожных составов.

Все перечисленные модели являются управляемыми промышленными коммутаторами второго уровня OSI. В них реализован широкий функциональный набор средств фильтрации и управления трафиком, ограничения доступа, резервирования каналов, среди которых поддержка VLAN, QoS, резервированного кольца HIPER-Ring, MRP-ring, протокола RSTP и возможности объединения нескольких портов в один «транк». Во всех сериях есть модификации для жёстких условий эксплуатации. Коммутаторы просты в обращении и имеют понятный интерактивный Web-интерфейс.

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

Также аппаратная поддержка PTP в коммутаторах даёт возможность соблюдать условия жёсткого реального времени при использовании протокола EtherNet/IP. Благодаря интегрированной в коммутатор возможности аппаратной синхронизации часов точного времени компенсируются все задержки передачи сигнала, вносимые коммутаторами. В результате максимальное время доставки данных может сократиться в тысячу раз.

Заключение

В различных системах автоматизации и управления предъявляются разные требования к сетям передачи данных. Например, цикл передачи данных для перечисленных сетей составляет примерно следующие значения:

• для сети, обслуживающей низкоскоростные датчики (измерение температуры, влажности, давления), – до 100 мс,

• для сети в системах управления приводами – до 10 мс,

• для сети в системе позиционирования, контроля перемещения – до 1 мс, для особо точного позиционирования – десятки микросекунд,

• для сети в системах электронного измерения – порядка микросекунды.

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

Если сравнивать возможности протоколов EtherNet/IP, PROFINET, EtherCAT, Powerlink и IEEE 1588 с типовыми требованиями технологических процессов, то, как говорится, есть из чего выбрать. Получается, большинство технологических процессов можно реализовать, используя сеть Ethernet и один из протоколов реального времени. Несмотря на все плюсы IEEE 802.3 Ethernet как базы, переход на неё осуществляется медленно. Причины банальны: трудности с освоением новых технологий, задержки с их внедрением в серийные устройства производителями, инерционность проектировщиков, использующих потом эти серийные продукты.

В помощь процессу перехода от традиционных сетей Fieldbus к Real-Time Ethernet – «наследственные признаки» протоколов второй группы, то есть сходство в техническом плане и где-то совместимость с протоколами Fieldbus. Так, в PROFINET можно найти много от PROFIBUS, Powerlink можно на-звать Ethernet-наследником шины CAN, EtherNet/IP перенял черты DeviceNet.

Аппаратная и программная базы для перехода готовы: доступен целый ряд средств автоматизации нижнего и среднего полевого уровня, в том числе представленные платы-контроллеры и преобразователи протоколов Hilscher и коммутаторы Real-Time Ethernet производства Hirschmann. ●

Автор – сотрудник фирмы ПРОСОФТ
Телефон (495) 2340636
Email: info@prosoft.ru