Как работает протокол PRP?

Рассматриваем работу протокола параллельного резервирования PRP.

June 1, 2013, 5 p.m. | 4901

Все больше производителей нетрадиционных измерительных преобразователей (например, волоконно-оптических преобразователей тока и напряжения) и устройств сопряжения с шиной процесса согласно МЭК 61850-9-2LE реализуют поддержку протокола резервирования PRP (Parallel Redundancy Protocol). Поддержку данного протокола резервирования также реализуют производители устройств релейной защиты и автоматики (РЗА) – причем не только в части интерфейса МЭК 61850-9-2LE, но также и в части интерфейса шины станции МЭК 61850-8-1, посредством которого производится обмен данными с другими устройствами РЗА на энергообъекте (согласно протоколу GOOSE) и с системами АСУ ТП (согласно протоколу MMS).

Одним из достоинств протокола резервирования PRP является то, что нарушение исправности канала связи или коммутатора сети Ethernet не приводит к возникновению паузы в информационном обмене между устройствами сети, как это например происходит в сети, функционирующей под управлением протокола RSTP (Rapid Spanning Tree Protocol), когда на переконфигурацию сети после повреждения требуется некоторое время, в течение которого связь между устройствами отсутствует.

При использовании протокола PRP требуется создание двух независимых друг от друга локальных сетей (локальной сети А и локальной сети B) произвольной топологии — как это показано на рис. 1. Соответственно, устройства, выполняющие прием и отправку данных по условиям протокола PRP, должны иметь два независимых интерфейса для подключения к этим сетям.

Рис. 1. Топология сети Ethernet при использовании протокола PRP.

Поддержка устройствами РЗА протокола резервирования PRP заключается в том, что при отправке данных они способны добавлять в фрейм Ethernet так называемый Redundancy Сontrol Trailer (RCT), который мы далее будем именовать как трейлер PRP (см. рис. 2), а при приеме данных — способы анализировать, согласно определенному алгоритму, кадры Ethernet с трейлером PRP, полученные от других устройств.

Трейлер PRP включает в себя следующие параметры:

  1. 16-битный номер посылки в последовательности посылок;
  2. 4-битный идентификатор локальной сети, по которой осуществлялась передача посылки (1010 (0xA) для локальной сети А и 1011 (0xB) для локальной сети B);
  3. размер фрейма данных (LSDU) (12 бит).
  4. cуффикс PRP (на рис. 2 – RCT-маркер).

Рис. 2. Трейлер PRP в фрейме Ethernet.

Устройство-отправитель с поддержкой протокола PRP выполняет передачу идентичных пакетов с соответствующими трейлерами PRP в две независимые локальные сети. Устройство-приемник, обладающее поддержкой протокола PRP, также подключается к двум независимым локальным сетям, но обрабатывает только один пакет из двух, поступивших на его сетевые интерфейсы — либо из сети А, либо из сети B – в зависимости от того, какой из них поступил раньше/какой из них корректный. Второй экземпляр пакета отбрасывается. Дубликаты обнаруживаются и отбрасываются устройством-приемником как раз на основе анализа трейлера PRP.

Рис. 3. Пакет МЭК 61850-9-2LE с трейлером PRP.

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

Важным аспектом является сохранение трейлеров PRP при передаче посылок коммутаторами локальных сетей А и B – важно, чтобы они дошли в их исходном виде до конечных устройств с поддержкой PRP.

С учетом трейлера PRP максимальный размер тегированного Ethernet фрейма (согласно IEEE 802.11q) может превышать 1522 октета (что является пределом для тегированного фрейма без PRP). Все сертифицированные коммутаторы должны без каких-либо проблем пропускать фреймы размером до 1536 октет. На практике, однако, возникают случаи, когда коммутаторы работают не так как положено, исключая трейлер PRP и, в некоторых случаях, даже теряя пакеты.

Latest blog posts

Transmission of data structures in a GOOSE message
Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.

Software Based Centralized Protection: commissioning experience
Software Based Centralized Protection: commissioning experience

In 2018 Tekvel signed several contracts to commission centralized protection system based on servers and independent software. In this article we would like to share our experience and discuss some of the problems, that might require special attention from utilities on the way to mass deployment of centralized PAC systems.

Alex Apostolov about the past, present and the future of relay protection
Alex Apostolov about the past, present and the future of relay protection

The new episode of Big Energy, produced by Tekvel team, is already on YouTube. This time we met Alex Apostolov - editor-in-chief of PAC World magazine and principal engineer of OMICRON electronics - who is one of the most well-known and reputable protection and control engineers in the world. Enjoy, like and share with engineers community!