[ На главную ] -- [ Список участников ] -- [ Правила форума ] -- [ Зарегистрироваться ]

МЭК104. Механизм защиты от потери данных

  Вход на форум   логин       пароль   Забыли пароль? Регистрация
On-line:  

Раздел: 
Телемеханика и связь в энергетике / Модемы и протоколы ТМ / МЭК104. Механизм защиты от потери данных

Страницы: 1  ответить новая тема

Автор Сообщение

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 02-10-2012 10:57
Добрый день.
Разрабатываю ПО slave станции КП.
Ситуация следующая:
Имеем к примеру Slave станцию КП c которой через МЭК104 могут работать несколько Master станций. Для работы с каждой из них на КП организуется собственный буффер посланых APDU (т.е. каждый мастер работает с КП асинхронно с другими).

В процессе работы КП контролирует счетчик подтвержденых АПДУ мастером и стирает подтвежденые сообщения в буфере(для каждого мастера независимо).

Вопрос в следующем:
Если после отправки очередного пакета с нумерацией на мастер станцию, станция КП не получила подтверждения в течение таймаута, согласно ГОСТ следует активное закрытие на КП и т.д... Счетчики посланых и принятых APDU в 0.

1)Что делать с теми сообщениями которые не были подтверждены?
а) стирать и забыть про них...
б) отправить их мастеру...тогда как понять что заново подсоединился именно тот мастер который был до этого?

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 08:58
Каждый производитель софта делает по-разному
1.вообще после разрыва соединения все стирать, т.е. в многопоточной slave-станции закрывать поток этого клиента с потерей всей информации о нем. Это проще всего, но не будет режима отложенной передачи данных (этот режим рассмотрен на ветке форума «ОИК»). Сейчас многие КП такой режим поддерживают, но далеко не все SCADA могут такие данные принять – даже у одного и того же производителя софта КП и SCADA бывает, что КП работают в таком режиме, а верхний уровень – нет.
2.если режим отложенной передачи поддерживать, то данные не переданные клиенту за время перерыва связи, нужно сохранять в буфере (обычно до 2000 событий на каждый ТС). А какому клиенту «не додали» данных модно определить по адресу клиента при начале соединения.
3.есть и проблема – а сколько данные в буфере хранить – вечно (сбрасывать на внешний накопитель), несколько часов (пока канал не починят), до перезагрузки КП? Определяется местными условиями. Например, КП работает только на один и тот же верхний уровень (их обычно несколько). После разрыва связи через некоторое время канал восстанавливается и данные «додаются». Здесь хранить можно «вечно», или до перезагрузки КП – верхний уровень ведь когда-нибудь все-равно появится. Другая ситуация – «случайный» клиент. Например, я раз в месяц подключаюсь ноутбуком для контроля – при разрыве связи сохранять непереданные данные не нужно. В следующий раз я другим ноутбуком может быть подключусь. Определять «постоянных» и «случайных» клиентов можно, например, по наличию или отсутствию синхронизации времени, или при конфигурации КП их указывать.

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 03-10-2012 11:17
Да, все верно написано, спасибо. Мыслим в одном направлении и наступаем на одни и теже грабли...

Проблема осталась с идентификацией клиента при подключении, идея "по адресу" (если конечно имеется ввиду IP адрес) не подошла в следствии возможного использования Firewall-ов с NAT, тогда КП видит всех клиентов с одним и тем же IP.

В 104 протоколе есть еще такая вещь как "Originator Address" и в случае если под причину передачи используем 2 байта можно клиентам назначить уникальные orig адреса и на КП определять кто и что недополучил...Но что делать если под причину передачи занят 1 байт и поля originator address нет совсем?

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 11:49
идея использовать под причину передачи 2 байта вполне подходит. В "формуляре согласования" нужно будет только это указать - что в системе ТМ вот такая адресация. О других идеях надо подумать. Если не делать ничего - подключится "случайный" клиент и все данные отложенные соберет, хоть они ему и не нужны.

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 13:00
А вот еще один экзотический способ идентификации клиента. После прерывания канала и последующего его восстановления от "мастера" передавать кадры не с нулевого, а с того номенра, на котором был обрыв. КП после инициализации свои счетчики обнуляет, и смотрит, а с каким номером пришел первый же запрос? Если КП запомнил последний пришедший номер от "мастера" до разрыва канала, то так можно определить, какой "мастер" соединился, давать ли ему сохраненные данные и какие (у каждого клиента свои). Сейчас попробовал - КП так работает. Надо бы посмотреть, нет ли запрета какого в госте. Вроде нет - "мастер" же не инициализируется, счетчики просто инекрементируются, и, может быть, не обязательно от нуля.
2.а другие люди еще делают так - по рабочему и резервному каналам от КП дают одни и те же данные, но с разных портов. Но от "случайных" (не запланированных) клиентов это не спасает.

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 03-10-2012 13:38
Действительно, идея счетчиков "экзотичексая" )

Но к сожалению система разрабатывается как слэйв, при условии того что к ней будут подключаться различные мастера с различными скадами разных производителей с одним общим знаменателем - это использование МЭК 104. И механизм реализации счетчиков (теоретически) у них может разнИца.

Касаемо же "нет ли запрета какого в госте"...вроде что-то есть.
Запрет или же указание это: Из госта 104 "...после установления TCP соединения передаваемые и принимаемые порядковые номера устанавливаются в ноль."

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 14:45
продолжаем экзотику:
квитанции по гост можно подавать не на каждый кадр, а на группу. По умолчанию группа = 12. Ее можно настраивать на каждом "мастере" по своему

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 14:55
или вот еще:
работать реально на asdu=1, а от каждого мастера подавать на опрос еще и "свой", несуществующий на КП asdu. В результате КП получает опрос по asdu=1 и еще по какому-нибудь, идентифицирующему "мастера". По asdu=1 выдает данные, как положено, а по несуществующему asdu ничего не выдает, только квитанции и подтверждения.

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 03-10-2012 14:56
А также квитанции отсылаются мастером по таймеру...независимо от достижения макс. числа принятых

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 15:00
а как при этом идентифицировать мастера? не понял

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 03-10-2012 15:07
в том то и дело )) никак...
а вот по поводу доп. запроса на не сущесвтующий асду на КП, очень даже ничего...тока проблема опять может быть (теоретически) с "мастерами"...можно ли там будет проворачивать такеи фокусы с настройками

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 15:12
на мастерах можно делать любые настройки - такое можно поставить условие, кто хочет с этим КП работать. Сделать их будет легко (главное, чтобы не повторялись у разных мастеров).

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 03-10-2012 15:19
можно выделить диапазон несуществующих асду, в каждый из них записать по одному ТС (ну вроде это байт состояния и его надо принимать - так объяснять тем, кто на верхнем уровне)

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 03-10-2012 16:37
Родилась такая идея...реализуемая с точки зрения любого мастера мне кажется.
Если есть коннект, мастер для того что бы для него велся буффер на сервере, пишет свой уникальный id в КП (используя даже стандартный аsdu для записи целого) в какой-то оговоренный ранее регистр.
С момента записи (а до нее в этом адресе 0) КП создает для этого мастера буфер и начинает работать через него.
Когда рвется связь и спустя некоторое время восстанавливается мастер опять пишет свой id в КП, КП же в свою очередь проверяет что для данного id в буффере через который он работал ранее есть данные и шлет их ему...сразу после ответа на общий опрос.

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 03-10-2012 16:38
Если же мастер ничего не записал, то КП работает с ним без буфера, т.е. так можно цеплятся своим ноутом для тестов

бывалый
Группа: Участники
Сообщений: 55 		Добавлено: 04-10-2012 07:57
Да, с ид, видимо, подойдет. А как его закачивать в КП? Как ТУ?

редкий гость
Группа: Участники
Сообщений: 19 		Добавлено: 04-10-2012 08:26
ну да, как ТУ

Страницы: 1  ответить новая тема
Раздел: 
Телемеханика и связь в энергетике / Модемы и протоколы ТМ / МЭК104. Механизм защиты от потери данных

KXK.RU