МЭК 104: таймаут ожидания следующего байта

Раздел:  --== Все разделы ==-- ------------------------------------------------------------- СДТУ - Общий раздел Телемеханика в электроэнергетике Оперативно-информационные комплексы Измерительные преобразователи Модемы и протоколы ТМ Каналы связи в электроэнергетике Высокочастотная связь по ЛЭП Цифровые системы связи и передачи данных О сайте и форуме Объявления Телемеханика и связь в энергетике / Модемы и протоколы ТМ / МЭК 104: таймаут ожидания следующего байта

Страницы: 1

Автор	Сообщение
kvser Группа: Участники Сообщений: 8	Добавлено: 07-05-2009 14:30
	Изучил 870-5-104. Начал реализовывать(режим сервер), возникли вопросы: 1) Принимаю данные. Дак вот, если я получил половину APDU, то следующую половину запроса сколько времени ждать? 2) APDU начинается с 0x68. А что делать при встречи какого-то мусора между двумя APDU. Просто игнорировать с записью в лог, о посторонних не соответствующих протоколу данных? Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 07-05-2009 14:52
	еще добавлю: если ждать данные, то может произойти таймаут, к примеру, T3 - таймаут для посылки блоков тестирования. И при полудуплексном канале, что я должен сделать, прекратить получение и послать блоки тестирования, или все-таки дождаться получения. Вообщем лучше конечно найти какое-то "полное" описание протокола, а не ГОСТ, который не оговаривает поведение в некоторых ситуациях. Цитировать
kuzulis частый гость Группа: Участники Сообщений: 34	Добавлено: 07-05-2009 16:41
	Мне тож интересно, я тож "изучаю" :) а Вы смотрели : ---- УСТРОЙСТВА И СИСТЕМЫ ТЕЛЕМЕХАНИКИ Часть 5. Протоколы передачи Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей ---- п 5.1 Защита от потери и дублирования сообщений Использование передаваемого порядкового номера N(S) и принимаемого порядкового номера N(R) идентично методу, определенному в рекомендации МСЭ-Т Х.25. [5]. Для наглядности дополнительные последовательности определены на рисунках 9 - 12. Оба порядковых номера увеличиваются на единицу для каждого APDU и каждого направления. Передатчик увеличивает передаваемый порядковый номер N(S), а приемник увеличивает принимаемый порядковый номер N(R). Приемная станция подтверждает каждый APDU или несколько APDU , когда она возвращает очередной принимаемый порядковый номер, вплоть до которого все APDU были приняты правильно . Передающая станция хранит APDU в буфере до тех пор, пока не получит обратно собственный передаваемый порядковый номер в качестве принимаемого порядкового номера, который является подтверждением для всех номеров до полученного номера включительно. Затем правильно переданные APDU в буфере могут быть стерты. В случае длительной передачи данных только в одном направлении формат S посылается в другом направлении, чтобы подтвердить APDU до того, как буфер переполнится или до тайм-аута . Этот метод должен использоваться в обоих аправлениях. После установления соединения TCP передаваемые и принимаемые порядковые номера устанавливаются в ноль. ------------------------- 1) Принимаю данные. Дак вот, если я получил половину APDU, то следующую половину запроса сколько времени ждать? тут хитро как то ГОСТ все оговаривает и непонятно: 1. т.е написано что приемная станция может подтверждать каждый APDU, а может несколько APDU... так вот вопрос, в каких случаях она это делает? т.е откуда она "знает" что сейчас нужно подтвердить только 1 APDU, а в следующий раз например 6 APDU? 2. нигде не указана величина таймаута... я думаю, что ее нужно настраивать в приемной станции выборочно, в зависимости от настроек таймаута передачи передающей станции! 3. Если принимаете половину APDU, то нужно забраковать его и послать передающей станции запрос, чтобы она повторила посылку снова... я так думаю APDU начинается с 0x68. А что делать при встречи какого-то мусора между двумя APDU. Просто игнорировать с записью в лог, о посторонних не соответствующих протоколу данных? ну дык алгоритм простой: 1. При входящем соединении от передающей станции создаем сокет и обнуляем все счетчики и т.д. и т.п. 2. Ожидаем в сокете прихода данных от передающей станции в течении таймаута №1. Если время вышло, то делаем дисконнект 3. При приходе данных в сокет - читаем один байт и если он 68H, то читаем второй байт (где указана длина N остальных ожидаемых байт ) 4. Читаем потом 4 байта с содержимым счетчиков и если все нормуль, то читаем до конца N-4 байта (или читаем сразу N байт, а потом уже анализируем эти N байт по 4-м первым) ... ... 9. Если приняли "битое" APDU, то отправляем запрос на повтор передачи и ждем в течении таймаута №2 10. Если время истекло - рвем соединение ... ... 15. Если приняли APDU успешно, то шлем передающей станции подтверждение. ... ... 26. См п 2 Это я так примерно думаю как должно быть ЗЫ: тоже патаюсь разобраться в протоколе :) , так что это все мое ИМХО без пол-литра не разобраться, хотя там все в документе расписано насчет того, как должна проходить процедура инициализации и обмена даныыми и т.п.. Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 08-05-2009 08:19
	а Вы смотрели : ---- УСТРОЙСТВА И СИСТЕМЫ ТЕЛЕМЕХАНИКИ Часть 5. Протоколы передачи Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей конечно 1. т.е написано что приемная станция может подтверждать каждый APDU, а может несколько APDU... так вот вопрос, в каких случаях она это делает? т.е откуда она "знает" что сейчас нужно подтвердить только 1 APDU, а в следующий раз например 6 APDU? станция же знает сколько апду она получила (счетчик соответствующий), значение этого счетчика и посылается Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 08-05-2009 08:28
	3. Если принимаете половину APDU, то нужно забраковать его Вы хотите сказать, что мне должен придти весь пакет сразу? Т.е. он не может придти по частям? Например, в текущий момент времени я могу прочитать из сокета, только 3 байта, потому как остальные еще не доступны. Через некоторое время и остальные придут, если все хорошо сложится и послать передающей станции запрос, чтобы она повторила посылку снова... я так думаю Что это за запрос о повторе посылке? Какой идентификатор типа? Цитировать
kuzulis частый гость Группа: Участники Сообщений: 34	Добавлено: 08-05-2009 09:09
	Вы хотите сказать, что мне должен придти весь пакет сразу? Т.е. он не может придти по частям? Ну да, т.к передающая станция готовит пакет у себя ,т.е. составляет его, а потом передает целиком... Ведь это всего максимум 255 байт, о каких частях речь вообще??!! :) это ж не килобайты и не мегабайты.. И то, в случае оч оч оч длинного пакета, в ф-ю Send (или какая там ..) передается длина всего пакета обычно... А уже сам драйвер и сетевуха на более низком уровне уже заботится о том чтобы доставить весь пакет получателю.. Например, в текущий момент времени я могу прочитать из сокета, только 3 байта, потому как остальные еще не доступны. Через некоторое время и остальные придут, если все хорошо сложится дык чтение из сокета - это ж асинхронная операция... если говорить про WinSock, то там есть вызов Select, и т.п. т.е например если пришло в приемный буфер сокета принимающей станции к текущему моменту например 10 байт, то мы : 1. Читаем первый байт, и если он = 68H , то читаем второй... Иначе если не равен 68H, то не имеет смысла вообще читать пакет, т.к. там будет мусор - и мы выполняем транзакцию (см. доку по протоколу) для закрытия TCP соединения. 2. Прочитав второй байт, мы узнаем сколько ожидается длина остального пакета данных, и читаем из приемного буфера сокета остальные байты... Тут наверное по тайм-ауту нужно читать, и если за отведенное время остальные данные пакета не пришли, то рвать соединение.. Что это за запрос о повторе посылке? Какой идентификатор типа? эммм... ну наверное в ASDU должен быть при PRM=0 функциональный код = 1 , что означает отрицательная квитанция (см. УНИФИЦИРОВАННЫЕ ПРОТОКОЛЫ ИНФОРМАЦИОННОГО ОБМЕНА Общие Технические Требования СО 34.48.160-2004) ЗЫ: наверное как то так, хотя я сам не разобрался в протоколе , нужна реальная "железяка" с поддержкой МЭК 104, чтобы на ней все оттестировать, или ходябы ПО, которое симулировало работу таких девайсов. Попробуйте найти такое ПО и скачать, а потом отпишитесь тут на форуме и ссылочку на такое бесплатное ПО дайте :) Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 08-05-2009 09:44
	2. Прочитав второй байт, мы узнаем сколько ожидается длина остального пакета данных, и читаем из приемного буфера сокета остальные байты... Тут наверное по тайм-ауту нужно читать, и если за отведенное время остальные данные пакета не пришли, то рвать соединение.. правильно, по таймауту. А каким должен быть таймаут (мк, сек, час, день)? В протоколе это не описано Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 08-05-2009 09:48
	1)Симуляция iec104 (мастер слайв) 2)есть конвертер из opc В iec104, называется "opc104" от prosoft Цитировать
Andrew аксакал Группа: Участники Сообщений: 568	Добавлено: 08-05-2009 10:30
	Демоверсии... Написано, что всего посылают/принимают 20 телеграмм, а потом что? Не работают? Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 08-05-2009 11:10
	Демоверсии... ...а потом что? Не работают? потом перезапускаешь и опять работает Цитировать
kuzulis частый гость Группа: Участники Сообщений: 34	Добавлено: 08-05-2009 11:32
	вот: ----- t0 30 с Тайм-аут при установлении соединения t1 15 с Тайм-аут при посылке или тестировании APDU t2 10 с Тайм-аут для подтверждения в случае отсутствия сообщения с данными t2<t1 t3 20 с Тайм-аут для посылки блоков тестирования в случае долгого простоя ---- Я так думаю что нужно брать t1 для станции контролирующей (если контролирующая станция посылает APDU контролируемой, а потом в течении t1 ждет ответа/подтверждения от контролируемой) а t2 - это таймаут с которым контролируемая станция ожидает данных от контролирующей.. Я так думаю ... Цитировать
kvser Группа: Участники Сообщений: 8	Добавлено: 08-05-2009 12:39
	а t2 - это таймаут с которым контролируемая станция ожидает данных от контролирующей.. Я так думаю ... Нет, это время ожидания подтверждения, а не данных. Потому как slave ожидает данные даже в том случае, если он сам ничего не послал эээ, что-то я не то написал совсем t2- если нет данных, которые можно послать в ответ, то через это время необходимо послать сообщение формата S Цитировать

Страницы: 1

Раздел:  --== Все разделы ==-- ------------------------------------------------------------- СДТУ - Общий раздел Телемеханика в электроэнергетике Оперативно-информационные комплексы Измерительные преобразователи Модемы и протоколы ТМ Каналы связи в электроэнергетике Высокочастотная связь по ЛЭП Цифровые системы связи и передачи данных О сайте и форуме Объявления Телемеханика и связь в энергетике / Модемы и протоколы ТМ / МЭК 104: таймаут ожидания следующего байта