[Николай]

Евгений Кузнецов 02 окт 2009, 09:49

Добрый день!
Есть вопрос для знающих людей по FF. Перечитал всю (скорее всего) свободно доступную литературу,
интуитивно чувствую, что очень интересная и перспективная технология, но вот посмотреть или
‘пощупать’ пока не удалось. Хотел спросить, а как FF в жизни? Чем он упрощает прикладное ПО?
Дмитрий в нескольких ветках писал, что наладка выполняется значительно быстрее. А за счет чего?
Спасибо.
Евгений.

andrmur 02 окт 2009, 16:50

Евгений,
Лучше всего Вам съездить на завод, где FF работает и посмотреть своими глазами, поговорить с инженерами на месте, и пощупать руками.
Или ездить на выставки, где будет рабочее демо, например, в Киеве на нефтегазе.
А если кратко, то FF не упрощает, а немного усложняет ПО, но зато устраняет ряд механических операций и за этот счет ускоряет проведение работ.
Для применения FF квалификация КИПовцев должна быть выше, чем для простого КИП, поскольку все традиционные операции (настройка, калибровка) делаются уже не отверткой, а через компьютер.
Проектанты должны знать технологию и оборудование, чтобы правильно спланировать и проложить кабели.
АСУТПшники должны фактически влезать в мозги датчикам и позиционерам, поскольку функциональные блоки теперь работают не в контроллере, а в самих приборах.

Евгений Кузнецов 03 окт 2009, 12:34

Андрей,
спасибо за ответ. Я бы съездил, если бы в наших широтах была такая инсталляция.
У наиболее распространенных у нас Эмерсон и Ханивел, насколько я знаю, нет внедрений
проектов с FF.
Почему-то представляется, что ни проектантам, ни киповцам эта технология
особых трудностей не создаст. Проектанту по большому счету все равно какой кабель
вести от шкафа управления до кроссов и полевых приборов, а киповцы и сейчас приборы настраивают
или коммуникаторами, или PACTWare, или софтом от производителя. А вот эксплуатации
АСУТП и программистам мировоззрение придется поменять. Вернее не поменять, а расширить.
Обратил внимание, что кроме известных брендов, появилось достаточное кол-во компаний-поставщиков
пакетов конфигурирования сетевых РСУ на базе FF. Ведь при наличии качественного КИПа от
известных и не очень производителей уже нет необходимости разрабатывать ПО и железо
контроллеров, а достаточно обеспечить компьютерный интерфейс параметрирования и опроса
шины с приборами. А уж приборы сами справятся с генерированием авайрийных признаков,
передачей друг другу уставок на регулирование и с собственно регулированием.
Это, конечно, упрощенное представление о технологии FF, но, думаю, в принципе верное и указывает на
то, что эта технология на пользовательском уровне достаточно проста.
Андрей, а у Вас (имею в виду российский Роквелл) есть внедрения на FF?
Евгений

Jackson 05 окт 2009, 10:49

Дмитрий Милосердов писал(а):Я сейчас приехал с Emerson Global Exchange, где они представляли все свои новые технологии.

Вставлю оффтопиком.
А я сейчас приехал с достраивающегося корабля спецназначения (то бишь военного), где ген.проектант – не буду пока его называть – ни сном ни духом не догадывается о существовании например RS-485 ModBUS, CAN J1939, Ethernet и всего остального, про FF я вообще молчу. По кораблю гуляют адского размера кабельные трассы, всё передаётся либо 4-20 мА либо сухими контактами, стоят огромные шкафы набитые модулями ВВ контроллеров и релюхами под завязку, горы аналог-аналоговых преобразователей… Это тихий ужас! Бедные настройщики к каждому датчику и по каждому кабелю от начала до конца должны проползти по всему кораблю….
Я в шоке! И ведь находят вояки в условиях своей тесноты место для этих груд релюх и пачек кабелей….. Я не говорю про то сколько это всё стОит!

andrmur 05 окт 2009, 11:53

Евгений,
Действительно, на Украине мне неизвестна ни одна инсталляция FF.
Так что смотреть живьем можно в России или в Европе.
У Роквелл в России пока нет действующих систем с FF, но обязательно будут – мы сейчас прорабатываем один проект и на столах у нас живописно разбросаны приборы FF и подключены к системе.
Что касается мнения о ненужности контроллеров, то я думаю, что такое светлое будущее наступит еще не скоро.
Все-таки приборы пока что умеют делать немногое:
– функциональные блоки AI с масштабированием сигнала для датчиков
– AO для клапанов
– DI/DO для интерфейсов с традиционными сигнализаторами и клапанами-отсекателями
– ПИД регуляторы
– Линеаризаторы сигналов
Чуть более сложные алгоритмы приходится делать в контроллере.
Регистрировать события и алармы, накапливать тренды также пока что приходится в контроллере – у датчиков пока нет еще объема памяти.
Но когда-нибудь лет через 10 это появится, и возможности датчиков выйдут на уровень контроллеров…

Евгений Кузнецов 05 окт 2009, 12:11

Дмитрий,
а есть у Вас какие-то презентации с этого мероприятия? Напр., в части сравнения М-серии и новой S-серии.
В инете доступны только PDS-ы на 11-ю версию DeltaV (или я плохо искал).
Кстати, а правда что HW для DeltaV выпускал MTL? А кто сейчас? МТЛ уже под GEFanuc-ом.
По теме – будет возможность хоть-где посмотреть, обязательно это сделаю. Но из Вашего опыта личных внедрений:
верны ли мои предположения в ответе Андрею?
Евгений

andrmur 05 окт 2009, 12:20

MTL никогда не входил и сейчас не входит в GE.
MTL Instruments является подразделением Cooper Crouse-Hinds.
MTL производит только искробезопасные модули в/в для DeltaV, которые, впрочем, не шибко продаются.
Все железо DeltaV производится исключительно на стороне, но это не значит, что такое же можно купить у кого-то другого — Эмерсон остается эксклюзивным владельцем прав на конструкцию и разработанные принципиальные схемы.

Евгений Кузнецов 05 окт 2009, 12:48

Андрей,
я неправильно выразился – продукт MOST 8000 продан МТЛ-ем Фануку, но в общем понятно.
Спасибо за ответ.

Евгений Кузнецов 05 окт 2009, 13:12

Дмитрий,
еще с пристрастием и не спрашивал ,)
Я больше общался с ними по продуктам КИП, а по системам как-то не приходилось.
Человек из нашего Эмерсона пообещал поделиться всей, какая есть, информация,
но, в принципе, информация и так есть в сети. Для меня более важны были личные
ощущения о разных этапах проекта тех людей, кто делал такие системы своими руками.
А кто остановил свой выбор на ФФ для Ванкорского м/р? И чем в данном случае
руководствовались (ценовой фактор, новизна, невозможность или затрудненность реализации
по обычной схеме)?
Евгений.

Евгений Кузнецов 05 окт 2009, 14:19

Понятно. Уверен, что повода усомниться в правильности выбора не будет.
А еще вопрос или подходит ФФ для задач циклической логики? Напр., 10 конвейеров
работающих последовательно друг на друга, остановился один – все перед ним
должны остановиться и в интерфейсе оператора должны появиться сообщения о том,
что один остановился аварийно по причине такой-то, а остальные сблокированно от
останова следующего за ним. Такие функциональные блоки (сблокированных пусков
маршрутов, сблокированных остановов, выработка причин остановки), скорее всего,
в существующих ФФ устройствах отсутствуют. Такая функциональность должна
быть реализована в стратегиях контроллера? Целесообразно ли использовать в таком
случае дискретный ввод/вывод как ФФ-УСО?

Евгений Кузнецов 05 окт 2009, 16:22

Дмитрий,
а ДельтаВи сама по себе подойдет для быстрых циклических задач?
Вопрос возник из-за того, что у ДельтаВи минимальный цикл выполнения – 100 мсек,
а для ПЛК цикл выполнения программы в 100 мсек – чаще всего трагедия.
Евгений

Евгений Кузнецов 05 окт 2009, 17:39

Дмитрий,
сейчас задачи как таковой нет, это больше для понимания реальных возможностей РСУ.
Но предположим: в цепочке производства кокса есть углеподготовительный цех, который
принимает угли, хранит, смешивает по нужной рецептуре, измельчает и транспортирует
смешанную шихту в коксовый цех. В коксовом цехе шихта спекается в кокс в батареях.
При спекании, кроме кокса, образуется коксовый газ, из которого извлекаются механические
и химические соединения в цехе улавливания.
Углеподготовительный цех (за исключением приготовления шихты) – это в чистом виде
дискретная логика, растянутая на несколько км: последовательные цепочки (маршруты)
механизмов, вдоль которых располагаются щитовые с пусковой аппаратурой этих самых механизмов.
Дискретных входов – 1200, выходов – 250. Задача системы управления углеподготовкой – управление цепочками
механизмов, и определение причины аварийного останова и причины невозможности запуска
(технологическая – концевик, аварийная кнопка и т.д., или электрическая – тепловая защита,
оперативное питание, силовое питание и т.д.). Каждому механизму соответствует от 5 до 12 дискретных
входов, в т.ч. и быстрые, напр., импульсы от датчика скорости (скажем, 10 Гц). Важно:
– правильный запуск маршрута,
– правильный останов маршрута,
– правильное определение причины аварийного останова или неготовности к запуску, т.к. на основании
этого принимаются технологические или электрические меры. Неправильно
определил – потерял время на простое механизмов, недогрузил коксовую батарею и т.д.
Цех улавливания – это в чистом виде непрерывный процесс (контроль и регулирование уровней,
температур, расходов). В этом цехе точно подойдет РСУ, напр. ДельтаВи.
А для углеподготовительного подойдет РСУ, напр.ДельтаВи? Правильно запустить и остановить последовательность
наверняка сможет, определить неготовность к запуску – тоже. А вот детектировать причину останова?
Некоторые сигналы реально могут быть в ‘1’ менее 1 секунды. Может быть модули SOE помогут?
Поскольку эти цеха внутри одного производства и обслуживаются одними людьми, то логично свести
разношерстность оборудования к минимуму и строить все на одной платформе. Вот мы и построили на ПЛК+СКАДА.
Хотел бы еще понять для себя насколько всеприменимы системы класса РСУ и подошла бы ДельтаВи
(или другая) для задачи управления углеподготовкой.
Евгений

Евгений Кузнецов 05 окт 2009, 18:22

Дмитрий,
а какие у ДВ есть контроллеры? Я знаю только МД, МД+, вот теперь еще SD, SX.
Вот для меня загадка, а если всем стратегиям, которые только возможны для объекта,
назначить цикл выполнения 100 мсек? Не станет ли плохо процессору? Есть ли какая-то
методика расчета загрузки процессора исходя из предполагаемого кол-ва и типов
стратегий и цикла их выполнения?
Интуитивно чувствую, что потянут. Да и реализация ввода быстрых сигналов может
быть разной, напр., интеллектуальный датчик скорости, который даст сухой контакт
аварии вместо подсчета импульсов в программе процессора и т.д.
А вот относительно стоимости – прайс-листа Эмерсона у меня нет, но эксплуатация
одного из предприятий, где мы работали, утверждала, что стоимость собственно железа
вполне сопоставима с стоимостью ПЛК, особенно на фоне высокого евро. А вот лицензии
на разработку и рантайм стоят очень больших денег.
П.С. вполне возможно, что если бы была инсталляция этой самой ДВ, то части бы вопросов
не возникло. Но наш Эмерсон немного зашифрованный и не раздает налево и направо
бесценный софт. Хотя, может это и правильно…

Евгений Кузнецов 06 окт 2009, 11:27

Дмитрий,
благодарю за ответы. А кроме ДВ у Вас применяются другие РСУ?
Если да и не затруднит, то интересно было бы услышать вкратце
или можно вывести критерии лучше/хуже в техническом и финансовом
плане для РСУ разных производителей. Хотя, если скидки для Вас сравнимы
со стоимостью системы, то наверное тяжело оценить финансовый аспект ,)

andrmur 06 окт 2009, 13:38

Евгений Кузнецов писал(а): а ДельтаВи сама по себе подойдет для быстрых циклических задач?
Вопрос возник из-за того, что у ДельтаВи минимальный цикл выполнения – 100 мсек,
а для ПЛК цикл выполнения программы в 100 мсек – чаще всего трагедия.
Евгений

для DeltaV 100 мс это самый быстрый цикл исполнения задачи. Быстрее никак нельзя.
Есть модули дискретного ввода (aka SOE) которые отмеряют время срабатывания сигнала с погрешностью 1 мс.
Но это используется для регистрации аварий — управлять все равно быстрее 100 мс нельзя.
Выбора контроллеров у вас нет – MD это старый контроллер, и для новых систем поставляется пока только MD+.
Есть программка LoadEstimator.exe на инсталляционном диске – специально для расчета нагрузки контроллера.
Если поставите штук 50 алгоблоков в цикл 100 мсек, то контроллер захлебнется.
DeltaV рассчитана на медленные непрерывные процессы — добыча нефти и газа, нефтепереработка, нефтехимия, фармацевтика.
Для быстрых дискретных процессов, в том числе для слежения за скоростью конвейеров, обычно применяют ПЛК или комплексные интегрированные системы управления на базе ПЛК:
PlantPAx у Allen-Bradley
PCS7 у Сименс и т.п.
В процессах углеподготовки используется много электродвигателей, которыми нужно управлять – плавный пуск или регулировка частоты. ПЛК изначально заточены под эти задачи и имеют интерфейс с MCC или VFD.

Alert 06 окт 2009, 14:40

Евгений, на мой взгляд FF имеет 2 наиболее существенных преимущества перед всеми остальними fieldbus-асами. Это:
– сигнал и питание по двум проводам
– искробезопасная концепция FISCO
А возможность устраивать какие-то контуры регулирования в поле, не то что в СНГ, но и в мире используется крайне редко. Руками на стенде я пробовал это делать, но что то кроме простых контуров реализовывать не просто. Очень много ограничений нужно учитывать.
На Ванкоре тоже отказались от этой ‘примочки’ насколько я знаю.
Вообще помнится там даже не множество клапанов перенесли на Modbus. Что делает уже невозможным управление их без контроллера.
Наладка действительно выполняется быстрее. Все стремится к plug&play )))
Кроме того огромное количество диагностической информации. Что позволяет экономить в эксплуатации, типа из-за быстрого обнаружения неисправности и предаварийному ремонту.
Но проектирование на FF имеет ряд особенностей непривычный нашим проектировщикам.
Т.к. датчики запитываются по той же шине что и сигнал, то нужно сначала подбирать кип, смотреть его потребление (ток, напряжение), потом считать потери напряжения во всем сегменте от каждого устройства до коробки и до источника. С полевыми барьерами для взрывоопасных зон это несколько проще. Таким образом определять кол-во устройств в каждом сегменте, проверить проходит ли по скорости (если нет опять переразбивать) и только потом считать кол-во модулей ввода на контроллере. При этом надо не забыть что можно и что не нужно объединять в один сегмент и что нельзя разрывать. Например устройство с разных узлов и тем более с дублирующих объединять в сегмент не стоит, а датчик и клапан из одного контура разносить не хорошо и т.д.
Только мое мнение: FF имеет смысл только на непрерывных производствах с взрывоопасными зонами и тем более на судах и платформах.
Для конвееров с их быстрыми дискретными сигналами FF точно пихать не стоит. И никогда никто не сделает концевой выключатель с поддержкой FF.
P.S. Есть еще Profibus-PA. Тот же физический уровень, но протокол не H1, а Profibus. На мой взгляд именно H1 преимущество FF перед Profibus-PA.

Jackson 06 окт 2009, 14:49

Alert писал(а):Только мое мнение: FF имеет смысл только на непрерывных производствах с взрывоопасными зонами и тем более на судах и платформах.

Гм, ещё ни на одном судне и корабле и платформе я не видел FF.

Alert 06 окт 2009, 15:14

genelectric писал(а):

Alert писал(а):Только мое мнение: FF имеет смысл только на непрерывных производствах с взрывоопасными зонами и тем более на судах и платформах.

Гм, ещё ни на одном судне и корабле и платформе я не видел FF.

Платформа ‘Моликпак’, ‘Пильтун-Астохская-Б’ и ‘Лунская-А’ SEIC. Там очень много FF. Но не для ПАЗ, естественно.
Проектировали, поставляли и инсталировали не из России к сожалению.

Jackson 06 окт 2009, 15:20

Alert писал(а):

genelectric писал(а):

Alert писал(а):Только мое мнение: FF имеет смысл только на непрерывных производствах с взрывоопасными зонами и тем более на судах и платформах.

Гм, ещё ни на одном судне и корабле и платформе я не видел FF.

Платформа ‘Моликпак’, ‘Пильтун-Астохская-Б’ и ‘Лунская-А’ SEIC. Там очень много FF. Но не для ПАЗ, естественно.
Проектировали, поставляли и инсталировали не из России к сожалению.

Да, я оговорился – я имел в виду отечественного применения. Последняя наша отечественная платформа – это, как я понимаю, ‘Варандей’, но там FF и не пахнет, хотя налицо и взрывоопасность и непрерывность процесса.

Alert 06 окт 2009, 15:30

genelectric писал(а): Да, я оговорился – я имел в виду отечественного применения. Последняя наша отечественная платформа – это, как я понимаю, ‘Варандей’, но там FF и не пахнет, хотя налицо и взрывоопасность и непрерывность процесса.

Я слышал как Эмерсон, а точнее отдельные люди из него бились с Лукойлом по Корчагинской платформе, отстаивая FF. ЗАКАЗЧИК был непреклонен! ) Хотя как рассказывали приводили даже вес кабелей и кроссовых шкафов в том и другом случае.

andrmur 06 окт 2009, 16:35

Alert писал(а): Я слышал как Эмерсон, а точнее отдельные люди из него бились с Лукойлом по Корчагинской платформе, отстаивая FF. ЗАКАЗЧИК был непреклонен! ) Хотя как рассказывали приводили даже вес кабелей и кроссовых шкафов в том и другом случае.

Слухи неверные 😛
Как человек, лично причастный к этому проекту, могу сказать, что не сильно бились и никаких сравнительных расчетов не делали.
И, кстати, Лукойл, это самая прогрессивная компания — они первыми в 2000 году применили в России FF на Пермском НПЗ.

Евгений Кузнецов 07 окт 2009, 09:45

Дмитрий,
по рогам получили за то, что считали Модбас подвидом Филдбаса ,)?
А логика управления на Ванкорском м/р выполняется в контроллере или в полевых устройствах?

Ilya 09 окт 2009, 16:30

Здравствуйте, Дмитрий!
Вы не знаете случайно, чем обусловлен отказ от диагностики физического уровня FF в проекте Ванкор?

Илья Жуйков
ЗАО ‘Теккноу’, московский филиал
zhuykov @ tek – know.ru

Ilya 09 окт 2009, 17:08

Я имею в виду диагностику физического уровня. Мы предлагаем модули расширенной диагностики, которые устанавливаются стационарно вместе с системой питания. Данные модули отслеживают множество параметров связанных с физическим уровнем (напряжения, токи, шумы, балансность, джиттер, потерянные пакеты и т.п.), помогают превентивно выявлять проблемы (например когда постепенно ухудшается связь) имеют функции осциллографа и т.д.
Данные модули полностью интегрируются в AMS через OPC и DTM.
Понятно что у Вас и так есть AMS, через который Вы видите полевые приборы и их диагностические функции. Однако есть ещё и физический уровень связи, информацию о котором даёт наш модуль.

Илья Жуйков
ЗАО ‘Теккноу’, московский филиал
zhuykov @ tek – know.ru

Ilya 12 окт 2009, 11:54

Дмитрий,
Я уточнил этот вопрос. Модули у нас появились относительно недавно (в 2007), когда уже шло проектирование. На тот момент предложены они не были. Я не был в курсе дел, так что извиняюсь за беспокойство.
Сейчас, разумеется, мы предлагаем диагностику физ. уровня для всех новых проектов. Если у Вас есть интерес для собственного кругозора, могу прислать информацию.

Илья Жуйков
ЗАО ‘Теккноу’, московский филиал
zhuykov @ tek – know.ru