Компания ДЭП - Форумы

Здравствуйте.

Предполагается на базе ПТК Деконт решить задачу контроля работы небольшого генератора с режимом отдачи энергии в сеть. Посему со стороны сетевой организации идет требование о создании небольшой телемеханики с передачей в их диспетчерскую информации по протоколам МЭК-101/104, точно пока не известно, будет зависеть от каналов связи.

И второй момент по этой теме. Заказчик желает использовать приборы контроля качества электрической энергии, пока идет разговор о приборах Ресурс UF2. Они имеют либо какой-то свой протокол обмена, либо опцию протокол МЭК-101 slave. Кроме того возможно будут какие-то либо измерители, либо модули РЗА, тоже возможно с протоколом МЭК-101.

Прошу уточнить по вопросам:
1. Видел на вашем сайте табличку со списком поддерживаемых протоколов. Там упоминаются МЭК-101/104 в режиме slave, это видимо КП (контролируемый пункт). Но нет ничего про режим мастера. Есть ли возможность использовать оборудование как ПУ МЭК-101/104, то есть как мастера для опроса внешних устройств по этим протоколам?
2. Есть ли документ, так называемый протокол совместимости, в котором описываются детали реализации МЭК?
3. К каким системам телемеханики был опыт у вас или у ваших клиентов подключения вашего оборудования как КП по протоколам МЭК? То есть когда в диспетчерскую данные с контроллера передаются напрямую в какую-то существующую систему, не WinDecont, не OPC, не SCADA-система, а натуральный ОИК.

Заранее спасибо за ответы,
Сергей Кондратьев.

И еще вопросы:
3. Спорадическая передача и общий опрос - оба режима поддерживаются? Есть возможность настройки для спорадики сигналов ТИ величины апертуры, чтобы передавать только при изменении на заданное значение?
4. Временные метки. Поддерживаются ли они вообще, и есть ли возможность передавать спорадику с метками, а общий опрос - без меток? Таково требование диспетчерской.

Прошу уточнить по вопросам:
1. Видел на вашем сайте табличку со списком поддерживаемых протоколов. Там упоминаются МЭК-101/104 в режиме slave, это видимо КП (контролируемый пункт). Но нет ничего про режим мастера. Есть ли возможность использовать оборудование как ПУ МЭК-101/104, то есть как мастера для опроса внешних устройств по этим протоколам?

МЭК-101/104 в режиме Мастер только написали. Через две недели появиться для клиентов.

2. Есть ли документ, так называемый протокол совместимости, в котором описываются детали реализации МЭК?

Будет также через две недели. Поддержины все основные функции.

3. Спорадическая передача и общий опрос - оба режима поддерживаются? Есть возможность настройки для спорадики сигналов ТИ величины апертуры, чтобы передавать только при изменении на заданное значение?

Если вы спрашиваете про МЭК-101/104 в режиме Slave - то поддерживается оба режима. Спорадика ТИ передается по апертуре.

4. Временные метки. Поддерживаются ли они вообще, и есть ли возможность передавать спорадику с метками, а общий опрос - без меток? Таково требование диспетчерской.

Это тоже поддерживается

Спасибо!
Еще остался вопрос по опыту интеграции с чужими системами телемеханики - в какие системы производилась передача информации? Нам предположительно потребуется передача в Систел, в одну диспетчерскую, и в другую еще в какую-то систему, пока нет точной информации.

Наврядли такое решение будет найдено, не встречал пока не одну мультиюзерную скаду , поэтому пишлу её сам ... есть уже определённые сдвиги ... протатип могу показать:)

Faster писал(а):Наврядли такое решение будет найдено, не встречал пока не одну мультиюзерную скаду , поэтому пишлу её сам ... есть уже определённые сдвиги ... протатип могу показать:)

Что за "мультиюзерность" такая?
Для систем телемеханики стандартный функционал - передавать данные от КП одного производителя в ОИК другого, по стандартным протоколам МЭК. В этом в телемеханике гораздо больший порядок, чем в АСУТП с их кривым OPC.

serg_tm писал(а):Что за "мультиюзерность" такая?
Для систем телемеханики стандартный функционал - передавать данные от КП одного производителя в ОИК другого, по стандартным протоколам МЭК. В этом в телемеханике гораздо больший порядок, чем в АСУТП с их кривым OPC.

Что Вы вкладываете в понятие "кривой OPC"?

По-моему, Вы сравниваете несравниваемое: стандарт OPC и МЭКовские протоколы 101/104. Я бы еще понял если бы сказали, например, кривой Modbus и МЭК-870-5-101, а тут OPC и МЭК...

Kirill писал(а):По-моему, Вы сравниваете несравниваемое: стандарт OPC и МЭКовские протоколы 101/104. Я бы еще понял если бы сказали, например, кривой Modbus и МЭК-870-5-101, а тут OPC и МЭК...

Эти механизмы получения данных вполне можно сравнить с точки зрения принципов, на которых они базируются.

Технология OPC работает только в операционках Windows, пригодна только для связи между двумя приложениями. Что при этом делает OPC-сервер, как работает, как надежно функционирует - знает исключительно его разработчик. И если по какой-то причине вдруг возникают проблемы с получение данных, даже при использовании самой хорошей SCADA-системы, в этом запросто может быть виноват OPC-сервер. И OPC-сервер легко может вызвать сбой всего приложения.

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

OPC - это технология для построения локальных систем автоматизации, к тому же полностью привязанная к Windows. Возможно - в новом стандарте OPC UA наконец от этих ограничений избавятся, но это будет еще не скоро.

serg_tm писал(а):Эти механизмы получения данных вполне можно сравнить с точки зрения принципов, на которых они базируются.

Технология OPC работает только в операционках Windows, пригодна только для связи между двумя приложениями. Что при этом делает OPC-сервер, как работает, как надежно функционирует - знает исключительно его разработчик. И если по какой-то причине вдруг возникают проблемы с получение данных, даже при использовании самой хорошей SCADA-системы, в этом запросто может быть виноват OPC-сервер. И OPC-сервер легко может вызвать сбой всего приложения.

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

OPC - это технология для построения локальных систем автоматизации, к тому же полностью привязанная к Windows. Возможно - в новом стандарте OPC UA наконец от этих ограничений избавятся, но это будет еще не скоро.

Уровень функционирования и задачи у OPC и МЭК-101/104 совершенно разные, и сравнивать их некорректно. Если рассмотреть пирамиду автоматизации, то можно увидеть что МЭК-101/104 (вместе с Modbus, DNP3 и т.д.) находиться на более нижнем уровне чем OPC. Конечно же можно обойтись без OPC и работать напрямую с коммуникационным портами по соответствующему протоколу и линии связи, но при этом говорить "МЭК-101/104 лучше OPC" это все равно что сказать "танк лучше автомобиля": где хочу там и еду, броня, асфальтированная дорога не нужна, да еще и стрелять умеет (сравнение корявое, но мысль надеюсь понятна).

А поводу надежности функционирования: никто ни отчего не защищен. Ошибки бывают везде. Разработчик предоставляет гарантии того что программный продукт соответствует спецификации, для этого OPC Foundation проводит тестирование продуктов различных разработчиков и публикует результаты у себя на сайте (Вот например результаты тестирования продукта: http://www.opcfoundation.org/Products/ProductDetails.aspx?CM=1&RI=8865&CU=4)

Kirill писал(а):Если рассмотреть пирамиду автоматизации, то можно увидеть что МЭК-101/104 (вместе с Modbus, DNP3 и т.д.) находиться на более нижнем уровне чем OPC. Конечно же можно обойтись без OPC и работать напрямую с коммуникационным портами по соответствующему протоколу и линии связи, но при этом говорить "МЭК-101/104 лучше OPC" это все равно что сказать "танк лучше автомобиля": где хочу там и еду, броня, асфальтированная дорога не нужна, да еще и стрелять умеет (сравнение корявое, но мысль надеюсь понятна).

Мысль конечно понятна. Но данное образное представление, и Ваши суждения об OPC односторонни, и мне наиболее напоминают образ мышления разработчиков, программистов. Это как раз вы смотрите - а можно ли сравнивать OPC и МЭК? Да конечно нет, как можно, это же совершенно разные вещи в принципе! Пирамида автоматизации, и все такое...

А кто придумал вообще эту пирамиду? Глупые картинки из рекламных буклетов разных фирм, в основном занимающихся SCADA и АСУТП. Посмотрите рекламу кого нибудь типа Сименса, решения для энергетики - нет там никакой пирамиды, и OPC упоминается исключительно для задач межпрограммной интеграции со сторонними системами.

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

Но это все лирика. Суровая правда жизни такова, что в системах телемеханики практически нет OPC, это и практика, и требования. И если где-то OPC встречается - то исключительно либо на самом верхнем уровне, либо в локальных системах АСУТП отдельных подстанций, что обычно вызвано выбором в качестве ОИК какой нибудь SCADA.

serg_tm писал(а):Но это все лирика. Суровая правда жизни такова, что в системах телемеханики практически нет OPC, это и практика, и требования. И если где-то OPC встречается - то исключительно либо на самом верхнем уровне, либо в локальных системах АСУТП отдельных подстанций, что обычно вызвано выбором в качестве ОИК какой нибудь SCADA.

Ну так, а я Вам о чем говорю? OPC - это верхний уровень, МЭК 101/104 внизу.
И если подход без использования OPC Вам кажется более простым/надежным/быстрым/удобным/привычным, то это не значит что OPC хуже чем МЭК-104/104.
А про пирамиду автомазации Вы зря так. Если рассматривать конкретные решения то про пирамиду можно и забыть, но для полного понимания картины и умения видеть систему с разных уровней абстракции некая многослойная структура (в данном случае пирамида) необходима.
Необходимость 7-уровневой модели OSI вы отрицать же не будете? Если в МЭК 870-5-101-2001 описаны 3 уровня: физический, канальный, прикладной, то это же не значит что остальных 4-х уровней вообще не существует, и вся эта 7-уровневая модель глупая и нафиг никому не нужная? И сравнивать протокол сетевого уровня с протоколом транспортного уровня тоже не будете, потому что для разных целей они предназначены.

Kirill писал(а):И если подход без использования OPC Вам кажется более простым/надежным/быстрым/удобным/привычным, то это не значит что OPC хуже чем МЭК-104/104.

Для меня - как раз и означает что хуже. Потому что я рассуждаю об OPC не виртуально, не вообще, не "за идею", а применительно к конкретным проектам автоматизации, которыми занимаюсь. В наших проектах нам для интеграции ПО верхнего уровня и оборудования объектов никакой OPC видеть не хочется. Это во первых требование наших заказчиков - электрических сетей, во вторых наше, наработанное практикой.

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

Если вдруг решитесь продолжить обсуждение дальше, то определитесь вначале что же для вас есть OPC? Не то, на каком уровне автоматизации он находится, а какие конкретно задачи он решает, или должен решать. Потому что я говорю только о конкретной функциональности - связь между контроллером и верхним уровнем. И для выполнения такой функциональности считаю OPC плохим выбором.

serg_tm писал(а):Для меня - как раз и означает что хуже. Потому что я рассуждаю об OPC не виртуально, не вообще, не "за идею", а применительно к конкретным проектам автоматизации, которыми занимаюсь. В наших проектах нам для интеграции ПО верхнего уровня и оборудования объектов никакой OPC видеть не хочется. Это во первых требование наших заказчиков - электрических сетей, во вторых наше, наработанное практикой.

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

Если вдруг решитесь продолжить обсуждение дальше, то определитесь вначале что же для вас есть OPC? Не то, на каком уровне автоматизации он находится, а какие конкретно задачи он решает, или должен решать. Потому что я говорю только о конкретной функциональности - связь между контроллером и верхним уровнем. И для выполнения такой функциональности считаю OPC плохим выбором.

Ваше право считать что хуже что лучше для Вас и переубеждать в чем-то не пытался. Holy war не раздуваю, просто изначально мы друг друга не поняли: вы формулируете свое мнение как "МЭК-101/104 лучше OPC", хотя на самом деле хотите сказать "Подход с использованием OPC не всегда удобен/надежен по сравнению с подходом, когда SCADA напрямую работает с контроллером по определенному протоколу (это может быть и МЭК-101/104 и ModBus или вообще какой-то свой)".

serg_tm, собстенно я не за ДЕП я скорее всего воббще не на барикадах...

твои рассуждения про телемехнику БРЕД ,Ю я уже 3 года её делаю . имею авторский проект , если ты мне хочешь на пуэ дать сылку илитамна госты потелемеханике, погляди в каких годах писали их ...

Длаее твоя фраза типа ОПЦ и пирамида , ты реально не вкруиваешь этосовсем разные вещи МодБас и ОПЦ , неастолько разные что драйвер модбаса полнофункциональный весит 1.77кб да да почти два килобайта , а самый бзовы ОПЦ клиент весит 300кб ... сравни и подумай ...

МОД БАС и МЭК это протоколы ине имеют нечегообщего с ОПЦ , например моя телемеханика работает через сеть Интернет, это даёт обсальтную возможность к расширению и местоположению...

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

serg_tm писал(а):

Faster писал(а):Наврядли такое решение будет найдено, не встречал пока не одну мультиюзерную скаду , поэтому пишлу её сам ... есть уже определённые сдвиги ... протатип могу показать:)

Что за "мультиюзерность" такая?
Для систем телемеханики стандартный функционал - передавать данные от КП одного производителя в ОИК другого, по стандартным протоколам МЭК. В этом в телемеханике гораздо больший порядок, чем в АСУТП с их кривым OPC.

Всегда убивала привязка к протоколу МЭК ... ыыы
вот тебе примерный вид телемеханики моей:

КП ..... КП
перадают всё
на сервер
сервер обслуживает OPC базуданных, архивы и прочие прелести
к нему подключаются клиенты, все процессы протикают на сервере , та естьползователиправа доступа ипрочее
клиенты подключаются по моемуц протоколу по TCP/IP шифрование и прочая лага

колво лиентов не ограничено вот это и есть мультиюзерная

serg_tm писал(а):

Kirill писал(а):По-моему, Вы сравниваете несравниваемое: стандарт OPC и МЭКовские протоколы 101/104. Я бы еще понял если бы сказали, например, кривой Modbus и МЭК-870-5-101, а тут OPC и МЭК...

Эти механизмы получения данных вполне можно сравнить с точки зрения принципов, на которых они базируются.

Технология OPC работает только в операционках Windows, пригодна только для связи между двумя приложениями. Что при этом делает OPC-сервер, как работает, как надежно функционирует - знает исключительно его разработчик. И если по какой-то причине вдруг возникают проблемы с получение данных, даже при использовании самой хорошей SCADA-системы, в этом запросто может быть виноват OPC-сервер. И OPC-сервер легко может вызвать сбой всего приложения.

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

OPC - это технология для построения локальных систем автоматизации, к тому же полностью привязанная к Windows. Возможно - в новом стандарте OPC UA наконец от этих ограничений избавятся, но это будет еще не скоро.

Слушай ты где такое вычитал ?
OPC это стандарт прмышленного представления данных , тоесть ка кработает устройство не знает програмист скады но у него естьстандарт по которому он может взаиможествовать ...

как ты умудрился сравнить сетевой протокол с OPC ?
Это как сравниать железную дорогу авто мастерской

Блин как спамер стал .....

В общем скажи в какой КОНТОРЕ ты работаешь , мыло кину чтоб тя уволили нафиг после таких рассуждений ...


баста топик больше не читаю... у нас уже пятеро инжинеров под столом седят.

Фастер - за базаром следи, слишком нагло себя ведешь. Здесь не кружок для общения мальчиков по понятиям.
По твои многочисленным постам отлично видно, что ты программист до мозга костей, 3 года делаешь свою телемеханику - я просто поражен, ты почти профи. А большие подстанции были - 100 кВ и больше? Или так, по мелочи все - городские ТПшки? Есть опыт организации передачи данных с КП в диспетчерскую верхнего уровня - электрические сети? А передача системному оператору?

Описание твоей разработки про "мультиюзерность" - просто обзавидоваться можно! А не в курсе, что для любых нормальных SCADA-систем клиент-серверная архитектура, пользователи, разделение прав - это вообще-то стандартный функционал, о котором даже заявлять как-то смысла нет.

ДЭПу - вам не стыдно терпеть Фастера у себя на форуме?
Я получил ответы на свои вопросы, спасибо. Прошу удалить данную тему, дабы избежать ее дальнейшего развития не по существу вопроса, или закрыть на редактирование.

принашу конечно извинения за грубость , это видимо про цитату о матчасти, но увы не могу забрать свои слова обратно учить её надо.

насчёт клиент серверных насчитали по пальцам и большинство корявые... не разграничевающие объектный доступ ..

насчёт больших ТП , смешно слышать рзницы нет щлкать 0.4 кв или на 500кв , лишь исполнительный механизм разный ...

а вот между МОД БАС и ОПЦ разница есть ... так что мне стыдиться нечего ...

кстати раскажите мен общие принципы между модбасом и ОПЦ , я очень хочу просветиться в этом направлении ... и ещё что вы имели в виду под системным оператором , лично у меня 4 сетевых района и городская электросеть ... с нового года будем залазить на подстанции с большим напряжением, там просто глухо с финансированием, а я не альтруист.

Faster писал(а):принашу конечно извинения за грубость, это видимо про цитату о матчасти, но увы не могу забрать свои слова обратно учить её надо.

Учим матчасть.
Data Access Custom Interface Standard, Version 2.05A, June 28 2002.
Раздел 2.2, Where OPC Fits, страница за номером 3, Figure 2-4 - OPC Client/Server Relationship.
Черным по белому нарисовано месторасположение SCADA-системы - снизу от OPC-сервера (по картинке справа), а некое отвлеченное приложение Application - выше OPC-сервера (по картинке - слева).
Там же еще есть Physical I/O - видимо что-то любое, подключаемое минуя SCADA-систему.

Еще раз четко выскажу свою точку зрения. Интерфейс OPC создавался для организации межпрограммного взаимодействия, для передачи технологических данных между программами, в том числе как вариант получения данных от неких Physical I/O через программу со стандартным интерфейсом. Но никак не для замены кучи всяких протоколов между контроллерами и SCADA. Даже в настоящее время большая часть SCADA-систем для связи с контроллерами используют протоколы, и OPC предназначен для интеграции - с железом, которое данная SCADA не знает, с другими приложениями.

Вот в отношении использования интерфейса OPC против протоколов МЭК в части коммуникации между SCADA и контроллером я и имею сказать что-то против. Причем говорю не как программист, рассматриваю 7-ми уровневую модель ISO, а как инженер по автоматизации. Если я использую SCADA-систему, которая имеет поддержку МЭК, то я легко могу подключить любое железо, работающее по этому протоколу, к существующему ОИК, по любому каналу связи.

В последнее время конечно стали появляться решения, когда в качестве ОИК используется SCADA, данные в нее передаются по OPC, а выдает их OPC-сервер из МЭК-101/104. Подозреваю, что такие решения возникают у интеграторов, которые ранее работали в АСУТП, и нельзя сказать, что оно правильное.

Благодаря уже большому числу наработок по OPC только ленивый не делат свою SCADA-систему, с доступом по OPC, без какой либо привязки к реальному железу. Это хорошо, мальчикам-разработчикам есть на чем поучится, потренироваться. В общем такое развитие нормально, популяризуются технологии АСУТП, упрощаются, становятся доступны. Но это не значит, что они также сплошь и рядом используются при построении больших распределенных систем.

Faster писал(а):насчёт больших ТП , смешно слышать рзницы нет щлкать 0.4 кв или на 500кв , лишь исполнительный механизм разный

Разницы нет только в теории, также как между жигулями и мерседесом (банально сравнение, но вот так) - кузов на 4-х колесах, с двигателем. Разница в деталях исполнения. Извините - расписывать детали времени нет.

Faster писал(а):кстати раскажите мен общие принципы между модбасом и ОПЦ , я очень хочу просветиться в этом направлении ... и ещё что вы имели в виду под системным оператором

Я не говорил про Модбас. МЭК и Модбас совсем разные протоколы, схожесть можно найти разве что в адресации параметров - тут не строки, как в OPC, а целые числа. Ну право слово, здесь тоже можно писать много, вкратце не получится, а на много времени нет. Гляньте в сети, информации достаточно.

Сравнить OPC и МЭК можно с точки зрения организации доступа к контроллеру. В OPC мы работаем с некоей программой, прослойкой между контроллером и SCADA-системой. В протоколах МЭК имеем дело с бинарным протоколом, но в формате его бинарности все очень четко оговорено. Форматы передаваемых данных могут быть многих типов, конечно строк и массивов нет, но это не надо. Данные могут передаваться с временными метками, и без, есть приоритеты данных, есть спорадическая передача по инициативе контроллера.

Кроме того протоколы МЭК свободно используются и для ретрансляции технологических данных между серверами, различными уровнями диспетчерских, причем в сколь угодно сложных сетевых структурах, а не только в рамках сети Windows/DCOМ. Для работы протокола МЭК-101 достаточно канала 9600 бод, а можно и меньше. Я знаю, есть решения типа SplitOPC, но это уже костыль, когда приходится иметь дело с OPC по необходимости.

С точки зрения масштабируемости, кол-ва ресурсов, необходимых для работы технологий OPC и МЭК подумайте сами - что более ресурсоемко, оперировать адресом в виде длинной строки, или несколькими байтами МЭК-адреса параметра? А системы телемеханики оперируют объемами информации в десятки и сотни тысяч параметров.

Реализация МЭК-101/104 не такая уж тривиальная, особенно в достаточно общем виде, а не маленького кусочка. На мой взгляд - написать OPC-сервер проще.

Системный оператор:
http://www.so-cdu.ru/
Его интересуют объекты от 220 кВ и выше.

В заключение. Ребята, изучайте МЭК, его надо как минимум знать, понимать принципы функционирования. Без этого пути в автоматизацию больших подстанций нет. А в последнее время я все чаще встречаюсь с ситуацией, когда в технических требованиях на телемеханику объектов 6-10 кВ тоже прописывается МЭК. Само оборудование может быть любым, главное чтобы данные выдавала в МЭК.

Извинения приняты.
Удачи!

Про оператора , хорошо тока далеко...

насчёт вас мне кажется что у вас просто в голове немного перемешаны разые понятия, ещё раз повторяю :
ОПЦ это некая среда описывающая уникальный и неизменный интерфейс взаимодействия , чего с чем не описано. но задумывалось как железо с софтом

Протокол МЭК, МОДБАС и прочие -это протоколы, такие же как IPX/SPX , TCP/IP ну и прочие ...

среда это то где протокол работает .. OPC сервер в общем с железом не обязан обющаться он может иметь несколько драйверов и общаться с разным железом и прочей прелестью...

но это не суть . сама суть заключается в том что производителю контроллеров надо лишь написать OPC сервер (что не так сложно ) чтобы все смогли юзать их контроллер , а производители ПО не обязаны замарачиваться и понимать как там думает этот долбанный контроллер, а как тот ? они знают как работает опц ...

собственно как вывод ОПЦ это избыточная прокладка, универсальный интерфейс. как более сложный пример можно привести универсальный драйвер звука в винде , в него выводят звук все и так как хотя хоть в 10 каналов а он уже разбирается с тем что может звучка и выводит так как получится ...


надеюсь всё таки ты поймёшь что ОПЦ это прокладка что и показано на том рисунке что можно и без него !

Вот те краткая мат часть...

Надеюсь что ты понимаешь что меня не стыдно тут держать

кстати и уж извени не смог весь твой топик прочитать... ломает вечно ... ты так многотам налил

а насчёт всяких там 6кв 110 , ты так и не понял что разница лишь в исполнительном механизме !!! и мне и моей скаде и всей моей телемеханики глубоко до печки чем она счёлкает !!!

в какой теори ты разницу нашол я не понимаю ? ну подключал я реклоузер на 220кв (прости если не правельно наисал) работает как будет финансирование буду и их подключать ....


в общем меж нами разница в том что я ипрограмер и инжинер и отвёрткой крутить умею, а следовательно имею больший обзор проблемы и лучше вижу приемущества.

кстати когда искал с чем есть ДЭП в своё время находил (не помню названия) интересный OPC сервачёк у него был очень большой переченьинтерфейсов от RS-232 до TCP/IP modbus ну и ещё больший перечень протоколов исобственно МЭК там был поройся в нете он не так дорого стоил порядко 10к евро. зато вообще забудешь проблеу с тем какой протокол на железе ...

Faster писал(а):ОПЦ это некая среда описывающая уникальный и неизменный интерфейс взаимодействия , чего с чем не описано. но задумывалось как железо с софтом

Мне кажется я довольно внятно показал, для чего задумывался OPC. Никакой конкретной ориентации на связь с железом не было, все было очень универсально - и для связки между собой программ, и для подключения неизвестных девайсов. В то время, когда разрабатывался OPC, SCADA-системы рассматривались как нижний уровень автоматизации, они работали напрямую с железом, и от них надо было унифицировать получение данных. А благодаря стараниям Мелкомягких еще и умудрились базировать OPC на технологии COM/DCOM, привязанную только к Винде.

Faster писал(а):сама суть заключается в том что производителю контроллеров надо лишь написать OPC сервер (что не так сложно ) чтобы все смогли юзать их контроллер

В МЭКе суть в том, что производителю телемеханики всего лишь надо поддерживать в своем КП протокол МЭК (что не сложнее написания OPC-сервера), и тогда это КП может быть легко интегрировано в любую систему телемеханику, под любой программной платформой, на любых каналах связи.

Faster писал(а):надеюсь всё таки ты поймёшь что ОПЦ это прокладка что и показано на том рисунке что можно и без него !

Вот именно что прокладка. И проекты автоматизации легко могут строится без этой прокладки, и в этом есть серьезные преимущества. А в телемеханике они и строятся без OPC, и тенденции использования здесь OPC идут от разброда и шатания в стане телемеханизации распредсетей и городских сетей, отсутствия регламентных документов, попыток различных интеграторов и отдельных специалистов перенести на данную область свой опыт автоматизации в АСУТП, ЖКХ и пр.

Faster писал(а):а насчёт всяких там 6кв 110 , ты так и не понял что разница лишь в исполнительном механизме !!! и мне и моей скаде и всей моей телемеханики глубоко до печки чем она счёлкает !!!

Вашей SCADA, если таковая и есть, наверное и без разницы. Потому что за нее всю грязную (и основную!) работу делает OPC-сервер связи с КП. Без него SCADA слепа, глуха и нема. Раньше такие программы называли не SCADA, а HMI, или MMI.

Программных продуктов, базирующихся целиком на работе с данными только по OPC не так много. Из тех, кого я знаю - это Genesis, и MasterSCADA, можно еще новенького DataRate упомянуть. При чем в MasterSCADA только первоначально был механизм исключительно OPC, а сейчас уже своя интегрированная среда программирования контроллеров. А вот SCADA-систем, имеющих прямую поддержку протоколов МЭК, а в Америке еще и DNP3 - много.

Faster писал(а):в общем меж нами разница в том что я ипрограмер и инжинер и отвёрткой крутить умею, а следовательно имею больший обзор проблемы и лучше вижу приемущества.

Я своего первого OPC-клиента написал году так в 2000, это было уже почти на закате моей программерской деятельности. И попрограммировать пришлось, и ручками поработать, все было. Сейчас занимаюсь проектами, внедрением. Поэтому мне понятна и оптимистическая точка зрения программистов, и скептическая внедренцев.

Я вижу всё таки что для вас протокол и интерфейс ка кбы одно и тоже ...

повторю в краце сказад должна нетока знать МЭК нои варианты сртедипрочее , и под каждое писать и кадое продумывать , кукда как проще самому произвдителю определиться с тем где и что он передаёт ... а СКАДА должна иметьт одно универсальное решенеи и оно ОПЦ


далле СКАДА будет слепа:
обрезать провод , забить канал связи
убить опц сервер
оторвать шнур питания от компьютера

в общем всё что угодно ...

Сложно понять ваши плохо сформулированные и написанные мысли. Я все таки человек старой формации и стараюсь, по возможности, придерживаться правил русского языка. Хотя понятно, что в современном интернет-сообществе они отмирают.

А по существу замечание вот такое. Знакомились когда нибудь с документом Standard for SCADA and Automation Systems? По этим словам поиском в сети найдете его легко. Найдите, уж коли занимаетесь писательством своей SCADA-системы, проглядите его мельком, оцените - как там рассматривается технолология OPC, и как - коммуникационные протоколы.

Да знакомился давно ...

всётаки речь не о том что я пишу а о том как вы понимаете протокол и OPC а вы его с точки зрения любого мана понимаете не верно...


на этом разговор окончен ... простоуже сорить в топикенадоело ...


я не дурак но промолчу ...

Похоже вы так и не смогли понять мою мысль, что я сравниваю протоколы МЭК и интерфейс OPC не чистой идеологической точки зрения, где и на каком уровне каждый из них находится - эта сторона мне безразлична.

Принцип сравнения - с точки зрения организации доступа SCADA-системы к контроллерам. В этом отношении протоколы МЭК могут быть также универсальны, как и интерфейс OPC. И SCADA-система вполне может быть построена на механизме доступа к внешним данным через МЭК и другие подобные протоколы, имея при этом значительные преимущества перед построением на базе OPC.

Я тоже заканчиваю флеймить, свободное время подошло к концу.

С идеалогической точки зреня мне не ка кне удаётся понять как можно сравнивать кролика и экскаватор ?

Только потому что они обароют ямки ? (способствуют доставки данных)

не извени, такой уровень аьбстракции даже для меня очень высок ...

Faster писал(а):С идеалогической точки зреня мне не ка кне удаётся понять как можно сравнивать кролика и экскаватор ?

Больше никакие сравнения в голову не приходят?
А как насчет автомобиля, поезда, парохода, самолета? Как их можно сравнить идеологически? А вот функционально- с точки зрения доставки грузов - очень даже запросто.

закон абстракции : сравнить можно всё что угодно, только ен всегда можно чтото при этом получить

Faster писал(а):а насчёт всяких там 6кв 110 , ты так и не понял что разница лишь в исполнительном механизме !!! и мне и моей скаде и всей моей телемеханики глубоко до печки чем она счёлкает !!!

в какой теори ты разницу нашол я не понимаю ? ну подключал я реклоузер на 220кв (прости если не правельно наисал) работает как будет финансирование буду и их подключать ....

Прежде чем начать щелкать выключателями, надо будет пройти аттестацию комплекса в ФСК ЕЭС. Сильно не уверен, что у вас хватит на это желания, времени и средств. Но желаю успеха