Как организовать асинхронную связь между PLC и SCADA?
Александр Туманов; 1.4.03

Требуется обновлять теги по инициативе PLC, т.е. асинхронно, чтобы не грузить сеть. S7 протокол работает синхронно. Как реализовать такой обмен между S7-400H и WinCC?

Re: Как организовать асинхронную связь между PLC и SCADA?
Чистяков Дмитрий "СеверСталь"; 1.4.03

Сеть и так должна работать не загружаясь. Т.е. из контроллера в WinCC не передаются все тэги, которые прописаны в WinCC. А только те, которые в данный момент отображаются на кадрах визуализации и те, что учавствуют в AlarmLogging для формирования сообщений.

Так, например, у нас сейчас в проекте 26 тыс. тэгов и 1 сервер и 23 клиентских станции. Если бы все тэги передавались из контроллера в сервер WinCC, то проект, просто на просто завис бы. ;-)
А так коммутатор говорит, что загрузка канала лежит в пределах 3-8%. У нас используется CP443-1 в S7-400 (CPU417-4) и CP1613 в сервере.
А вообще, какая у вас сеть. Возможно проблема в канальном или физическом уровне сети.
Re: Как организовать асинхронную связь между PLC и SCADA?
Александр Туманов; 1.4.03

Сеть проектируется. Тем не менее, мне хочется узнать как реализуется именно асинхронная связь (про синхронную я и сам почти всё знаю), причём только S7-400 позволяет её реализовать.

Re: Как организовать асинхронную связь между PLC и SCADA?
Чистяков Дмитрий "СеверСталь"; 2.4.03

Так а в WinCC как раз и так асинхронная связь. Тут народ наоборот жалуется, что она асинхронная. ;-)

http://www.automation-drives.ru/cgi-bin/forum/forum.cgi?dir=1008101932&root=1048671221&year=2003
Re: Как организовать асинхронную связь между PLC и SCADA?
Маслов Дмитрий; 9.4.03

Ну это смотря что подразумевать под асинхронной связью. В первоначальном варианте вопроса требовалось, чтобы теги обновлялись по инициативе контроллера. В WinCC это по умолчанию так и есть, а устанавливается это здесь: правой кнопкой щелкнуть на типе используемого соединения (например, Industrial Ethernet), выбрать System Parameter, в открывшемся диалоге есть флажки "Cycle formation by PLC" и "With trasfer of changes". Только надо учитывать, что это довольно сильно нагружает CPU контроллера и количество циклов обновления тегов у контроллера ограничено. Особенно это касается трехсотых. В рантайме можно посмотреть, сколько циклов опроса тегов формируется контроллером, а сколько операторской станцией. Для этого надо при запущенном WinCC Runtime запустить Simatic->WinCC->Tools->Channel Diagnosis.

В случае использования дублированного контроллера все точно также. Просто надо сконфигурировать соединение в Step'e и использовать его в WinCC как Named Connection.
Re: Как организовать асинхронную связь между PLC и SCADA?
Евгений Трунов; 7.5.03

Разбиение по кадрам визуализации большого числа переменных - это хорошо, конечно. А как быть в случае, если при этом необходима работа TagLogging, к примеру? При необходимости архивации 2.000 тегов на том же сервере разбиение их на 20 кадров по 100 тегов ничего не даст в плане загрузки - TagLogging-то будет инициировать свои запросы к DataManager'у, на все 2.000 штук :-(.


И, кстати, у AlarmLogging'a разве другой принцип? Т.е., имеются analog alarms для тех же 2.000 тегов, к примеру. Для того, чтобы зафиксировать alarm message по любому из них, аларм-логгингу необходимо опрашивать все 2.000, вне зависимости от того, сколько выведено на текущий экран. Или это реализовано как-то по-другому?
Re: Как организовать асинхронную связь между PLC и SCADA?
Чистяков Дмитрий ОАО СеверСталь; 7.5.03

У TagLogging и AlarmLogging действительно другой принцип связи.

Я так понял, Вы хотите сделать на базе WinCC обычный самописец?
Тут стоит отметить, что разбивать ничего не потребуется - сетевые службы сами разобьют посылки на несколько кадров. Только вот тут можно напороться на недостаточность быстродействия канала связи.
С какой частотой Вы предполагаете записывать данные?
А может Вам для этой цели будет удобнее использовать специализированные для этого системы?
Например, IBA. www.iba-germany.com

Re: Как организовать асинхронную связь между PLC и SCADA?
Евгений Трунов; 8.5.03

Под "разбиением на кадры" имелось в виде не разбиение на сетевые пакеты, а разделение на 20 мнемосхем (кадров) по 100 тегов. В теории в каждый момент времени будут запрашиваться только те 100 тегов, м/схема с которыми открыта на этот момент. Это от Graphic-subsystem. А наличие Tag- и Alarm-logging подсистем сводят идею на нет :-(.


А какой может быть иной принцип? Простейший случай - таг-логгингу необходимо архивировать X тегов с интервалом в T секунд. Для этого он должен иметь на момент архивации срез переменных с мгновенными реальными значениями, полученный от DataManager'a. Вне зависимости от того, когда в последний раз они запрашивались другими подсистемами.

Аларм-логгингу, для регистрации отклонения аналогового параметра, необходимо это самое отклонение зафиксировать. Вот тут можно и "по инициативе контроллера", при том, что аналоговые значения меняются в каждом цикле :-).

Самописец - да нет, не совсем. Просто если уж параметр заслужил право отображаться, то он с вероятностью 90% заслужил и право быть сохраненным для потомков, и сигнализировать о своих проблемах.

По поводу быстродействия канала связи - это перекликается с моим же :-) вопросом от 07.05.2003 о примерных расчетах такого быстродействия при проектировании системы.