41

Re: 61850 / goose / потеря связи

определение - это к тем, кто их соблюдает, я их - обычно - нарушаю  ICQ/ae:P .
Если в контексте сказанного: канал в котором независимо от наличия передаваемых данных ПОСТОЯННО присутствует информация (синхропоследовательность, пилот-сигнал и т.д.), позволяющая НЕПРЕРЫВНО осуществлять контроль качества и параметров (например, ОСШ и вероятности ошибок, адресации и синхронизации) канала/сети связи, и сообщающая оконечному устройству о своей готовности к передаче данных с ЗАДАННЫМИ параметрами надежности/готовности, и корректирующая параметры канала/сети, если это необходимо.

Из всего сказанного Вами далее (и о чем я писал еще в 2000 году, как о недостатках стандарта, правда тогда еще в отношении UCA) следует, что контроль достоверности передаваемой информации отсутствует. Потому что гуси считают, что это дело сети обеспечивать заданные параметры качества. А сеть об этом знает ? (Ethernet - точно нет)
Кстати, а кто занимается физической структурой сети, на которую ложится гусь? Неужели релейщики? или связисты? АСУ-шники?

ЗЫ.
я не пытаюсь доказывать, что это хорошо или плохо.
Я тоже практически уверен в том, что будущее РЗА за последовательными каналами (и в библиотеке - пока - выкладываю только позитивную информацию).
Меня больше интересуют причины трансформации сознания релейщиков, которые с одной стороны готовы до хрипоты спорить о характеристиках и необходимости ежегодной поверки на порядки более надежных вещей (например, ВЧЗ), а с другой под прессом производителей "слепо" верить в новые много более дорогостоящие технологии (похоже на посещение рынка или бутика: дорого, значит - хорошо, ГУЧЧИ - значит хорошо)


obagley пишет:

Sergei,

1. На мой взгляд, ваше определение избыточно. Ключевое отличие синхронного и асинхронного канала в следующем: в асинхронной связи имеются старт-стоп метки, по которым синхронизация тактов передатчика и приемника происходит заново на каждый пакет, а в синхронной связи этих меток нет, поскольку синхронизация тактов осуществляется иным способом. Основных способов два: восстановление тактовой частоты из непрерывного потока данных (осуществляется обычно с помощью PLL, phase locked loop) или специальная синхропоследовательность, которая может передавать как по отдельной физической линии (например, в стандарте X.21), так и по тем же проводам, что и основной сигнал (например, co-directional G.703). В общем и целом мне думается, что способность НЕПРЕРЫВНО осуществлять контроль качества и параметров канала связи не является неотъемлемой характеристикой синхронного канала. Может присутствовать, может и нет.

2. Я бы не сказал, что контроль достоверности передаваемой информации отсутствует. Просто он осуществляется на другом уровне и в соответствии с другими стандартами. Если любопытно, посмотрите стандарты IEC 8802-3, IEC 8877 и IEC 60874, они используются на физическом уровне для передачи гусей. Увы, современные реалии таковы, что в одном стандарте невозможно описать абсолютно все. Поэтому и идет отсылка к уже имеющимся стандартам.

3. Физической структурой сети должны заниматься системные интеграторы, в том числе и используя рекомендации фирмы-производителя. А иначе действительно можно на офисных свичах подстанционную сеть сгородить и удивляться потом.

4. Вопрос "кто чем занимается и кто за что отвечает" - очень уж философский :-) Тем не менее, обратите внимание на тот факт, что проблема взаимоотношений связистов-асушников-релейщиков давно и успешно решается, с тех пор как начали внедрять ДЗЛ по оптике, системы передачи команд через мультиплексоры и тому подобное. GOOSE-сообщения - это абсолютно то же самое, но внутри подстанции.

5. Про "последовательные каналы" - не понял, от них наоборот везде отказываются в пользу одноранговых сообщений (GOOSE) и систем клиент-сервер (прочие виды коммункации в рамках IEC61850.


Прошу извинения, но перенос получился кривой, нехватка опыта

Sergei пишет:

пункт 5 - это неправда, желаемое, а не действительное

42

Re: 61850 / goose / потеря связи

Прочитав всю переписку, я так и не понял - что все-таки рекомендовали... Самый простой способ - контроль достоверности каждого сигнала пускать по "И" со значением самого сигнала, при этом появление недостоверности любого сообщения от от одного и того же терминала по "ИЛИ" выводить на предупредительную сигнализацию. А вообще, мое мнение, передавать такие сигналы как блокировка/разрешение ЛЗШ, пуски УРОВ, дистанционное включение/отключение не особо хорошо (рано или поздно кто то да и пошлет не то и не туда, ведь вывести goose сложновато, это не проводок откинуть для видимого разрыва).

43

Re: 61850 / goose / потеря связи

more,
Ваше отношение понятно и на этом этапе инженерии верно!
Но уже через 5-10 поектов саи захотите сделать, набив руку.

44

Re: 61850 / goose / потеря связи

grsl,

не поверите - сделал уже не один, а желание все больше пропадает, особенно если терминалы собраны по оптическиму кольцу... Default/hmm:/ И насколько знаю, ФСК тоже отказывается от передачи релейных сигналов по goosю. Я уж не говорю про немцев (славный Siemens Nürnberg), которые по гусю передают только сигналы оперативной блокировки, а все остальное медью.

45

Re: 61850 / goose / потеря связи

ICQ/ad;)
Почему, и в это поверю.
И верю что кольца надоедают, потому только звездой, нафик кольца никому не нужны.
Ну если гусями только блокировки, то ну их совсем. Есть тогда более простые решения.
Я как то писал, шинка ПС для блокировок, напруги около 24 проводов и всё, если одиночная система шин и того половина.

46

Re: 61850 / goose / потеря связи

Ну на это есть другое мнение ФСК. Отдельный источник питания на 2 часа как минимум. А зачем, если терминалы и так питаюстя от АБ. И все-таки дополнительный вопрос - как выводить из работы сигналы гуся? В сипротеках, допустим есть вход "блокировка передачи данных", но он не работает, заблокировать можно хитрым путем, но только до перестарта терминала, потом передача данных продолжается. Мне до сих пор интересно - сколько простоит ПС 500 Воронежская ICQ/ag:D . Там все сделано по гусю - пуски УРОВ, FG:N? команды отключения и включения. Я, конечно понимаю - "ПРОГРЕСС", но хотелось бы посмотреть на процедуру плановых работ на териналах (наверное так и отцепляют Ethernet от терминалов  Default/lol:lol: )

47

Re: 61850 / goose / потеря связи

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

Тут грядут несколько проектов где всё будет на гусях, кроме напруги шин нет никаких шинок, если буду участвовать, как инспектор ( 50 на 50 шанс), буду требовать выполнения.

48

Re: 61850 / goose / потеря связи

А почему нельзя каждый сигнал передавать через элемент И ? На второй вход вешаем плюс от общего ключа "Вывод Гусей терминала". Таким же образом можно, наверное, и прием организовать..... Только не надо говорить про ресурсы логики.... И не надо критиковать немцев. У них изначально гуси можно было только в классе "Control"  прописывать, где идут свои требования к допустимому  времени передачи. А наши горе-проектировщики, не читающие техдокументацию, воткнули их якобы в класс "protection", где совсем другие требования, согласно стандарта ко временам передачи.... Вот и пришлось немцам срочно обеспечивать для класса "Control" обеспечивать времена как для класса "protection", вот так от чьей-то безграмотности технический прогресс развивается....
Вообще, странно, почему до сих пор не сделали механический оптический ключ, который бы "перегораживал" свет в оптическом кабеле, блокируя передачу сообщений.... А может такой ключ есть, просто у нас специалистов по оптике нет?

49

Re: 61850 / goose / потеря связи

Ну если Конспиратор начал , то я продолжу.
Ресурсы логики сегодня фигня, там такие запасы.....


Когда то сделал, опять таки на LON, до сих пор работает, два сигнала ( было УРОВ и блокировка ЛЗШ), один рабочий, один тестовый.
когда реле переходит в режим тестирования, инфа идёт по тесту,а рабочий канал свободен.
Т.о образом проверяется всё от начал до конца.
Не могу особено расписать, так как нужно конечо на конкретных примерах и конкретной логике.

50

Re: 61850 / goose / потеря связи

На самом деле, лет 7-8 назад, нужна была такая фигня "пакетный переключатель для оптики".
Будете смеятся, но тогда нашли, правда не купили, как то боязно было и нашли более элеганатное решение.

51

Re: 61850 / goose / потеря связи

Ну по поводу запасов ресурса логики - то это не фигня. Быстрая логика Сименса ограничена, и очень сильно. ICQ/ae:P

52

Re: 61850 / goose / потеря связи

НУ сколько той быстрой логики надо то ?
  10 -20 gates and timers.

53

Re: 61850 / goose / потеря связи

more, и кстати, а пробовали ли вы на серии 7SJ800, как там с ресурасами?
один из проектов может быть имено с этими реле

54

Re: 61850 / goose / потеря связи

more пишет:

Ну по поводу запасов ресурса логики - то это не фигня. Быстрая логика Сименса ограничена, и очень сильно. ICQ/ae:P

То, что Вы подразумеваете под "быстрой логикой" (PLC), то ее можно  и не считать, будто бы ее и нет.... Мы говорим о логике PLC1, которую кто-то когда-то отнес к "медленной" логике и посчитал, что ее нельзя использовать для РЗА....
На самом деле,рекомендую померить задержку прохождения сигнала в этой логике при ее 100% использовании в режиме КЗ..... Тогда увидите, что она не медленная, а очень даже и ничего (только не берите терминал со старым процессором, например 7SJ62).

55

Re: 61850 / goose / потеря связи

ну да - скорее нет спецов по оптике
различное коммутационное оптическое оборудование даже в России и механическое и электро-оптическое было уже лет 25-30 назад.
А уж в РЗА, имхо, оно как воздух нужно - для обхода дефектных устройств/узлов/муксов

56 (2018-03-05 21:36:17 отредактировано obagley)

Re: 61850 / goose / потеря связи

Deleted

Oleg Bagleybter

57

Re: 61850 / goose / потеря связи

grsl,

Таких терминалов пока не испытывал, хотя видел. Поэтому ничего конкретного сказать не могу. ICQ/ac:(

58

Re: 61850 / goose / потеря связи

Распределение ресурсов процессора по типам логики для различных терминалов  (number of ticks)
Терминал   
                                 PLC         PLC1    MW_BEARB        SFS
6MD66 v4.8    1000    5000    3000    3000
7VK v4.6                    400    2000    10000    10000
7SA, 7SD5 v4.6    200    1900    10000    10000
7UM62 v4.6    400    2000    10000    10000
7UT613 v4.6    200    2000    10000    10000
7UT612 v4.6    90    255    1200    1000
7SJ80 v4.6    400    2000    10000    10000
7SJ61                    130           255      2536     2173
7SJ62-64 v4.7    400    4000    10000    10000

59

Re: 61850 / goose / потеря связи

Что-то в предыдущем сообщении некоторые строчки сдвинулись, но кому надо, разберется......

60

Re: 61850 / goose / потеря связи

obagley,
Что таким образом будет проверено, только наличие сигнала в сети, goose-анализатором?
нaверное даже индикации на АСУ не выходят?
А если я хочу кусок схемы проверить в полном объёме, а кусок в тестовом?