Протокол мэк 104 что это
Протокол мэк 104 что это
ГОСТ Р МЭК 60870-5-104-2004
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
УСТРОЙСТВА И СИСТЕМЫ ТЕЛЕМЕХАНИКИ
Часть 5. Протоколы передачи
Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием
стандартных транспортных профилей
Telecontrol equipment and systems. Part 5. Transmission protocols. Section 104.
Network access for IEC 60870-5-101 using standard transport profiles
Дата введения 2005-07-01
1 РАЗРАБОТАН ОАО «Научно-исследовательский институт электроэнергетики» (ВНИИЭ)
ВНЕСЕН Техническим комитетом по стандартизации ТК 396 «Автоматика и телемеханика»
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 9 марта 2004 г. N 89-ст
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта МЭК 60870-5-104:2000 «Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для МЭК 870-5-101 с использованием стандартных транспортных профилей»
1 Область применения
Настоящий стандарт из серии ГОСТ Р МЭК 870-5 распространяется на устройства и системы телемеханики с передачей данных последовательными двоичными кодами для контроля и управления территориально распределенными процессами. Раздел 104 является обобщающим стандартом, который дает возможность взаимодействия различной совместимой аппаратуры телемеханики.
Настоящий обобщающий стандарт рассматривает стандарты ГОСТ Р МЭК 870-5-1 ГОСТ Р МЭК 870-5-5. Правила настоящего стандарта представляют комбинацию прикладного уровня ГОСТ Р МЭК 870-5-101 и функций транспортного уровня, предусматриваемых TCP/IP (Протокол управления передачей/Протокол Интернета). Внутри TCP/IP могут быть использованы различные типы сетей, включая Х.25 [1], FR (Фрейм реле), ATM (Режим Асинхронной Передачи) и ISDN (Цифровая сеть интегрированного обслуживания). При использовании тех же определений альтернативные ASDU, как показано в других обобщающих стандартах серии ГОСТ Р МЭК 870-5 (например, ГОСТ Р МЭК 870-5-102), могут комбинироваться с TCP/IP, но настоящий стандарт этого не рассматривает.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
Становление стандартов передачи телемеханических данных в электроэнергетике (МЭК 101/104) — особенности разработки
Здравствуйте! Меня зовут Юрий.
Преамбула
Проработав несколько лет в энергетической отрасли в теме организации передачи данных, хочу поделиться с сообществом полученными знаниями, в том числе тем, «как это было».
Сразу оговорюсь, что в тексте будут даны названия компаний и продуктов, которые на рынке уже давно, так что рассматривать это как рекламу я бы не стал. Также хочу отметить, что все сроки, связанные с «неразглашением конфиденциальной информации» давно уже прошли, что позволяет мне делиться полученной в процессе работы информацией. Какие-то конкретные фамилии «ответственных за» называться не будут, т.к. все они в той или иной степени развивали это направление.
Ссылки в статье даны для тех, кто желает погрузиться в тему немного глубже.
Как все начиналось
Немного о 603-ем приказе
Полное название документа: О приведении систем телемеханики и связи на генерирующих предприятиях электроэнергетики, входящих в состав холдинга ОАО РАО «ЕЭС России», в соответствие с требованиями балансирующего рынка, Приказ № 603 от 09.09.2005 ОАО РАО «ЕЭС России».
Спорные моменты протокола МЭК
Есть несколько нюансов, которые никак нельзя трактовать однозначно.
Метка времени в формате UTC
В зарубежной реализации протокола сказано, что рекомендуется использовать метку времени в формате UTC. Парадоксально, но для Российской редакции этого документа для нашей много-часовопоясной страны эта сточка отсутствует, хотя она могла бы решить огромное количество проблем, связанных с передачей данных из одного часового пояса в другой!
Отсутствие часовых поясов
В 7-ми байтной метке времени есть большое количество свободного пространства, которое позволяет задать текущий часовой пояс, если уж возникла такая необходимость.
Возможность расширения
Как показала практика применения данного протокола, из всего набора определенных в нем типов кадров реально применяется процентов 20, максимум. Но в самом начале его использования отечественные разработчики постарались использовать кадры, зарезервированные под дальнейшее расширение. Это к вопросу о процессе «развития» протокола.
Немного о продуктах того периода и их возможностях
В связи с тем, что энергетика — это достаточно денежная отрасль, к «кормушке» старались попасть большое количество фирм со своими продуктами или услугами. Соответственно, по распространенности того или иного продукта можно судить насколько близко договорились между собой представители власти и представители того или иного бизнеса.
К счастью, в случае если эти договоренности так или иначе сопровождал какой-то продукт на первом этапе не самого лучшего качества, постепенно он доводился до ума, модернизировался и сейчас уже можно сказать является надежным и не заменимым. Но про сложности этапа внедрения, связанные с «сыростью» и не согласованностью решений между различными участниками все-таки помнить следует.
О косяках особенностях в реализации
Прим.: В связи с тем, что на тот момент моя работа в компании была непосредственно связана с тестированием оборудования тех или иных производителей для выдачи разрешительных документов на внедрение этих систем на объектах сдаваемых ОАО «СО ЕЭС», разработчиков я видел достаточно много, с некоторыми из которых я до сих пор поддерживаю хорошие отношения.
Основные особенности в реализации протоколов были связаны с непониманием процедурной части реализации протоколов. Т.к. МЭК раздел 870-5 регламентирует только форматы передаваемых данных, часть производителей подразумевала, что можно тупо эти данные слать, не выполняя никаких процедур, связанных с установкой соединения на канальном уровне. За процедурную часть отвечал раздел МЭК 870-6, на который почему-то никто из «законодателей» не обращал внимания. Тем не менее, имея в запасе прекрасно сформулированное Норвежское соглашение, со всеми его диаграммами и вычеркнутыми частями, всем производителям удалось придти к какому-то единому пониманию того, как должен строится обмен.
Насколько я знаю, сейчас процедура проверки совместимости протоколов уже не проводится, т.к. все, кто был на этом рынке уже свои реализации протоколов МЭК за эти годы успели отладить, а те, кто не успел — просто покинули рынок (есть и такие компании).
ГОСТ Р МЭК 60870-5-104-2004
Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей
Купить ГОСТ Р МЭК 60870-5-104-2004 — бумажный документ с голограммой и синими печатями. подробнее
Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО «ЦНТИ Нормоконтроль»
Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.
Способы доставки
Из серии ГОСТ Р МЭК 870-5 распространяется на устройства и системы телемеханики с передачей данных последовательными двоичными кодами для контура и управления территориально распределенными процессами. Раздел 104 является обобщающим стандартом, который дает возможность взаимодействия различной совеместимой аппаратуры телемеханики.
Оглавление
1 Область применения
2 Нормативные ссылки
3 Общая архитектура
4 Структура протокола
5 Определение Управляющей Информации Прикладного Протокола (APCI)
5.1 Защита от потерь и дублирования сообщений
5.2 Процедуры испытаний (тестирования)
5.3 Управление передачей с использованием Старт/Стоп
5.5 Максимальное число APDU формата I, ожидающих квитирования (k)
6 Выбор ASDU, определенных ГОСТ Р МЭК 870-5-101, и дополнительных ASDU
7 Сопоставление (установление соответствия) выбранных блоков пользовательских данных и функций с услугами ТСР
7.1 Инициализация станции (см. пункты 6.1.5-6.1.7 ГОСТ Р МЭК 870-5-5)
7.2 Сбор данных при помощи опроса (см. пункт 6.2 ГОСТ Р МЭК 870-5-5)
7.3 Циклическая передача данных (см. пункт 6.3 ГОСТ Р МЭК 870-5-5)
7.4 Сбор данных о событиях (см. пункт 6.4 ГОСТ Р МЭК 870-5-5)
7.5 Общий опрос (см. пункт 6.6 ГОСТ Р МЭК 870-5-5)
7.6 Синхроизация времени (см. пункт 6.7 ГОСТ Р МЭК 870-5-5)
7.7 Передача команд (см. пункт 6.8 ГОСТ Р МЭК 870-5-5)
7.8 Передача интегральных сумм (телесчет) (см. пункт 6.9 ГОСТ Р МЭК 870-5-5)
7.9 Загрузка параметра (см. пункт 6.10 ГОСТ Р МЭК 870-5-5)
7.10 Тестовая процедура (см. пункт 6.11 ГОСТ Р МЭК 870-5-5)
7.11 Пересылка файлов (см. пункт 6.12 ГОСТ Р МЭК 870-5-5). Направление управления и контроля
8 ASDU с меткой времени для информации о процессе в направлении управления
8.1 ИДЕНТИФИКАТОР ТИПА 58: C_SC_TA_I Однопозиционная команда с меткой времени CP56Время2а
8.2 ИДЕНТИФИКАТОР ТИПА 59: C_DC_TA_I Двухпозиционная команда с меткой времени CP56Время2а
8.3 ИДЕНТИФИКАТОР ТИПА 60: C_RC_TA_I Команда пошагового регулирования с меткой времени CP56Время2а
8.4 ИДЕНТИФИКАТОР ТИПА 61: C_SЕ_TA_I Команда уставки с меткой времени CP56Время2а, нормализованное значение
8.5 ИДЕНТИФИКАТОР ТИПА 62: C_SЕ_TB_I Команда уставки с меткой времени CP56Время2а, масшабированное значение
8.6 ИДЕНТИФИКАТОР ТИПА 63: C_SE_TC_I Команда уставки с меткой времени CP56Время2а, короткий формат с плавающей запятой
8.7 ИДЕНТИФИКАТОР ТИПА 64: C_BO_TA_I Строка из 32 битов с меткой времени CP56Время2а
8.8 ИДЕНТИФИКАТОР ТИПА 107: C_TS_TA_I Тестовая команда с меткой времени CP56Время2а
9 Возможность взаимодействия (совместимость)
9.1 Система или устройство
9.2 Конфигурация сети
9.3 Физический уровень
9.4 Канальный уровень
9.5 Прикладной уровень
9.6 Основные прикладные функции
Приложение А Библиография
| Дата введения | 01.07.2005 |
|---|---|
| Добавлен в базу | 01.09.2013 |
| Актуализация | 01.02.2020 |
Этот ГОСТ находится в:
Организации:
Telecontrol equipment and systems. Part 5. Transmission protocols. Section 104. Network access for IEC 60870-5-101 using standard transport profiles
Чтобы бесплатно скачать этот документ в формате PDF, поддержите наш сайт и нажмите кнопку:
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
УСТРОЙСТВА И СИСТЕМЫ ТЕЛЕМЕХАНИКИ
Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей
ГОССТАНДАРТ РОССИИ Москва
1 РАЗРАБОТАН ОАО «Научно-исследовательский институт электроэнергетики» (ВНИИЭ) ВНЕСЕН Техническим комитетом по стандартизации ТК 396 «Автоматика и телемеханика»
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 9 марта 2004 г. № 89-ст
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта МЭК 60870-5-104:2000 «Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для МЭК 870-5-101 с использованием стандартных транспортных профилей»
© ИПК Издательство стандартов, 2004
Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Госстандарта России
Внутренние счетчики V после посылки или приема APDU
Внутренние счетчики V после посылки или приема APDU
Далее следует активное открытие (см. рисунки 17-20)
Рисунок 12 — Тайм-аут в случае неподтверждения последнего APDU формата 1
5.2 Процедуры испытаний (тестирования)
Неиспользованные, но открытые соединения могут периодически проверяться в обоих направлениях путем посылки тестового APDU (TESTFR = act), который подтверждается приемной станцией с помощью APDU TESTFR = con (см. рисунки 13 и 14). Обе станции могут начинать процедуру проверки после определенного периода времени, в течение которого не появляются посылки данных (тайм-аут). Получение каждого кадра — кадра 1, кадра S или кадра U — перезапускает таймер t3. Станция В контролирует соединение независимо. Однако до тех пор, пока она получает тестовые кадры от станции А, она не должна посылать тестовые кадры.
Процедура проверки может также инициироваться на «активных» соединениях, когда отсутствие активности возможно длительное время и наличие соединения необходимо подтверждать.
ГОСТ Р МЭК 60870-5-104-2004
5.3 Управление передачей с использованием Старт/Стоп
Функции STARTDT (Старт Передачи Данных) и STOPDT (Прекращение Передачи Данных) используются контролирующей станцией (например, Станция А) для управления пересылкой данных с контролируемой станции (например, Станция В). Это полезно, например, когда между станциями открыто, то есть доступно, более одного соединения, но только одно соединение в это время используется для пересылки данных. Определяемые здесь функции STARTDT и STOPDT (см. рисунки 15 и 16) позволяют избежать потери данных в случае переключения с одного соединения на другое. Функции STARTDT и STOPDT также используются с одиночным соединением между станциями для управления трафиком на соединении.
Когда соединение установлено, пересылка данных пользователя не разрешается автоматически от контролируемой станции по этому соединению, то есть STOPDT — это состояние по умолчанию, когда соединение установлено. В таком состоянии контролируемая станция не посылает никаких данных по этому соединению, кроме ненумерованных функций управления и подтверждения этих функций. Контролирующая станция должна активировать пересылку данных пользователя по соединению путем посылки STARTDT act по этому соединению. Контролируемая станция отвечает на эту команду STARTDT con. Если STARTDT не подтверждается, соединение закрывается контролирующей станцией. Это означает, что после инициализации станции (см. 7.1) STARTDT должен всегда посылаться до того, как инициируется какая-нибудь передача данных пользователя с контролируемой станции (например, информация общего опроса). Любые данные пользователя на контролируемой станции, готовые к передаче, посылаются только после STARTDT con.
Функция STARTDT/STOPDT являются механизмом для контролирующей станции, чтобы активировать/деактивировать направление контроля. Контролирующая станция может посылать команды или уставки, даже если она еще не получила подтверждения активации. Счетчики передачи и приема продолжают свою работу независимо от использования STARTDT/STOPDT.
В случае переключения с активного соединения на другое соединение (например, оператором) контролирующая станция сначала передает STOPDT act на активное соединение. Контролируемая станция прекращает пересылку данных пользователя по этому соединению и посылает обратно STOPDT con. Задержанные квитанции о приеме данных пользователя могут посылаться от момента времени, когда контролируемая станция получит STOPDT act, до момента времени, когда она возвратит STOPDT con. После получения STOPDT con контролирующая станция может закрыть соединение. Для того, чтобы начать пересылку данных от контролируемой станции по другому установленному соединению, требуется команда STARTDT на этом соединении.
Процедура начала пересылки данных
ГОСТ Р МЭК 60870-5-104-2004
5.4 Номер порта
Каждый адрес TCP состоит из адреса IP и номера порта. Каждое устройство, присоединяемое к TCP-LAN, имеет свой собственный адрес IP, в то время как номер порта определяется для всей системы (см. RFC 1700). Для настоящего стандарта номер порта определен как 2404 и утвержден IANA (Internet Assigned Numbers Authority — Организация по назначению номеров Интернет).
5.5 Максимальное число APDU формата I, ожидающих квитирования (к)
Значение к показывает максимальное число последовательно пронумерованных APDU формата I, которые ООД в данный момент может передать, не получая подтверждения. Каждый кадр формата I последовательно пронумерован «по модулю п», то есть может иметь номера от 0 до n—1, где «модуль» — есть модуль порядковых номеров, который определяется параметром п. Значение к не может никогда превысить n—1 для операции по модулю п (см. пункты 2.3.2.2.1 и 2.4.8.6 рекомендации МСЭ-ТХ.25 [11).
— Передатчик прекращает передачу при достижении числа к неподтвержденных APDU формата I.
— Приемник передает подтверждение по крайней мере после получения w APDU формата I*.
Максимальный диапазон значений к: от 1 до 32767** APDU, точность до одного APDU.
Максимальный диапазон значений w: от 1 до 32767 APDU, точность до одного APDU (рекомендация: значение w не должно превышать двух третей значения к).
6 Выбор ASDU, определенных ГОСТ Р МЭК 870-5-101, и дополнительных ASDU
Действительны ASDU, определенные ГОСТ Р МЭК 870-5-101, которые приведены в таблицах 1—6, и дополнительные, приведенные в пункте 8 настоящего стандарта:
Таблица 1 — Информация о процессе в направлении контроля ИДЕНТИФИКАТОР ТИПА :=Ш8[1..8]
Протокол мэк 104 что это
ГОСТ Р МЭК 60870-5-103-2005
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Устройства и системы телемеханики
Обобщающий стандарт по информационному
интерфейсу для аппаратуры релейной защиты
Telecontrol equipment and systems. Part 5. Transmission protocols. Section 103.
Companion standard for the informative interface of protection equipment
Дата введения 2006-09-01
Сведения о стандарте:
1 ПОДГОТОВЛЕН ОАО «Научно-исследовательский институт электроэнергетики» (ВНИИЭ) на основе собственного аутентичного перевода стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 396 «Автоматика и телемеханика»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении В
1 Область применения
Настоящий обобщающий стандарт распространяется на аппаратуру релейной защиты с последовательной передачей данных двоичными кодами для обмена информацией с системами управления. Настоящий стандарт определяет взаимодействие между аппаратурой релейной защиты и устройствами системы управления на подстанции. Настоящий стандарт использует серию стандартов МЭК 870-5.
Настоящий стандарт устанавливает определения информационного интерфейса для аппаратуры релейной защиты. Для устройств, совмещающих функции релейной защиты и функции управления в одном устройстве и использующих общий порт связи, требования настоящего стандарта допускается не применять.
Использование заранее определенных сообщений и прикладных процедур обязательно, если они применимы. В других случаях должны использоваться групповые услуги. Частные диапазоны, определяемые в настоящем стандарте, сохраняются для совместимости, однако их использование для будущих применений не рекомендуется.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ИСО/МЭК 7498-1:1994 Информационные технологии. Взаимосвязь открытых систем. Базовая эталонная модель. Базовая модель
EIA RS-485:1993 Стандарт на электрические характеристики генераторов и приемников для использования в балансных цифровых многоточечных системах
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 обобщающий стандарт (companion standard): Обобщающий стандарт добавляет семантику к определениям базового стандарта или функционального профиля. Это может выражаться в определении конкретного использования информационных объектов или в определении дополнительных информационных объектов, сервисных процедур и параметров базовых стандартов.
3.3 направление управления (control direction): Направление передачи от системы управления к устройству защиты.
3.4 направление контроля (monitor direction): Направление передачи от устройства защиты к системе управления.
3.5 система управления (control system): Применяется как мастер для канала связи, т.е. первичная станция в соответствии с МЭК 60870-5-2.
3.6 информационный интерфейс (informative interface): Интерфейс устройства защиты, используемый для обмена данными с системой управления и не оказывающий влияния на функции защиты.
3.7 метка (tag): Двоичный сигнал, регистрируемый и передаваемый в составе передачи данных о нарушениях.
3.8 совместимый диапазон (compatible range): Стандартный диапазон, который должен использоваться всеми производителями.
3.9 частный диапазон (private range): Диапазон, который может использоваться производителями для своих частных применений.
3.10 Сокращения и обозначения
— дифференциальная защита линии;
— дифференциальная защита трансформатора;
— текущий канал (Actual channel);
— блок данных прикладного уровня (Application Service Data Unit);
— управляющая информация протокола прикладного уровня (Application Protocol Control Information);
— оптоволоконный коаксиальный разъем;
— строка битов (Bitstring);
— уровень совместимости (Compatibility level);
— причина передачи (Cause of transmission);
— однобитный счетчик ASDU;
— устройство связи (Communication unit);
— аппаратура окончания канала данных АКД (Data circuit-terminating equipment);
— управление потоком данных;
— оконечное оборудование данных ООД;
— ассоциация электронной промышленности;
— архитектура повышенной производительности;
Как я писал библиотеку под МЭК 870-5-104 на Arduino при помощи Wireshark
В этой статье я хотел бы рассказать о своем знакомстве с протоком передачи данных МЭК 870-5-104 со стороны контролируемого (slave) устройства путем написания простой библиотеки на Arduino.
Что такое МЭК 870-5-104 это и где применяется?
МЭК 60870-5-104 – протокол телемеханики, предназначенный для передачи сигналов ТМ в АСТУ, регламентирующий использование сетевого доступа по протоколу TCP/IP. Чаще всего применяется в энергетике для информационного обмена между энергосистемами, а также для получения данных от измерительных преобразователей (вольтметры, счетчики электроэнергии и прочее).
Стэк протокола МЭК 670-5-104:
Используемые материалы
Краткое описание этапов работы
Подготовка
Термины и сокращения
APCI — Управляющая Информация Прикладного Уровня может применяться как самостоятельный управляющий кадр (кадр U или кадр S).
ASDU — Блоки данных прикладного уровня, состоит из идентификатора блока данных и одного или более объектов информации, каждый из которых включает в себя один или более однородных элементов информации (либо комбинаций элементов информации).
APDU — Протокольный блок данных прикладного уровня.
ТС — телесигнализация.
ТИ — телеизмерения.
ТУ — телеуправление.
1. Установка TCP/IP соединение порт 2404
Контролирующая (master) станция инициализирует установку TCP соединения путем посылки TCP пакета с флагом (SYS). Соединение считается установленным, если в течение контрольного времени (t0) контролируемая станция (slave) выдала на свой уровень TCP/IP подтверждение «активного открытия» (SYS ACK). Контрольное время t0 называется «Тайм-аут установки соединения». Таймер t0 определяет, когда открытие отменяется и не определяет начало новой попытки соединения.
Взаимодействие с транспортным уровнем выполняет стандартная библиотека для плат Arduino «Ethernet.h». То есть первым делом необходимо установить TCP/IP соединение между контролируемой и контролирующей станциями. Для этого необходимо в скетче Arduino инициализировать устройство и создать сервер который будет ожидать входящие соединения через указанный порт.
Если загрузить этот скетч то будет происходить следующее:
Установка соединения, далее приходит пока неизвестный для Arduino пакет STARTDT act и по истечении определенного времени рвется соединение. Далее необходимо разобраться что такое STARTDT act.
2. Подтверждение запроса на передачу данных (STARTDT act/con)
В МЭК 670-5-104 существует 3 типа формата для передачи:
Таким образом далее необходимо считать байты полученные от контролирующей (master) станции и разобрать их.
Прочитав данные необходимо разобрать их и сформировать ответ.
Вот как выглядит посылка содержащая блок STARTDT в программе Wireshark, APDU блок U-формата, который состоит только из APCI.
APCI—Управляющая Информация Прикладного Уровня может применяться как самостоятельный управляющий кадр (кадр U или кадр S).
Вкратце можно сказать, что блок APCI определяет тип блока APDU и его длину. APCI состоит из следующих шести байтов:
1. Признак инициализации блока APDU переменной длины, начинающийся байтом START2 68h;
2. Длин APDU, в данном примере равна четырем байтам;
3. Байт управления в котором определяется тип APDU, в данном примере записано значение равное семи, что означает запрос на передачу данных;
4,5,6 Не используются.
Исходя из вышеописанного, перед тем как ответить, не мешало бы определить какой тип APDU нам послала контролирующая станция. Зная, что тип APDU записан третьим по порядку чтения блока APCI байтом, сохраню его в целочисленную переменную.
Примечание: Если будет получен пакет формата «I» то 3 байт в APCI будет также содержать значение младшего слова счетчика принятых пакетов, 
поэтому пришлось немного усложнить конструкцию определения типа APDU.
Из рисунка выше видно, что тип APDU соответствующий значению 7 это STARTDT act соответственно ответить необходимо таким же по структуре пакетом только значение типа должно иметь значение 11 (0b), что соответствует STARTDT con.
После обновления скетча наблюдаем следующий порядок обмена:
Установку соединения, запрос на передачу данных, подтверждение запроса и еще один новый пока неизвестный APDU формата I типа 1 C_IC_NA Act.
3. Запрос на общий опрос станции
APDU C_IC_NA_1 кроме блока APCI так же имеет блок ASDU (блок данных прикладного уровня), которые вместе формируют Протокольный Блок Данных Прикладного Уровня APDU.
Рассмотрим более подробно полученный APDU.
После обновления скетча наблюдаем следующий порядок обмена: 
Установку соединения, запрос на передачу данных, подтверждение, запрос на общий опрос станции от контролирующей станции, завершение инициализации, запрос на общий опрос станции в направление контролируемой станции, подтверждение общего опроса, пересылка значений всех доступных сигналов на контролирующей станции, завершение общего опроса и неизвестный APCI формата S.
Запрос опроса станции выдается в направлении контролируемой станции:
— если с контролируемой станции получен «КОНЕЦ ИНИЦИАЛИЗАЦИИ» или
— если центральная станция обнаруживает потерю канала (безуспешное повторение запроса канального уровня) и последующее восстановление его.
4. Подготовка и передача данных
APDU блок формата S, состоящий только из APCI предназначен для подтверждения принятого APDU I формата. Для S-формата 7 старших бит служебного поля байта 1 и байт 2 не задействованы, а байт 3 (7 старших бит) и байт 4 определяют текущий номер принятой посылки.
В данном случае блок S указывает на то, что контролирующая (master) станция готова к приему данных в течении определенного времени, не превышающего, тайм-аут t3 определенного на стороне контролирующей (master) станции. То есть контролирующая (master) станция говорит нам «я готова к приему данных!». Далее необходимо позаботиться о том какие данные передавать и откуда их брать.
Что можно передавать? Существует несколько видов информации определённых в МЭК 870-5- 104:
В данном примере рассматривается передача контрольной информации на примере 1, 11 и 13 функций (одноэлементная, измерение масштабируемое, измерение короткий формат с плавающей запятой). Данные формируются рандомно. Также необходимо учитывать, что у каждого передаваемого сигнала имеется байт качества.
Простой алгоритм определения качества сигнала:
Так же необходимо учесть, что для каждого сигнала имеется уникальный идентификатор IOA, в энергетике принято распределять эти адреса следующим образом:
И так получив APDU подтверждение S или I формата от контролирующей станции можно начать передавать имеющиеся в распоряжении данные, не забывая увеличивать номер передаваемого кадра. 
Загрузив скетч в Wireshark наблюдаем, что наконец-то началась передача данных. 
Далее привожу описание структуры ASDU M_SP_NA_1 одноэлементная индикация.
TypeId — вид информации.
SQ — классификатора переменной структуры.
Предусматриваются две структуры блоков данных:
1. Блок, содержащий i объектов информации, каждый из которых содержит по одному элементу информации (или по одной комбинации элементов); старший бит классификатора переменной структуры SQ (single/sequence) равен 0, остальные 7 битов задают число i.
2. Блок, содержащий один объект информации, который содержит j элементов либо одинаковых комбинаций элементов информации; старший бит (27 = 80h) классификатора SQ равен 1, остальные 7 битов задают число j.
CauseTx — причина передачи.
Addr — адрес слэйва (указывается при конфигурировании мастера).
IOA — адрес объекта информации, по этому адресу контролирующая станция будет привязывать свой тэг
SIQ — показатель качества передаваемого сигнала.
Структура ASDU блока функции M_ME_NB_1:
В ответ на полученные данные master будет отправлять блоки формата S и процесс зациклится до тех пор пока контролируемое(slave) устройство не перестанет передавать кадры.
5. Процедуры тестирования
Процедуры тестирования применяются с целью контроля за работоспособностью транспортных соединений. Процедура выполняется независимо от «активности» IP-соединения, если в течение контрольного времени t3 не было принято ни одного кадра (I, U, S). Время t3 является предметом согласования и называется «Тайм-аут для посылки блоков тестирования в случае долгого простоя». Процедура тестирования реализуется путем посылки тестового APDU (TESTFR =act), которое подтверждается принимаемой станцией с помощью APDU (TESTFR =con).
Если от контролирующей (master) станции придет APDU у которого в байте отвечающего за тип APDU значение равно шестидесяти сети (TESTFR) это говорит о том, что в течении времени t3 от контролируемой станции не было принято ни одного кадра (I, U, S), и если в течении времени t1 не ответить подтверждением то соединение будет разорвано.