Задачи узла отправителя

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

1. Пакет нужно сформировать, следует сказать, что IP-пакет состоит из двух частей: заголовка, в котором находится вся необходимая информация для обработки пакета узлами компьютерной сети и поля данных. Сам IP никаких данных не генерируют, процесс IP получает данные от вышестоящего процесса, если вышестоящим процессом является транспортный уровень, то обычно это такие протоколы как UDP, TCP, SCTP, но вышестоящим процессом может быть и протокол сетевого уровня, например, протокол ICMP, который используется когда мы хотим чего-нибудь попинговать. Кто бы ни был вышестоящим процессом его данные помещаются в соответствующее поле данных в пакете, а затем накрываются заголовком.

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

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

4. И наконец IP-пакет запаковывается в кадр канального протокола, далее кадр превращается в битовую последовательность, которая направляется в сеть через выбранный интерфейс.

Вроде бы никаких хитрых действий отправитель не совершает.

Задачи узла получателя

Задачи получателя несколько более простые:

1. Пакет нужно получить и убедиться в двух вещах:

   1. Получатель должен убедиться, что именно он является получателем.

   2. А также проверить корректность полученных данных.

2. Далее данные передаются вышестоящему процессу, который уже решит что с ними делать.

Если получатель сочтет нужным, то он в дальнейшем может послать ответ отправителю.

Задачи маршрутизатора (транзитного узла)

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

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

2. Далее требуется определить какому из соседей по канальной среде следует передавать пакет. Если роутер в одной канальной среде с получателем, то пакет будет передан непосредственно ему, если же нет, то следующему транзитному узлу.

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

4. Если требуется модификация пакета, то пакет модифицируется, а затем отправляется в выбранный интерфейс.

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

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

Топология и подготовка лабы

С теорией всё, давайте соберем простенькую лабу и посмотрим на IP устройства в эмуляторе. Для практики по данной теме буду использовать CPT. Пока мы ничего не будем настраивать, просто посмотрим, что эмулятор будет нам рассказывать о действиях узлов.

Схема, на которой будем тренироваться выглядит так:

Пояснения к схеме:

1. Оранжевым обведены хосты.

2. Зеленым роутеры.

3. Синим коммутатор, в данном случае мы его не рассматриваем как IP-устройство, сейчас можно представить, что это не коммутатор, а связка проводов, которая соединяет PC2, PC3 и RO2 вместе.

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

Лабу нужно перевести в режим симуляции, а затем настроить фильтр пакетов, которые мы хотим видеть, всё это можно сделать кнопками в правом нижнем углу программы.

Кнопка Edit Filters отвечает за появление окна на скрине выше, на вкладках IPv6 и Misc тоже нужно отключить отображение всех прочих пакетов.

Взаимодействие отправителя и получателя

Начнем с более простого, то есть с той ситуации, когда отправитель и получатель находятся в одной канальной среде. На схеме между PC2 и PC3 есть коммутатор, но для IP он полностью прозрачный, можно считать что этих два устройства с точки зрения IP соединены напрямую проводом.

Выполним пинг с PC2 на PC3, нужно открыть командную строку PC2 сделать это можно так:

1. В топологии кликаем на иконку PC2.

2. Появится окно, в котором нужно будет выбрать вкладку Desktop.

3. На вкладке Desktop выбираем иконку Command Prompt.

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

После того, как мы ввели команду и нажали Enter, PC2 сформировал два пакета:

1. Синий, это как раз тот пакет, который нас интересует, то есть ICMP.

2. Зеленый, это кадр с ARP запросом, он нам не интересен, сейчас нам лишь важно понимать, что протокол ARP поможет PC2 узнать канальный адрес узла PC3, в данном случае это мак-адрес.

Посмотрим содержимое синего пакета, клацнув в него.

Появившееся окно имеет две вкладки: OSI Model и Outbound PDU Details. Нам интересна первая, вторую даже смотреть не будем, на ней представлена детальная информация о структуре кадров и пакетов, она нам сейчас не интересна.

На вкладке OSI можно по шагам посмотреть что делает тот или иной узел при приеме или отправке пакета. За прием отвечает In Layers, за передачу отвечает Out Layers. Как видите, каждая половина разбита на семь уровней, это семь уровней модели OSI, если шрифт уровня тускло серого цвета, значит на нем ничего не происходит, если шрифт черный, значит на этом уровне что-то происходит и он кликабельный, переключаться между уровнями можно еще и кнопками Previous Layer/Next Layer.

На рисунке выше CPT нам показывает, что делает узел отправитель(PC2) на сетевом уровне :

1. PC2 запустил процесс Ping сразу после того, как мы выполнили команду ping.

2. Процесс Ping создает сообщение ICMP Echo Request и отправляет его нижележащему процессу. Здесь следует пояснить, что ICMP и IP это протоколы сетевого уровня, но для ICMP процесс IP это нижележащий процесс.

3. Отправитель должен подставлять в пакет свой IP-адрес, чтобы обратная сторона могла ответить, если она сочтет это нужным. При выполнении команды ping не был задан IP-адрес, поэтому устройство выбрало адрес само (оптимальный на взгляд устройства, хотя по факту он там настроен один).

4. PC2 установил, что IP-адрес узла получателя находится с ним в одной подсети, а также в пакет был добавлен IP-адрес узла получателя.

А вот что CPT нам может рассказать о канальном уровне.

На канальном уровне:

1. Узел PC2 определил, что IP адрес получателя юникастовый, а это значит, что узел должен знать или определить мак-адрес получателя. Чтобы определить канальный адрес соседа узел запустил процесс ARP.

2. Первым делом ARP проверил свою таблицу, чтобы найти: какой мак-адрес соответствует IP-адресу, который мы пингуем (192.168.0.1), но такого соответствия он не обнаружил, поэтому PC2 сформировал ARP-запрос и сохранил ICMP пакет в свой буфер(то есть на текущем шаге синий пакет отправлен никуда не будет).

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

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

1. ARP-запрос PC2 использует, чтобы изучить канальный адрес соседа, в сторону которого должен быть отправлен пакет с ICMP.

2. ARP-запрос получат все соседи PC2 по канальной среде, но ответ даст только тот сосед, чей IP-адрес будет указан в ARP-запросе, все остальные проигнорируют этот ARP-запрос. И тут два момента: если соседей с таким IP нет, то никто и не ответит; если сосед с таким адресом есть, то он ответит, в ответе будет содержаться его мак-адрес.

Вот что по этому поводу нам показывает CPT:

Узел RO2 получил запрос и проигнорировал его, это видно по красному крестику, а вот узел PC3 готов ответить на запрос. Что делает PC3 для отправки ARP мы пропустим, но в итоге мы приходим к той ситуации, что узел PC2 получил ARP ответ и изучил мак-адрес соседа, в сторону которого надо отправить пакет.

Зеленый пакет ниже это и есть ARP-ответ PC3, а синий пакет, это тот ICMP, который ранее был спрятан в буфер.

Давайте рассмотрим дальнейшие действия PC2, уже после того, как он изучил мак-адрес нужного соседа.

Напомню, что остановились на том, что у канального уровня не было мак-адреса соседа, в сторону которого надо было посылать пакет, теперь мы этот адрес знаем, поэтому:

1. ICMP пакет был извлечен из буфера для дальнейшей обработки.

2. PC2 инкапсулирует(помещает/запаковывает) IP пакет, внутри которого ICMP, внутрь Ethernet кадра.

И тут мы видим что физический уровень стал кликабельным.

А на L1 мы видим, что отправитель выбрал свой интерфейс, через который он будет готов послать сообщение в сеть, на физическом уровне Ethernet кадр превращается в последовательность бит.

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

Здесь мы видим изменения:

1. На вкладке OSI появилось описание того, что происходит на приеме, т.е. теперь у нас информация по In Layers и Out Layers.

2. Вкладок PDU Details тоже стало две.

Сейчас мы не будем заходить на вкладку из пункта два. Что касается первого пункта: PC3 должен сперва принять пакет, т.е. выполнить действия получателя, они описаны под заголовком In Layers, а затем он должен будет дать ответ, т.е. PC3 становится отправителем, что он делает для ответа описано под заголовком Out Layers.

Также вы могли заметить что прием выполняется снизу вверх, а передача наоборот, сверху вниз. PC3 на физическом уровне получает битовую последовательность по порту FastEthernet0 и превращает ее в кадр Ethernet. Переходим на канальный уровень.

Здесь узел PC3 убеждается:

1. Что мак-адрес это мак-адрес, который присвоен одному из интерфейсов PC3, либо это широковещательный мак-адрес, любо это мак-адрес многоадресной рассылки, на который должен отвечать PC3. По факту в данном случае мак-адрес юникастовый и он принадлежит PC3.

2. Ввиду того, что мак-адрес назначения, указанный в кадре, принадлежит PC3, можно снять Ethernet заголовок и заглянуть и обнаружить под ним IP-пакет.

Переходим на сетевой уровень.

Здесь происходит следующее:

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

2. Внутри пакет обнаружилось ICMP вложение, которое надо передать процессу ICMP.

3. ICMP процесс установил что тип полученного сообщения это ICMP Echo Request, на который нужно дать ответ.

И вот мы на границе, когда один и тот же узел превращается из отправителя в получателя. Посмотрим, что делает PC3 для отправки ответа, ответ начинает формироваться на сетевом уровне и спускается вниз к физическому.

Действия узла такие:

1. ICMP процесс решает что на данный Request следует ответить сообщением типа ICMP Echo Reply.

2. Сообщение Echo Reply отправляется процессу IP.

3. Узел видит, что IP-адрес назначения находится в одной подсети с ним, а значит пакет можно отправлять непосредственно получателю.

ICMP вложение накрывается IP заголовком и передается на канальный уровень.

1. PC3 установил что IP-адрес назначения юникастовый, а значит надо запустить ARP процесс для того, чтобы узнать канальный адрес соседа.

2. Мак-адрес соседа находится в ARP-таблице, поэтому в дальнейшем в Ethernet-кадр в поле мак-адрес назначения будет подставлен мак-адрес, соответствующий IP-адресу 192.168.0.2, взятый из ARP-таблицы.

3. IP-пакет накрывается Ethernet-заголовком, тем самым формируется Ethernet кадр.

На физическом уровне ничего интересного нет, PC3 для отправки выбрал интерфейс Fa0, превратил кадр в битовую последовательность, которая и была направлена в сеть. В итоге ответ PC3 дойдет до PC2 и когда PC2 получит этот ответ, произойдет изменение в командной строке, появится диагностическая информация о том, что узел PC3 доступен.

Исходный отправитель превратился в получателя. Получение пакета на канальном и физическом уровнях для PC2 ничем не будут отличаться от действий на PC3, поэтому оставляю этот момент без комментариев. Вот что происходит на сетевом уровне уровне:

1. Первым шагом PC3 видит, что пакет принадлежит ему, а значит, надо снять IP заголовок.

2. Под заголовком обнаруживается ICMP вложение, оно предается ICMP процессу.

3. ICMP процесс видит, что это Reply на Request, посланный ранее.

4. Процесс Ping получает от ICMP сообщение Echo Reply, в этом сообщение содержится диагностическая информация, которая затем отображается на экране командной строки.

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

По итогу:

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

2. Поверхностно разобрались с тем, как связаны канальный и сетевой уровни.

3. И убедились, что функции отправителя и получателя может выполнять одно и то же устройство.

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

Видео версия

Вот здесь теоретическая часть:

Вот здесь про прямое взаимодействие хостов:

p.s. Вопросы на подумать к данной теме смотрите в конце поста со второй частью.

Словосочетание "не гарантирует доставку пакетов" немного раскрою:

• пакеты на сети теряются, потерянный пакет IP не будет пытаться восстановить или повторно переслать, если IP-пакет потерялся, то он потерялся, средств по восстановлению пакетов или повторной их пересылки в IP нет;

• пакеты в ходе передачи могут быть изменены, иногда это делается намеренно, например, изменяется значение поля TTL, а иногда нет, например, пакет искажается из-за того что физический канал не надежный, вообще, IP никак не контролирует пользовательские данные, в заголовке пакета есть контрольная сумма, но она считается только для заголовка;

• пакеты, которые были отправлены позже, могут прийти в пункт своего назначения раньше;

• пакеты дублируются, IP это не контролирует, иногда это бывает полезно, иногда не очень.

Есть еще и третий способ разделить протоколы на группы: бывают протоколы, которым необходимо установить соединение перед началом передачи данных, в ходе установления соединения участники согласовывают параметры передачи. А бывают протоколы, которые не требуют установление соединения и начинают сразу слать пакеты адресатам. IP относится ко вторым.

История протокола IP

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

Ограничусь лишь сегодняшним днем. У нас существует две актуальные версии протокола IP: IPv4 и IPv6. Работают они практически одинаково, на начало 2024 года могу сказать, что IPv4 будет еще долго актуальным, изучение немного проще начать с него, поэтому здесь и далее, если я пишу IP, то имею ввиду именно IPv4.

Ресурсы для изучения IP и вообще сетевых технологий

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

Во второй список вошли:

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

2. Пособия по подготовке к экзаменам вендоров, сам вендор не важен: HP, Cisco, Juniper, Huawei или любой другой.

3. Статьи и публикации в интернете, желательно на открытых для стороннего мнения площадках, например, Хабр.

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

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

Вот некоторые RFC для IP:

• RFC 791 это спецификация протокола IP;

• RFC 5737 содержит в себе перечень блоков IP-адресов, зарезервированных документации;

• RFC 919 это правила распространения широковещательного трафика;

• RFC 1918 описывает блоки IP-адресов, которые можно использовать в частных сетях;

• RFC 1122 описывает требования к программной реализации хостов на сетевом, канальном и транспортном уровнях.

На самом деле RFC огромное множество, есть и шуточные, которое, например, описывает работу протокола IP поверх голубиной почты RFC 2549.

Для тех, кому нравится больше смотреть:

https://www.youtube.com/watch?v=IzPgASpMG0Q&t=

p.s.

в завершении следующих постов буду стараться придумать 2-3 вопроса.

p.p.s.

Следующий пост о видах IP устройств и о том, чего они там такого делают. Готовлю, кнопка принтскрина потихоньку стерается :)

Усиление государственного регулирования в области энергосбережения (ФЗ 261 и другие нормативные акты) и сложность экономической ситуации в России стимулирует собственников к учету и экономии ресурсов. Соответственно увеличивается охват хозяйственной деятельности различных субъектов экономики приборами учета, и у каждого такого субъекта встает задача выбора наиболее подходящих ему приборов учета. Критерии такого выбора могут быть самые разные. Если у субъекта стоит задача автоматического сбора показаний счетчиков в единый центр учета энергоресурсов, то такие счетчики должны быть оснащены цифровым интерфейсом для передачи данных. В существующих решениях по построению распределенных АСКУЭ основной упор делается на выбор физической среды передачи данных от счетчика на верхний уровень (PLC-технология передачи по силовой линии, радиоканал, проводная связь RS 485, Ethernet и др.). Вместе с тем имеет определенное значение и используемый протокол передачи данных.

Несмотря на это, в настоящее время российские производители приборов учета не придерживаются какой-либо общепризнанной системы в выборе протоколов, вследствие чего наблюдается целый «зоопарк» разнообразных протоколов у производителей приборов учета. Это затрудняет их интеграцию в АСКУЭ. Учет используемых протоколов при осознанном выборе приборов может оказаться полезным для хозяйствующего субъекта. В настоящей статье приводится обзор широко используемых и перспективных протоколов передачи данных приборов учета, используемых в России и Европе. В обзоре рассматриваются протоколы, отвечающие российским/европейским стандартам, и не рассматриваются частные фирменные разработки, из-за их ограниченной сферы применения.

Протокол Modbus

Начнем с вездесущего протокола Modbus. Он используется в самых разных областях автоматизации, в том числе и в приборах учета электричества, газа, воды и тепла. Широко распространен как за рубежом, так и в России. Этот протокол основан на архитектуре ведущий/ведомый, может использоваться для передачи данных через последовательные интерфейсы RS 485/422/232, а также через сети TCP/IP. Типы данных – однобитовые (Coils) и целочисленные (Registers). К достоинствам данного протокола относится открытость, простота, массовое распространение, дешевизна технологии. Тем не менее, для задач учета этот протокол подходит не в полной мере.

Недостатки:

1. Определяет метод передачи только двух типов данных;

2. Не регламентирует начальную инициализацию системы. Назначение сетевых адресов и прописывание в системе параметров каждого конкретного устройства выполняются вручную на этапе адаптации и программирования системы;

3. Не предусмотрена передача сообщений по инициативе подчиненного устройства (прерываний);

4. Длина запроса ограничена, а данные могут быть запрошены только из последовательно расположенных регистров;

5. Не предусмотрен способ, с помощью которого подчиненное устройство могло бы обнаружить потерю связи с ведущим;

6. Соответствие регистров типам измерений и измерительным каналам не регламентировано.

На практике это может приводить к несовместимости протоколов счетчиков разных типов даже одного производителя и к необходимости поддержки большого числа протоколов и их модификаций встроенным ПО устройств сбора и передачи данных (УСПД) (при двухуровневой модели опроса – ПО сервера сбора) с ограниченной возможностью повторного использования программного кода.

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

Протокол DLMS/COSEM

Гораздо более сложным, чем протокол Modbus, является протокол DLMS/COSEM (IEC 62056), применяемый для учета электричества, газа, воды, тепла. Он распространен преимущественно за рубежом. Это стек ориентированный протокол, базирующийся на концепциях модели OSI, регламентирующий обмен данными между приборами учета и системами сбора данных, в основе которого лежит клиент-серверная архитектура.

DLMS – спецификация прикладного уровня, разработанная для стандартизации сообщений, передаваемых по распределительным линиям. Ею регламентируются: дистанционное считывание показаний с приборов учета, дистанционное управление, а также дополнительные сервисы для измерения любого вида энергоресурса.

COSEM – спецификация, в которой отражена интерфейсная модель приборов учета, обеспечивающая представление их функциональных возможностей. Интерфейсная модель использует объектно-ориентированный подход.

Достоинства протокола:

1. Возможность широкого выбора интерфейсов для передачи данных: RS 232/485, PSTN, GSM, GPRS, IPv4, PPP и PLC;

2. Определяет интерфейсную модель, действительную для любого типа энергоресурса. Система, построенная на базе протокола DLMS/COSEM, открыта для расширения путем добавления новых возможностей без изменения имеющихся сервисов;

3. Стандартизует функционал прибора учета: регистрация потребления, тарифное планирование, измерение качества электроэнергии и др.;

4. Обеспечивает контролируемый и безопасный доступ к информации внутри прибора учета (открытый доступ, доступ по паролю и с аутентификацией). Информация, передаваемая по коммуникационным линиям, может быть дополнительно зашифрована;

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

6. Широко распространен среди зарубежных приборов учета.

Однако у DLMS/COSEM есть и весомые недостатки:

1. Проблема полноты и “чистоты” реализации стандарта. На практике опрос счетчика с заявленной поддержкой DLMS одного производителя программой опроса другого производителя либо ограничен основными параметрами, либо попросту невозможен;

2. Большая сложность протокола;

3. Крайняя непопулярность среди отечественных производителей приборов учета.

Протокол M BUS

Далее рассмотрим протокол M BUS (ГОСТ Р ЕН +7(1434-3-2011, EN1434-3, EN13757). Сферой его применения являются преимущественно учет тепла и воды, также возможен учет электричества и газа. Он широко распространен в Европе, в России он тоже набирает популярность. Архитектура шины ведущий/ведомый. Используется стандартный телефонный кабель, шина полудуплексная, допустимые скорости передачи данных 300…9600 бит/с. Число устройств в сети – до 250 ед. Дальность работы в стандартной конфигурации до 1000 м. Логическая единица передается уровнем 36 В, с возможностью потребления от линии тока до 1,5 мА, логический ноль передается напряжением 24 В на master устройстве. Мастер передает данные меняя напряжение на линии: логической «1» соответствует 36 В, логической «0» 12…24 В. Ведомое устройство передает данные нагружением линии: в пассивном состоянии (логическая «1») ток нагрузки на линию связи должен быть ≤ 1,5 мА и не меняться в отсутствие передачи. Для передачи логического «0» ведомое устройство увеличивает ток потребления до 11…20 мА. Соответственно мастер отслеживает изменение тока нагрузки, определяя логическую «1» как неизменный ток, а увеличение тока потребления – как логический «0».

Стандарт тщательно оптимизирован для пониженного потребления и позволяет обходиться без отдельного внешнего источника питания конечного устройства, используя внутреннюю батарею и питание от самой линии, также отсутствует необходимость соблюдения полярности. Специфицирован также вариант M Bus для беспроводных сетей – Wireless M Bus (частота устройств 868,95 МГц).

Протокол хорошо проработан, его несомненными достоинствами являются:

1. Архитектура сети (витая пара) может быть практически любой топологии (кроме закольцованных);

2. Гарантированная передача данных относительно небольшого объема от большого числа приборов учета на расстояние до нескольких километров в условиях высокого уровня помех;

3. Умеренная стоимость оборудования и затраты на установку и эксплуатацию;

4. Простота расширения системы в течение эксплуатации;

5. Пассивное электропитание интерфейса Slave- устройств;

6. В развитии стандарта предлагается криптографическая защита данных с помощью симметричного шифра AES.

Недостатки протокола:

1. Применяется только в тех задачах, где не критична низкая скорость передаваемых данных;

2. Соответствие передаваемых данных типам измерений и измерительным каналам не регламентировано;

3. Ограниченный выбор оборудования на российском рынке для построения сетей M Bus. Недостаток справочной и технической документации.

ГОСТ Р МЭК 60870-5

Хорошо разработанным является набор протоколов по ГОСТ Р МЭК 60870-5 «Устройства и системы телемеханики. Часть 5. Протоколы передачи» (IEC 60870-5). Он используется, как правило, при интеграции систем телемеханики и учета электроэнергии. Например, при мониторинге состояния сетей 0,4/10 кВ. Он распространен за рубежом и несколько ограниченно в России. Это хорошо проработанный ряд стандартов, охватывающий разные уровни сетевого взаимодействия: начиная от физического уровня и кончая прикладным уровнем. На физическом уровне используется асинхронный интерфейс (UART). Диапазон скорости 300…9600 бод. Поддерживается также работа со стандартными сетями TCP/IP (Ethernet и модемное соединение). Возможно шифрование данных. Раздел +7(60870-5-102 является обобщающим стандартом по передаче интегральных параметров в энергосистемах. Стандарт +7(60870-5-104, например, может использоваться при передаче данных по Ethernet, а стандарт +7(60870-5-101 – при передаче данных через GSM/GPRS модем.

В качестве замечаний можно высказать следующее:

1. Поддержка этих протоколов счетчиками электроэнергии довольно ограничена;

2. Ограниченная поддержка протоколов системами верхнего уровня.

Стандарт PLC (IEC 61344)

Сферой применения стандарта PLC (IEC 61344) преимущественно является сбор данных с электросчетчиков. Также иногда допускается подключение расходомеров, теплосчетчиков, газовых корректоров. Распространен стандарт, как за рубежом, так и в России. Среда передачи данных — электросети среднего (4…30 кВ) и низкого напряжения (0,2…0,4 кВ). Для передачи данных используются различные виды модуляции электрического сигнала (S FSK, SS-FFH, OFDM, DCSK). Существуют сети PLC-I и PLC-II. Сети PLC-I могут выполнять статистические функции, то есть сбор и обработку информации за определенные временные отрезки, на основании которой производятся анализ и расчеты за потребленные виды энергии. АСКУЭ, построенная на базе оборудования PLC-II, кроме возможности статистического учета, может выполнять оперативно-измерительные функции, то есть в режиме, приближенном к режиму реального времени, отслеживать потребление и качество энергоносителей. Также через PLC-II можно управлять нагрузкой (включать/отключать потребителей). Основное назначение оборудования PLC-I – построение недорогой АСКУЭ бытовых потребителей. При необходимости получения более широкого набора данных необходимо развертывать более дорогие сети PLC-II. На большинстве объектов связь для PLC-I обеспечивается на расстоянии 400…800 м; на новых сетях, выполненных самонесущим проводом, – до 1000 метров. Для увеличения этого расстояния требуются ретрансляторы. Применение ретрансляторов увеличивает расстояние уверенного приема в 1,5…1,8 раза.

К достоинствам этого способа связи относятся:

1. Удешевление и упрощение монтажа за счет отсутствия необходимости прокладывать дополнительные информационные кабели для сбора данных. Это особенно важно, когда нужно сохранить интерьер помещений (особенно уже отремонтированных), или если сбор данных ведется с территориально разбросанных счетчиков (коттеджные и дачные поселки);

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

Недостатки:

1. Максимальная длина линии связи сильно зависит от качества силового кабеля («скрутки», плохие контакты или износ линий) и от наличия помех от подключенного оборудования (мощные моторы, преобразователи частоты, устройства плавного пуска). В случае «плохой» силовой линии иногда бывает невозможно ее использовать для передачи данных;

2. Ограниченный набор передаваемых данных в наиболее распространенных недорогих сетях PLC-I;

3. Несмотря на наличие стандарта IEC 61344, каждый производитель использует свои закрытые протоколы обмена данными, а часто и свои способы модуляции сигнала. Поэтому применение различных PLC-устройств в рамках одной сети 0,4 кВ проблематично, а часто и просто невозможно. Соответственно с один раз выбранным поставщиком придется работать долгие годы;

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

Заметим, что стоит отличать собственно стандарт PLC (IEC 61344) и PLC-технологию передачи данных по силовой линии. Указанная PLC–технология используется не только стандартом IEC 61344, но стандартами DLMS\COSEM, KNX, LonWorks и некоторыми другими.

Стандарт Euridis

В заключение в качестве достаточно нового зарубежного протокола рассмотрим Euridis (IEC 62056-31). Сферой его применения является учет электричества. Распространен он довольно ограниченно – преимущественно Франция, Северная Африка. В качестве среды передачи используется витая пара, длина линии – до 500 м, число устройств в сети – до 100 ед., скорость передачи – 1200 бит/с. Для связи используется асинхронная, полудуплексная, двунаправленная передача данных. В качестве положительных сторон данного протокола отметим наличие процедуры аутентификации для защиты данных и невысокую стоимость оборудования.

К недостаткам протокола отнесем:

1. Ограниченный регион распространения;

2. Небольшое число устройств с поддержкой данного протокола;

3. Ограниченную среду передачи – витая пара. Для использования других сред требуются шлюзы;

4. Применяется только в тех задачах, где не критична низкая скорость передаваемых данных.

Краткая оценка протоколов

Протокол Euridis, распространен только в отдельных регионах. Его применение ограничивается электроэнергетикой.

Протокол Modbus имеет большую популярность, но ему присущ ряд существенных недостатков, ограничивающих его применение в системах учета энергоресурсов. На сегодняшний день ModBus не способен решить проблему протокольной разобщенности измерительного и контрольного оборудования для энергосистем.

ГОСТ Р МЭК 60870-5 предоставляет достаточно гибкий набор протоколов, что кроме преимуществ вносит и дополнительные сложности: разные производители приборов учета/УСПД могут поддерживать разные протоколы, что затрудняет их интеграцию в единую систему. Хотя применение этого стандарта в настоящее время ограниченно преимущественно электроэнергетикой, в этой сфере у него сильные позиции.

Протокол M BUS является весьма перспективным, для него разработаны законченные АСКУЭ, создана Open Metering System – европейская инициатива, преследующая цель унифицировать сбор данных с приборов учета ресурсов на основе шины M BUS. Успехом завершились усилия по интеграции шины KNX и M BUS, что позволяет строить законченные решения по автоматизации зданий. Заметим все же, что в протоколе M BUS соответствие передаваемых данных типам измерений и измерительным каналам не регламентировано, что требует индивидуальной настройки считывающего устройства верхнего уровня (наподобие УСПД) под конкретный прибор учета.

Протокол DLMS/COSEM позволяет теоретически добиться построения систем сбора данных, независимых от конкретного производителя и модификации прибора учета. То есть такие системы являются наиболее гибкими и открытыми. Среди зарубежных производителей он является одним из самых распространенных. Недостатком протокола является его существенная сложность.

Применение стандарта PLC является хорошим и недорогим способом для построения систем учета электроэнергии.

Заключение

Таким образом, ни один из существующих протоколов не является единственным кандидатом на роль универсального протокола для всех приборов учета. Что же делать системному интегратору, собирающемуся строить АСКУЭ с централизованным сбором данных?

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

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

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

Если стоит задача мониторинга и учета электроэнергии на оптовом и розничном рынках (например, мониторинг трансформаторных подстанций), то следует обратить особое внимание на решения на основе протоколов ГОСТ Р МЭК 60870-5. Эти протоколы хорошо приспособлены для решения этой задачи. Такой протокол может быть использован при передаче данных от электросчетчиков/УСПД на верхний уровень (SCADA-система, АСКУЭ).

При сборе данных о потребленном электричестве с низового уровня (с электросчетчиков) предпочтителен протокол PLC, когда прокладка кабеля с данными (RS 485, Ethernet) невозможна (порча интерьера помещения) или дорогостояща (большие расстояния).

Материал подготовлен Московским заводом тепловой автоматики (МЗТА)

Протоколы связи являются важной частью ПО автоматизации. В настоящее время даже простые датчики имеют встроенные коммуникационные порты для обмена данными, не говоря уже о ПЛК. В этой связи стоит рассмотреть два старейших, но до сих пор широко используемых протокола связи – Modbus и Profibus. Оба звучат одинаково, но имеют свои особенности. В чем между ними разница? Отвечает на этот вопрос статья на портале InstrumentationTools.

Что такое Modbus?

Modbus – это протокол связи, разработанный компанией Schneider Electric, ранее известной как Modicon. Вот почему он называется Modbus. Modbus передает данные по последовательной линии, в которой используются аппаратные интерфейсы, такие как RS-232, Ethernet и RS-485.

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

Modbus имеет два формата – RTU и ASCII. RTU используется в двоичном формате, тогда как ASCII использует в текстовый формат ASCII. Modbus – это открытый протокол, то есть любой поставщик может использовать его, встроив в соответствующее программное обеспечение.

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

В стандартной сети Modbus может быть максимум 247 подчиненных устройств. Бит отправляется и принимается в виде напряжения. Нулевой бит означает +5 В, а единичный бит означает -5 В. Modbus идентифицируется по таким данным, как адреса регистров катушек, код функции, идентификатор устройства и тип чтения/записи.

Кроме того, одной из основных функций, связанных с данными Modbus, является CRC (cyclic redundancy code – циклический избыточный код). Два байта добавляются в конце каждого сообщения Modbus для обнаружения ошибок.

Что такое Profibus?

Profibus означает Process (Pro) Field (Fi) Bus и был разработан Siemens. Profibus можно назвать расширением протокола Modbus, и он более продвинут. Profibus существует в двух модификациях: Profibus DP (Decentralized Peripherals – децентрализованная периферия) для автоматизации машин и Profibus PA (Process Automation – автоматизация процессов) для автоматизации процессов. В них встроены дополнительные функции в соответствии с требованиями приложения. Это позволяет программистам использовать протоколы в соответствии с их задачами. Но, в отличие от Modbus, который работает на трех разных аппаратных уровнях, этот протокол работает только в RS-485.

Единственное, что отличает Profibus – это режим с несколькими мастерами, в то время как Modbus позволяет использовать только одного мастера. Это возможно за счет дополнительного протокола Token Ring в нем. Каждый мастер проходит последовательность запуска при холодном или теплом старте.

Подчиненные устройства ждут, пока мастер запросит данные, и если они не получат ни одного запроса в течение определенного периода времени, он перейдет в спящий режим. В этом случае мастеру необходимо снова пройти этап запуска и инициировать связь. Это означает, что все ведущие и ведомые устройства доступны в сети для корректной связи. Однако режим с несколькими ведущими устройствами доступен только в системе Profibus PA.

Разница между Modbus и Profibus

1. Modbus – это открытый протокол, тогда как Profibus таковым не является, т.е. никто не может его свободно использовать.

2. Modbus разработан компанией Schneider Electric, а Profibus – компанией Siemens.

3. Двумя вариантами Modbus являются Modbus RTU и Modbus ASCII, тогда как двумя вариантами Profibus являются Profibus DP и Profibus PA.

4. Profibus обеспечивает более скоростную связь, чем Modbus.

5. Modbus может работать на разных аппаратных уровнях, таких как RS-232, RS-485 и Ethernet, тогда как Profibus может работать только на уровне RS-485.

6. У Modbus может быть только один Мастер, тогда как у Profibus может быть несколько Мастеров.

7. С точки зрения программирования Modbus намного проще в использовании, чем Profibus.

8. Profibus более эффективен и надежен для использования в сложных сетях связи, чем Modbus.

9. Profibus имеет больше возможностей для диагностики и устранения неисправностей, чем Modbus.

Сравнение Modbus и Profibus

Материал подготовлен Московским заводом тепловой автоматики