|
[ На главную ] -- [ Список участников ] -- [ Правила форума ] -- [ Зарегистрироваться ] |
On-line: |
Телемеханика и связь в энергетике / Модемы и протоколы ТМ / ТУ в ТМ |
Страницы: 1 2 Next>> |
Автор | Сообщение | |||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 11-10-2010 17:04 | |||||
Здравствуйте! Поясните, пожалуйста, как принято в телемеханике передавать с ПУ на КП команды телеуправления коммутационными аппаратами в протоколе МЭК-101/104? Передачей слова, к котором упакован номер аппарата и операция (вкл/выкд), которую нужно выполнить, либо обращением по адресу конкретного аппарата? |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 18-10-2010 17:20 | |||||
Вопрос не ясен, что не понятно? В протоколе достаточно точно и ясно это прописанно. Есть 2 номера комманд для использования в качестве ТУ. Это комманда с типом 45 (однопозиционная) и типом 46 двухпозиционная. Соответственно вкл/выкл задаются 1 или 2мя битами (в отдельном байте). Адрес объекта стандартен как и для других типов данных (ТС,ТИ). Обычно это слово. Эти оба параметра не упакованны в слово, а занимают свои байты. Читайте стандарт. | ||||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 26-10-2010 10:20 | |||||
Я только пытаюсь вникать в работу по этим протоколам, поэтому, мне кажется, что если коммутационных аппаратов несколько сотен, то было бы удобнее посылать команды управления разными коммутационными аппратами на один адрес (например, командой с типом 49, а не просматривать сотни адресов в каждом цикле на предмет обнаружения команды управления. Правда, тогда на стороне ПУ придется упаковать в одно слово и номер коммутационного аппрата, и выполняемую операцию. Или это не соответствует идеологии протокола? | ||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 31-10-2010 18:34 | |||||
Ни то и не другое. По протоколам (если коротко)указан тип передаваемой информации и её адрес. А "кому чего и куда" занимается , как правило контролер, который сконфигурирован в соответствии с привязкой железа (там свои адреса). Так что, нарисовать протокол и связать с каким то конкретным изделием - не выйдет. |
||||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 02-11-2010 08:49 | |||||
Но как контроллер определит "откуда" пришла команда, если управление осуществляется из нескольких мест? |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 02-11-2010 16:35 | |||||
А контролеру по-барабану откуда управление. Просто активизируется тот дискретный выход, на который ссылается привязка. А что касается разных мест, то , допустим 101 протокол всегда через СОМ порт, и сколько портов, столько и мест (даже возможно с одним и тем же номером ASDU). Почти так же и по 104. Я думаю, что Вы имеете мало опыта програмирования контролеров, и если попрактикуетесь, то сразу масса вопросов отпадёт. Кстати, "АББ" последние года комплектует SCADA шкафами RTU560. На базе этих шкафов строится и телемеханика. Особенность RTU560 в том, что используется контроллер CPU560, позволяющий вести автономный сбор и передачу информации для ТМ. Очень многофункциональный и гибкий, позволяет вести передачу как Slave, так и в режиме master, с протоколами модбас, внутренняя шина I/O, 101, 104, Ethernet, стыки RS232,RS485,RS422. Позволяет с помощью РЛС-функций создавать витруалные данные и логические операции. Это всё сказанное не в качестве рекламы. Я просто эксплуатирую телемеханику RTU560 и знаю её достоинства. Так что, рекомендую поближе познакомится с контролерами (лучше всего с хорошими). |
||||||
ASM Группа: Участники Сообщений: 5 |
Добавлено: 02-11-2010 17:36 | |||||
Контроллеру-то по барабану, но в архив событий нужно занести инициатора команды. То, о чем вы говорите, верно, если непосредственно в программе контроллера обращаться к функциям работы с COM-портами или Ethernet. А если обмен с "внешним миром" определяется на стадии конфигурирования контроллера, то при работе программы контроллера уже не понять, откуда появилась команда по 101 протоколу от диспетчера или по 104 от оператора ПС по данному IOA. Обмен по этим протоколам в данном случае идет уже "независимо от нашего сознания". Думаю, что со временем масса вопросов отпадет, хотя и не сразу)) А с RTU-560 обязательно познакомлюсь при случае. |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 11-11-2010 12:00 | |||||
Alleksandr
Не верно. Это частный случай, и в стандарте нет такого ограничения. МЭК 101 может передаваться по любым низкоскоростным последовательным каналам. Мы его используем при передаче данных ещё и через RS-485, GSM-связь, модемная связь(напр: телефонный канал, ВЧ-связь).
Адрес ASDU обычно представляет собой "Адрес КП" по нашему, и поэтому он един для всех данных контроллера. ASM
Почему не понять? Если Вы сами пишите ПО контроллера то ВСЁ в ваших руках. А вот если используете чужую оболочка типа Изаграф или Кодесис, то тут ...
Присвойте всем связным интерфейсам разные адреса и сохраняйте их в журнале при приёме ТУ, или что Вам там надо. А для чего контроллеру нужна эта инфа? Всё что должен контроллер это выстрелить ТУ на исполнение и выдать на верх квитанцию об успешном выполнении. Или Вам требуется запрет выдачи ТУ с некоторых интерфейсов?
Получиться каша. Как разобрать кому пришло ТУ. Такого в стандарте нет.
Во первых тип 49 предназначен не для ТУ, а для ТР (аналоговый выход). Упаковывать вместе адрес и выполняемую команду нельзя. В стандарте для этого есть разные поля. Никак не пойму для чего Вы пытаетесь переиначить стандарт и в общем то усложнить работу. Вся эта упаковка-распаковка всё делает сложнее. Есть слово - занесли в него адрес. Есть байт - занести в него команду. Всё вроде просто в данном случае. Это я Вам говорю как автор ПО для контроллера телемеханики ВАРИКОНТ-МИКРО. |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 11-11-2010 16:18 | |||||
Не верно. Вы путаете различные интерфейсы. Сом порт - устройство для реализации обмена, а RS232(422,485)- тип стыка двух обменивающихся устройств. Тем более и GSM не в тех дебрях нарыли. Может вы и автор ПО, но в электронике - слабоват. |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 11-11-2010 17:22 | |||||
Alleksandr
СОМ-портом исторически называют интерфейс RS232. А "устройством для реализации обмена" можно назвать микруху UART (например), если уж быть более точным. Хотя вообще эта фраза слишком расплывчата. Надо более конкретно выражаться что имеете ввиду. Например слово "стык" в приминёной фразе не совсем верно, правильнее называть стандарты RS232(422,485) типом интерфейса.
Позабавило. Скорее всего у Вас приняты другие понятия и идёт путаница.
Имел ввиду что МЭК 101 можно передавать не только по шнурку, который соединяет 2 устройства через интерфейсы RS232, но и через GSM модемы. А также МЭК 101 можно передавать через телемеханические модемы по аналоговым линиям связи, что я ранее и упоминал. А уж они к СОМ порту ни как не относятся! Как пример, у нас плата модема вставляется прямо в контроллер как и все другие платы. А если кто использует устаревшую идеологию построения на основе кАнальных адаптеров и простейших ЧМ-модемов типа АПСТМ (прошлого века), то сочувствую. Мы проводили сравнительный тест с подобной системой. И те люди поняли что не канал связи у них барахлит, а железо такое. Это я отвлекся.
Не верно. |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 11-11-2010 20:35 | |||||
Если "откуда пришла команда" определяется протоколом 101/104 = таки наверно Вы знаете текущий/используемый протокол при принятии команды в теле программы ? :) Обычно сначала же происходит распознавание протокола, затем прием /анализ данных. ИМХО |
||||||
Alleksandr частый гость Группа: Участники Сообщений: 39 |
Добавлено: 12-11-2010 08:46 | |||||
Сожалею, но Вы не правы. Не знаю, какие исторические корни у тех или иных названий, и в какое время , и кто им это раздавал, но на сегодня даже ребята из Майкрософта Вам подтвердят. (извините, что пальцем ткну :-). Включаете комп. - правой кнопкой Мой компьютер –Свойства – Оборудование – Диспетчер устройств – Порты – Сом(со своими драйверами). -------Слабак!----- (как выразился бы Леонид Быков в фильме "В бой идут одни старики" (Конечно - шутка!) |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 12-11-2010 09:07 | |||||
Интересно, как Вы умудрились работать по 101-у протоколу через аналоговый канал связи с помощью телемеханических модемов!?. Насколько я знаю, в ТЧ канале скорость телемеханики ограничена величиной в 2400Бод. А для 101 протокола рекомендованная скорость не ниже 9600 бит\с?????? То, что запихать 101 в ТЧ канал можно - да, согласен, только не говорите, что он - РАБОТАЕТ!!!!!!! Метки времени, фоновое сканирование, общий запрос и т.п. и т.д. на низких скоростях канал забивают напрочь, в итоге реальную картину какого-либо инцидента на объекте отследить практически невозможно (это из двухлетнего опыта работы со 101 протоколом). По поводу канальных адаптеров: да, идеология может и устаревшая на сегодняшний день, но практически она РАБОТАЕТ и довольно неплохо. Имейте ввиду, что канальный адаптер ведет первичную обработку всей поступающей телемеханической информации, а потом отправляет ее в HOST (верхнему уровню ПЭВМ), который занимается окончательной обработкой (архивирование, ретрансляция и т.п.) Такое "разделение" наиболее ГРАМОТНО, чем если у Вас ВСЕМ занимается ОДИН контроллер!!!!!!!!!! |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 12-11-2010 11:02 | |||||
Alleksandr Я так и подумал что понятия у Вас "из винды". Ребята из Майкрософта всё делают что бы домохозяйкам... было понятно. Да, там для упрощения применили наименование СОМ порт. Но Вы где то видели комп с RS585 на материнке? Отсюда и прирасло понятие СОМ=RS232. Обратимся к первоисточнику, для разьяснения. А им является IBM PC. Там был СОМ порт для связи с мышкой и модемом. И он всегда был только RS232. Это просто вопросы терминологии. Как я и говорил у нас с вами они чуть разняться. Ну не называем мы интерфейс RS485 СОМ-портом. О шутке - ой как не красиво. marshal
У нас вышло постановление концерна что вся телемеханика должна уметь работать с 101 и 104. Вот мы их и реализовали на всех видах связи. Но эти протоколы не являются у нас основными. Их ставим только по просьбе заказчика. А основным является протокол от телемеханики Сириус. Он гораздо быстрее и легче МЭКов. У нас не простой ЧМ-модем, а модем на основе сигнального процессора. Он производит цифровую фильтрацию входного сигнала с полосой пропускания рассчитанной исходя из заданых частот 0 и 1 и скорости, причём он делает это сам. Затем приём сигнала и его проверка. Центральному процу он передаёт готовый пакет с уже проверенными контрольными битами. Например при приёме протокола МКТ-3, модем приняв 14 битовое слово проверяет все 5 контрольных бит. Центральному процу выдаёт уже нормальный 8 битный байт данных. Это уже не модем в ваших понятиях, это гораздо большее. Посему разделение для нас не имеет смысла. Мы получили гораздо более высокое качество приёма! 2400 бод это предел для ЧМ модемов, и то на широком канале. Мы давно сделали фазовую модуляцию со скоростями до 9600, и ЧМ практически не используем. В канале с полосой до 3 кГц устойчивая связь со скоростью 4800. Подробнее тут
Нет. Учитывайте что у нас в каждом модеме свой мощный проц. Центральный проц контроллера только "тусует" готовые пакеты. Итого в 1 контроллере у нас до 12 процессоров, вместе ведут работу. Поймите, Вы просто не видели как можно работать по другому. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 12-11-2010 11:27 | |||||
Тогда это уже не совсем модем, а типа канального контроллера (который работает с каналми ТМ, а затем выдает "наверх"). Тогда вопрос: чем такое Ваше устройство отличается от классического канального адаптера? (который,например, у нас обрабатывает сразу 32 канала, вставляется в PCI-слот ПК). |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 12-11-2010 12:39 | |||||
Представьте, работает на скоростях 300-600 бод. Телеканал М2 емкостью 80ТС,40ТИ.Настроены апертуры. Общий опрос и команда синхронизации времени - раз в час. Период фонового сканирования ТС/ТИ что-то порядка 1 и 2 минут, кажется. |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 12-11-2010 12:55 | |||||
Скорость в идеальном канале ТЧ с использованием модемов 57600 бит/с история
А по поводу стык/интерфейс/протокол троллинг кончайте! Детский сад просто.. |
||||||
vad74 бывалый Группа: Участники Сообщений: 57 |
Добавлено: 12-11-2010 13:20 | |||||
Скорее это плата совмещающая в себе функции модема и канального адаптера.
Тем что наш модем работает с 1 направлением, но обрабатывает одновременно обе линии - приём и передача. Ну и содержит сам "модем". Наша часть "аналогового модема" фильтрует сигнал в точности под параметры связи. Обычный внешний модем ничего про параметр скорости канала не знает. А значит и точно фильтровать не может и его полоса шире оптимальной. Легче сюда пролазят шумы, помехи и наводки соседних каналов. Часть "канального адаптера" имеет доступ к исходной синусойде и точнее производит автоподстройку по скорости... Генераторы старых КП уходят в сторону, и частоты и скорости их плавают. Мы работая непосредственно с синусойдой точнее подстраиваемся под них. Надёжность выше. Ещё массо-габаритные показатели в нашем случае ниже на порядок а то и на 2 порядка. Да, чуть не забыл. Всё это работает при -25С, и не требет обогрева. Таже плата модема работает и в составе КП. У нас единый конструктив на КП и ПУ, наполнение разное. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 12-11-2010 14:05 | |||||
Понятно..........В диалог вступил в силу того, что сам с 2000 года эксплуатирую устройства ТМ через канальные адаптеры и модемы ТМ...... На сегодняшний день в лабораторных условиях протестировал устройства, через которые ЛЮБОЕ устройство телемеханики способно работать в сети Ethernet по ЛЮБОМУ протоколу. (подробнее в топике "Подключение 2-х устройств телемеханики через Ethernet"). Так что использовать ТЧ канал для передачи телеинформации, наверное, уже не будем.......... Вот......... |
||||||
Ol_merry Группа: Участники Сообщений: 8 |
Добавлено: 13-11-2010 10:14 | |||||
у нас принимается ТМ в 101 протоколе на обычный модем ТФМ на скорости 1200. И отлично всё работает |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 13-11-2010 10:26 | |||||
Что значит отлично!? Вот расчет скорости для МЭК 101/104: Все параметры ТИ, ТС передаются по изменениям. Изменившаяся телеинформация (ТИ, ТС) ставится в очередь (ТС в свою, ТИ в свою) на передачу с меткой времени, точность которой 1 мсек. Очередь разбирается по мере освобождения канала связи по принципу «первый зашёл – первый вышел». Наибольшим приоритетом обладает очередь ТС. Пример: Максимальный размер ASDU (блок данных прикладного уровня) МЭК 870.5-101/104 равен 247 байт. 1. ТИТ в формате float + 7байт метки времени. На каждый ТИТ идет 4+1+7+3=15, где 4-значение 1-качество, флаги достоверности, ручной ввод и т.д. 7-время 3-адрес параметра Получается 247/15=16 параметров за одну посылку. К посылке добавляется шапка 6 байт, получаем 253 байт. 100 ТИТ можно передать за 100/16=6,25 посылок или за 6,25*253=1581 2. Одиночный ТС+7байт времени к каждому ТС На каждый ТС идет 1+1+7+3=12, где 1-значение одиночного ТС 1- качество, флаги достоверности, ручной ввод и т.д. 7-время 3-адрес параметра Получается 247/12=20 параметров за одну посылку. К посылке добавляется шапка 6 байт, получаем 253 байт. 100 ТС можно передать за 100/20=5 посылок или за 5*253=1265 байт Итого 1581+1265=2846 байт или 22768 бит. При скорости канала 1200 бит/сек время передачи изменения всех ТС и ТИТ составит 18,97 с. И Вы считаете это "ОТЛИЧНО РАБОТАЕТ"!? |
||||||
skoctehs ветеран Группа: Участники Сообщений: 117 |
Добавлено: 13-11-2010 12:59 | |||||
ТСы и ТИТы пакетами/группами могут передаваться: · данные группы ТС (ГТС) · данные массива ТС (МТС) · данные группы ТИТ (ГТИТ) А скорость - да, где-то надо побыстрее вот 8 КП на радиолинии скорость 50 бод лидер 1200 мс просто опрос требования проходит где-то раз в 30 секунд ТС доходит до диспетчера через 45-120 секунд. |
||||||
marshal аксакал Группа: Участники Сообщений: 553 |
Добавлено: 13-11-2010 13:35 | |||||
К примеру, по проекту у нас на одной из ПС порядка 107 ТС и порядка 50 ТИТ. Теперь представьте, сколько ТС\ТИ изменится при системной аварии на ПС. Ясно, что не один и не два........ К тому же, из всех изменившихся ТС\ТИ диспетчеру нужно точно знать, что явилось ПРИЧИНОЙ аварии, а что СЛЕДСТВИЕМ. Это он может определить только по времени прихода ТС\ТС. Ясно, что сначала придет ПРИЧИНА, а потом СЛЕДСТВИЕ. А если что-то где-то задержится!? Поэтому скорость в канале на МЭК-101 нужно выбирать максимальную, и не ниже рекомендованной.......... А все эти "у нас все работает" - лишь отговорки........Понятно, что два устройства соединяться и на скорости 200 Бод, но кому нужна такая РАБОТА!!!! |
||||||
JJL долгожитель Группа: Участники Сообщений: 385 |
Добавлено: 13-11-2010 14:20 | |||||
Ув. vad74 ! После заявленных преимуществ Вашего модема (ФМ, 4800, и др.), следует отметить следующее: - Все это возможно реализовать на стандартном в части АЧХ, ГВЗ, полноты спектра, ограниченном количестве переприемов, низком уровне шумов и прочими стабильными во времени параметрами, заполучить которые в реальной сети связи эл.энергетики крайне сложно, разве что на цифровой системе передачи, но там есть иные, безмодемные способы взаимодействия; - Все это возможно, если и КП и ПУ (обе стороны) оснащены Вашими модемами (т.е. Вашими изделиями), что согласитесь, не всегда реализуемо; - В случае же с ЦППС иного типа (и "хвоста" канала ТЧ) все уходит на ЧМ в те-же 300-600 бод; - Модемы ТМ "прошлого века" (АПТ, АПСТ и др.) обеспечивают заявленную в их ТУ скорость и прыгать выше головы не могут и не должны; - При появлении на объекте цифровых каналов и при работе Ваших изделий с картами первичных мультиплексоров (с RS-портами непосредственно), Ваш интегрированный модем становится физически не нужным, но, в отличии от АПТ, АПСТ и др., его нельзя взять и перенести под другое КП, ну а интерфейсная карта Вашего КП (с RS-портом) становится опять "канальным адаптером". |
||||||
Andrew аксакал Группа: Участники Сообщений: 568 |
Добавлено: 13-11-2010 15:56 | |||||
Для этого есть метки времени, которые присваиваются устройством ТМ. |
Страницы: 1 2 Next>> |
Телемеханика и связь в энергетике / Модемы и протоколы ТМ / ТУ в ТМ |