Страниц: [1] 2
  Печать  
Автор Тема: МЭК 104: таймаут ожидания следующего байта  (Прочитано 25886 раз)
juvf
Участник
*
Offline Offline

Сообщений: 22


Просмотр профиля
« : Мая 12, 2009, 12:53:43 pm »

Изучил 870-5-104. Начал реализовывать(режим сервер), возникли вопросы:
1) Принимаю данные. Дак вот, если я получил половину APDU, то следующую половину запроса сколько времени ждать?
2) APDU начинается с 0x68. А что делать при встречи какого-то мусора между двумя APDU. Просто игнорировать с записью в лог, о посторонних не соответствующих протоколу данных?
Записан
mgb14
Участник
*
Offline Offline

Сообщений: 14


Просмотр профиля
« Ответ #1 : Мая 12, 2009, 09:12:28 pm »

1) Через таймаут t1 (по умолчанию 15сек), если вы не пришлете подтверждение получения пакета клиент выполнит active close, ваш таймаут не может быть больше t2, если за это время вы не получите полный пакет, то - active close должны выполнить уже вы.
2)104 не 101 мусору обычно неоткуда взяться, поэтому на любой мусор - аctive close
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #2 : Мая 13, 2009, 08:07:06 am »

спасибо, навели на верный путь...

получается таймер t2 надо запускать после приема первого байта?
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #3 : Мая 14, 2009, 04:12:12 pm »

реализовал обмен пакетами формата U.
Пошел дальше, опять вопросы:
1)
Цитировать
-Приемник передает подтверждение по крайней мере после получения w APDU формата I.
Получается нельзя сразу дать ответ на сообщение , а надо ждать, когда количество пришедших сообщений будет как минимум w?
Или тут имеется ввиду, что я (старая версия: не могу; новая: могу)послать как подтверждение сообщение формата S? Но сообщение формата S надо посылать вообще по таймеру
2)
Заводим счетчики переданных сообщений, принятых сообщений и подтвержденных
Но в протоколе под эти значения выделяются 15 бит. Итого в APCI можно передать максимальный передаваемый и принятый номер - 32767. А дальше что перебор?
Или максимальное число регулируется значением k? Но все равно при переходе номера со значения k на 0, могут быть всякие спецэффекты при подтверждении
« Последнее редактирование: Мая 15, 2009, 08:00:05 am от kvser » Записан
mgb14
Участник
*
Offline Offline

Сообщений: 14


Просмотр профиля
« Ответ #4 : Мая 14, 2009, 04:47:06 pm »

Тема не совcем "Программирование под QNX"  Cheesy
Получается нельзя сразу дать ответ на сообщение , а надо ждать, когда количество пришедших сообщений будет как минимум w?
Или тут имеется ввиду, что я не могу послать как подтверждение сообщение формата S? Но сообщение формата S надо посылать вообще по таймеру
Подтверждение  принятого I-кадра передается или сразу в ответном I-кадре (если он нужен) или посылкой S-кадра после принятия w-сообщений (то есть вы должны следить сколько принято неподтвержденных сообщений) или  S-кадром по таймауту t2 после первого полученного неподтвержденного
Заводим счетчики переданных сообщений, принятых сообщений и подтвержденных
Но в протоколе под эти значения выделяются 15 бит. Итого в APCI можно передать максимальный передаваемый и принятый номер - 32767. А дальше что перебор?
Или максимальное число регулируется значением k? Но все равно при переходе номера со значения k на 0, могут быть всякие спецэффекты при подтверждении
Значения счетчиков меняются циклически от 0 (после каждого установления связи) до 32767, после 32767 идет опять 0 - ну а со спецэффектами должны боротся вы  Cheesy - да нет их особо - обычное поведение unsigned переменной при суммировании и вычитании.
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #5 : Мая 15, 2009, 08:47:01 am »

Тема не совcем "Программирование под QNX"  Cheesy

а куда? в "Языки и алгоритмы"? пусть модератор тогда перенесет тему
тут реально нет соответствующего раздела кроме "Общение"  Cheesy
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #6 : Мая 22, 2009, 03:01:48 pm »

Появился еще вопрос:
Что должен делать слэйв при получении сообщения I-формата на неактивном соединении, т.е. в состоянии перед посылкой STARTDT_CON? Выполнять-таки команду и буферизировать сообщения ответов(а при переходе в активное состояние послать их), либо просто игнорировать?
Может ли (и когда это нужно) слэйв на неактивном соединении посылать сообщения S-формата  для подтверждения I-сообщений, в случае если слэйв их должен обрабатывать?
Записан
mgb14
Участник
*
Offline Offline

Сообщений: 14


Просмотр профиля
« Ответ #7 : Мая 22, 2009, 04:11:20 pm »

Получение I-кадров до STARTDT должно приводить к active close со стороны клиента.
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #8 : Мая 25, 2009, 01:29:48 pm »

Получение I-кадров до STARTDT должно приводить к active close со стороны клиента.
Как тогда понимать такое:
Цитата: ГОСТ
Любые данные пользователя на контролируемой станции, готовые к передаче, посылаются только после STARTDT con. ... Контролирующая станция может посылать команды или уставки, даже если она еще не получила подтверждения активации.

Т.е. контролируемая станции может получить данные по неактивному соединению, а также иметь какие-то готовые данные для посылки, но послать может после STARTDT con. Не понятный момент...
Записан
mgb14
Участник
*
Offline Offline

Сообщений: 14


Просмотр профиля
« Ответ #9 : Мая 25, 2009, 10:46:39 pm »

Это означает, что инициатива по открытию канала передачи данных всегда исходит от контролирующей станции (клиента), контролируемая станция (сервер) не может посылать имеющиеся у нее данные до получения STARDTDT act и выдачи STARTDT con.  Более подробно чем в 104 стандарте процедуры обеспечивающие совместимость описаны в документе: IEC/TS 60870-5-604 Edition 1.0 2007-10 Technical specification. Telecontrol equipment and systems – Part 5-604: Conformance test cases for the IEC 60870-5-104 companion standard.
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #10 : Мая 26, 2009, 11:18:33 am »

Это означает, что инициатива по открытию канала передачи данных всегда исходит от контролирующей станции (клиента), контролируемая станция (сервер) не может посылать имеющиеся у нее данные до получения STARDTDT act и выдачи STARTDT con. 
все правильно
но контролирующая станция может посылать команды и уставки на неактивном соединении, вопрос и заключался в том,
Цитировать
Что должен делать сервер(контролируемая станция) при получении сообщения I-формата на неактивном соединении

спасибо за наводку 604
Записан
mgb14
Участник
*
Offline Offline

Сообщений: 14


Просмотр профиля
« Ответ #11 : Мая 27, 2009, 12:08:57 am »

Фраза о том, что контролирующая станция может посылать команды не дожидаясь подтверждения STARTDT не означает необходимость контролируемой станции принимать и обрабатывать эти команды до получения STARTDT act, то есть несмотря на природу TCP предполагается, что пакет со STARTDT act придет раньше любых переданных после него команд и задача контролирующей станции это обеспечить, обычно это делается тем, что контролирующая станция не спешит с выдачей команд, а дожидается STARTDT con от контролируемой станции.
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #12 : Мая 27, 2009, 12:59:08 pm »

Более подробно чем в 104 стандарте процедуры обеспечивающие совместимость описаны в документе: IEC/TS 60870-5-604 Edition 1.0 2007-10 Technical specification. Telecontrol equipment and systems – Part 5-604: Conformance test cases for the IEC 60870-5-104 companion standard.
спасибо за наводку 604

интересно где этот документ взять? не нашел в свободном доступе, в российских гостах тоже нет.
Записан
mgb14
Участник
*
Offline Offline

Сообщений: 14


Просмотр профиля
« Ответ #13 : Мая 27, 2009, 07:08:51 pm »

Как все МЭК-овске стандарты в свободном доступе их официально нет. Мой экземпляр приобретен официально и на каждом листе идентифицирующая владельца надпись  Cheesy
А ГОСТ-ы в России выпускаются с огромным лагом - до сих пор не издана вторая редакция 104 (изданная МЭК в 2006 году), кстати там тоже есть несколько полезных уточнений по сравнению с первой редакцией (переведенной и изданной у нас в качестве ГОСТ)
Записан
kvser
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #14 : Мая 28, 2009, 09:21:22 am »

Как все МЭК-овске стандарты в свободном доступе их официально нет. Мой экземпляр приобретен официально и на каждом листе идентифицирующая владельца надпись  Cheesy
А ГОСТ-ы в России выпускаются с огромным лагом - до сих пор не издана вторая редакция 104 (изданная МЭК в 2006 году), кстати там тоже есть несколько полезных уточнений по сравнению с первой редакцией (переведенной и изданной у нас в качестве ГОСТ)

да, я заметил. У меня МЭК-овская официальная 2004 года. Где-то с месяц назад была приобретена. Эххх...
Записан
Страниц: [1] 2
  Печать  
 
Перейти в: