Pull to refresh

Comments 14

По конкретике — скажите, пожалуйта, что больше интересует, т.к. тема достаточно обширная.
Конкретный опыт применения на больших гетерогенных системах, нюансы. Передача в систему АСУП верхнего уровня.
Так-то понятно, что 101 / 104 — это протокол, который может все на свете в области энергетики, но мало кто ее разрабатывал сам и уже еще меньше тех, кто использовал его хотя бы на упоминаемые вами 20%.

Еще интересует стандарт IEC 61850. Насколько он реально применим в наших энергосистемах, насколько он востребован.
Ок! Про конкретику и нюансы я понял. Попробую смастерить на эту тему отдельный пост. В нем, кстати, постараюсь просто расказать и про внутреннее устройство протокола.

Касательно 61850 — в данный момент я практически ничего про него не знаю. Если встретится какая-нибудь хорошая статейка — дам ссылку.
Ну да, было бы неплохо. Рассмотрение четырех групп команд (информация процессов / системная информация в направлениях контроля, управления). Наиболее часто используемые команды.
Общая схема обмена сообщениями: запрос, подтверждение, сами данные и т.д.
Пример общение на этом проколе какой-нибудь станции контроля заряда аккумуляторных батарей (для примера).
Хорошо, уже начну делать наброски. :-)

P.S.
Я не искал, может быть сразу есть ответ на этот вопрос:
У меня Андроид, планшеты/телефоны. Может есть какой-нибудь софт для работы с хабром? Специально заточенный, типа Вордпрессовского клиента для андроид?
В 104 протоколе крайне печалит размер фрейма с ограничением в 256 байта, доставшееся в наследство от 101, работающего на RS 232 / RS 485. Хотя в 104 могли бы увеличить, ну хотя бы до значений близких к MTU Ethernet.
Ну и да, хотелось бы продолжения с подробностями
Про нюансы и 256 — вообще, во всех (насколько я видел) реализациях 104-ого несколько APDU фреймов могут быть переданы в рамках одного TCP пакета. Так что в этом смысле я не вижу серьезных ограничений. Наоборот, при реализации на основе UDP это позволяет оперативней отслеживать потери пакетов. Хотя, опять же, если честно на UDP видел 104-ый только 1 раз.
Наоборот, при реализации на основе UDP это позволяет оперативней отслеживать потери пакетов.

Как это? Если я верно понимаю, в этом случае, при пропадании одного юдипишного пакета мы потеряем сразу несколько APDU фреймов.
И, да.
Конкретный опыт применения на больших гетерогенных системах, нюансы. Передача в систему АСУП верхнего уровня.

Вот это очень интересует.
Как это?

Верно. Но внутри APDU в 104 протоколе есть механизм проверки доставки последовательности, который позволяет при определенной настройке протокола параметрами k и w и таймаутами t0, t1 и t2 добиваться обязательного моментального подтверждения получения последнего фрейма. Насколько я знаю у стека UDP/IP задержки могут быть меньше засчет моментальной отправки появившейся в нем информации. Но давайте я этот момент получше уточню и раскрою в новой статье.
… опыт применения на больших гетерогенных системах, нюансы… Передача в систему АСУП верхнего уровня.

Понял.
Хотелось бы увидеть комментарии по поводу сравнения новых протоколов МЭК-101/104 с устаревшими RPT80, GRANIT, UTM7, TM512 и по использованию их наравне с ними.
:-) Приятно видеть знакомые названия на несколько отстранненом от этой тематики сайте.

Постараюсь, если вспомню особенности и возможности старых протоколов.

P.S.
Кстати, документация (РП) к ЦППС «SMART-FEP» является одним из хороших источников информации о возможностях данных протоколов. Если что — пишите, попробую достать доку.
Отличная статья! А занимались ли Вы сами реализацией обмена по данному протоколу?
Хотелось бы обратится за консультацией.
Здравствуйте!
Что в Вашем понятии «занимался реализацией обмена»? Софт, к сожалению, не писал. Знаю хороших «писателей». :-) Могу свести.
Настройкой — раньше — постоянно, до тошноты. :-)

P.S.
Прошу прощения, на хабре бываю редко. Можно на почту личную shembel гав гмыл.
Sign up to leave a comment.

Articles