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

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

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

Все больше производителей нетрадиционных измерительных преобразователей (например, волоконно-оптических преобразователей тока и напряжения) и устройств сопряжения с шиной процесса согласно МЭК 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

Disrespectful Sampled Values subscriber behaviour
Disrespectful Sampled Values subscriber behaviour

Teaser: Some IEDs require that SV (or maybe GOOSE) messages on ingress port of the IED have proper VLAN tag (as configured in the subscription), thus resulting in failure to receive the untagged messages (or messages with another VLAN ID tag). Such behaviour of an IED is wrong but sometimes you can meet this. Read the full article to dig into the details.

When GOOSE can't fly!
When GOOSE can't fly!

Everyone who ever dealt with the commissioning of IEC 61850 based systems had situations when there were problems in establishing successful GOOSE communications between IEDs. The reasons for that are always different. There may be a fault of the commissioning engineer, a fault of the vendor or it may be a fault of both parties at the same time. We have faced such situation recently and this was the case when one could blame... decide yourself who is to blame in this situation, having read this note about nuances in configuring GOOSE-communications between IEDs of two different vendors.

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.