Foundation fieldbus что это

Обновлено: 17.05.2024

Вопрос Д.Милосердову и др.знатокам по Foundation Fieldbus

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

Лучше всего Вам съездить на завод, где FF работает и посмотреть своими глазами, поговорить с инженерами на месте, и пощупать руками.
Или ездить на выставки, где будет рабочее демо, например, в Киеве на нефтегазе.

А если кратко, то FF не упрощает, а немного усложняет ПО, но зато устраняет ряд механических операций и за этот счет ускоряет проведение работ.

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

спасибо за ответ. Я бы съездил, если бы в наших широтах была такая инсталляция.
У наиболее распространенных у нас Эмерсон и Ханивел, насколько я знаю, нет внедрений
проектов с FF.

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

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

Андрей, а у Вас (имею в виду российский Роквелл) есть внедрения на FF?

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

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

Я в шоке! И ведь находят вояки в условиях своей тесноты место для этих груд релюх и пачек кабелей. Я не говорю про то сколько это всё стОит!

По вопросам работы Форума можно обратиться по этим контактам.

Действительно, на Украине мне неизвестна ни одна инсталляция FF.
Так что смотреть живьем можно в России или в Европе.
У Роквелл в России пока нет действующих систем с FF, но обязательно будут - мы сейчас прорабатываем один проект и на столах у нас живописно разбросаны приборы FF и подключены к системе.

Что касается мнения о ненужности контроллеров, то я думаю, что такое светлое будущее наступит еще не скоро.
Все-таки приборы пока что умеют делать немногое:
- функциональные блоки AI с масштабированием сигнала для датчиков
- AO для клапанов
- DI/DO для интерфейсов с традиционными сигнализаторами и клапанами-отсекателями
- ПИД регуляторы
- Линеаризаторы сигналов

Чуть более сложные алгоритмы приходится делать в контроллере.
Регистрировать события и алармы, накапливать тренды также пока что приходится в контроллере - у датчиков пока нет еще объема памяти.
Но когда-нибудь лет через 10 это появится, и возможности датчиков выйдут на уровень контроллеров.

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

По теме - будет возможность хоть-где посмотреть, обязательно это сделаю. Но из Вашего опыта личных внедрений:
верны ли мои предположения в ответе Андрею?

MTL никогда не входил и сейчас не входит в GE.
MTL Instruments является подразделением Cooper Crouse-Hinds.

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

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

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

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

сейчас задачи как таковой нет, это больше для понимания реальных возможностей РСУ.
Но предположим: в цепочке производства кокса есть углеподготовительный цех, который
принимает угли, хранит, смешивает по нужной рецептуре, измельчает и транспортирует
смешанную шихту в коксовый цех. В коксовом цехе шихта спекается в кокс в батареях.
При спекании, кроме кокса, образуется коксовый газ, из которого извлекаются механические
и химические соединения в цехе улавливания.

Углеподготовительный цех (за исключением приготовления шихты) - это в чистом виде
дискретная логика, растянутая на несколько км: последовательные цепочки (маршруты)
механизмов, вдоль которых располагаются щитовые с пусковой аппаратурой этих самых механизмов.
Дискретных входов - 1200, выходов - 250. Задача системы управления углеподготовкой - управление цепочками
механизмов, и определение причины аварийного останова и причины невозможности запуска
(технологическая - концевик, аварийная кнопка и т.д., или электрическая - тепловая защита,
оперативное питание, силовое питание и т.д.). Каждому механизму соответствует от 5 до 12 дискретных
входов, в т.ч. и быстрые, напр., импульсы от датчика скорости (скажем, 10 Гц). Важно:
- правильный запуск маршрута;
- правильный останов маршрута;
- правильное определение причины аварийного останова или неготовности к запуску, т.к. на основании
этого принимаются технологические или электрические меры. Неправильно
определил - потерял время на простое механизмов, недогрузил коксовую батарею и т.д.

Цех улавливания - это в чистом виде непрерывный процесс (контроль и регулирование уровней,
температур, расходов). В этом цехе точно подойдет РСУ, напр. ДельтаВи.

А для углеподготовительного подойдет РСУ, напр.ДельтаВи? Правильно запустить и остановить последовательность
наверняка сможет, определить неготовность к запуску - тоже. А вот детектировать причину останова?
Некоторые сигналы реально могут быть в "1" менее 1 секунды. Может быть модули SOE помогут?

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

а какие у ДВ есть контроллеры? Я знаю только МД, МД+, вот теперь еще SD, SX.

Вот для меня загадка, а если всем стратегиям, которые только возможны для объекта,
назначить цикл выполнения 100 мсек? Не станет ли плохо процессору? Есть ли какая-то
методика расчета загрузки процессора исходя из предполагаемого кол-ва и типов
стратегий и цикла их выполнения?

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

П.С. вполне возможно, что если бы была инсталляция этой самой ДВ, то части бы вопросов
не возникло. Но наш Эмерсон немного зашифрованный и не раздает налево и направо
бесценный софт. Хотя, может это и правильно.

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

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

для DeltaV 100 мс это самый быстрый цикл исполнения задачи. Быстрее никак нельзя.
Есть модули дискретного ввода (aka SOE) которые отмеряют время срабатывания сигнала с погрешностью 1 мс.
Но это используется для регистрации аварий -- управлять все равно быстрее 100 мс нельзя.

Выбора контроллеров у вас нет - MD это старый контроллер, и для новых систем поставляется пока только MD+.
Есть программка LoadEstimator.exe на инсталляционном диске - специально для расчета нагрузки контроллера.
Если поставите штук 50 алгоблоков в цикл 100 мсек, то контроллер захлебнется.
DeltaV рассчитана на медленные непрерывные процессы -- добыча нефти и газа, нефтепереработка, нефтехимия, фармацевтика.

Для быстрых дискретных процессов, в том числе для слежения за скоростью конвейеров, обычно применяют ПЛК или комплексные интегрированные системы управления на базе ПЛК:
PlantPAx у Allen-Bradley
PCS7 у Сименс и т.п.

В процессах углеподготовки используется много электродвигателей, которыми нужно управлять - плавный пуск или регулировка частоты. ПЛК изначально заточены под эти задачи и имеют интерфейс с MCC или VFD.

Евгений, на мой взгляд FF имеет 2 наиболее существенных преимущества перед всеми остальними fieldbus-асами. Это:
- сигнал и питание по двум проводам
- искробезопасная концепция FISCO

А возможность устраивать какие-то контуры регулирования в поле, не то что в СНГ, но и в мире используется крайне редко. Руками на стенде я пробовал это делать, но что то кроме простых контуров реализовывать не просто. Очень много ограничений нужно учитывать.
На Ванкоре тоже отказались от этой "примочки" насколько я знаю.
Вообще помнится там даже не множество клапанов перенесли на Modbus. Что делает уже невозможным управление их без контроллера.
Наладка действительно выполняется быстрее. Все стремится к plug&play )))
Кроме того огромное количество диагностической информации. Что позволяет экономить в эксплуатации, типа из-за быстрого обнаружения неисправности и предаварийному ремонту.

Но проектирование на FF имеет ряд особенностей непривычный нашим проектировщикам.
Т.к. датчики запитываются по той же шине что и сигнал, то нужно сначала подбирать кип, смотреть его потребление (ток, напряжение), потом считать потери напряжения во всем сегменте от каждого устройства до коробки и до источника. С полевыми барьерами для взрывоопасных зон это несколько проще. Таким образом определять кол-во устройств в каждом сегменте, проверить проходит ли по скорости (если нет опять переразбивать) и только потом считать кол-во модулей ввода на контроллере. При этом надо не забыть что можно и что не нужно объединять в один сегмент и что нельзя разрывать. Например устройство с разных узлов и тем более с дублирующих объединять в сегмент не стоит, а датчик и клапан из одного контура разносить не хорошо и т.д.

Только мое мнение: FF имеет смысл только на непрерывных производствах с взрывоопасными зонами и тем более на судах и платформах.
Для конвееров с их быстрыми дискретными сигналами FF точно пихать не стоит. И никогда никто не сделает концевой выключатель с поддержкой FF.

Обзор основ технологии передачи данных по полевой шине Foundation Fieldbus

Технология Foundation Fieldbus — это открытая архитектура, предназначенная для интеграции информации от полевых датчиков в АСУ ТП. Она является цифровой, последовательной, двухсторонней системой связи.

Существует две реализации интерфейса Foundation Fieldbus:

Foundation Fieldbus H1
Foundation Fieldbus HSE (High Speed Ethernet)

Foundation Fieldbus H1 работает на скорости 31, 25 кбит/с и, как правило, соединяется напрямую с полевыми устройствами (датчики, приводы и системы ввода/вывода). Данные передаются по последовательному интерфейсу RS-485.

Foundation Fieldbus HSE работает на скорости 100 Мбит/с и обеспечивает интеграцию контроллеров, подсистем Foundation Fieldbus H1, серверов и рабочих станций посредством Ethernet.

Технология H1 использует все преимущества аналоговых систем 4. 20 мА, такие как:

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

Более того, технология Foundation Fieldbus обеспечивает:

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

Преимущества Foundation Fieldbus

За счет применения технологии H1 в системах управления могут быть получены значительные преимущества:

Передача бОльших объемов данных

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

Расширенные возможности для диагностики

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

Сокращение объема аппаратной части

Технология Foundation Fieldbus использует стандартизированные функциональные блоки (Function Blocks) для реализации функций управления, сбора и обработки данных.

Функциональные блоки — это стандартные функции автоматизации, такие как, например, аналоговый вход (AI), аналоговый выход (AO) или PID-регулятор. Все данные функции могут быть реализованы прямо на полевом устройстве за счет применения функциональных блоков.

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

Уменьшение объема используемых кабелей

Полевая шина H1 позволяет подключить множество устройств к одному сегменту шины при помощи одной «витой пары». В итоге отпадает необходимость тянуть кабели и линии связи к каждому полевому устройству, что существенно снижает издержки.

Заключение

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

Уровень пользовательских приложений

Функциональные блоки в Foundation Fieldbus бывает трех типов:

Ресурсный блок (Resource Block);
Функциональный блок — (Function Block);
Блок передачи данных (Transducer Block).

Ресурсный блок может существовать только в одном экземпляре в устройстве Foundation Fieldbus. Данный блок хранит информацию о характеристиках устройства: наименование, производитель, серийный номер.

Функциональный блок обеспечивает необходимое поведение системы. Исполнение каждого блока жестко задано по времени. В одном устройстве может быть множестве функциональных блоков.

В Foundation Fieldbus определены наборы стандартных функциональных блоков, таких как, например, AI, AO, DI, PID и т. д.

Также существуют, так называемые, гибкие функциональные блоки (Flexible Function Block). Данные блоки создаются пользователем. Тип, количество входов и выходов, а также внутренние алгоритмы определяются пользователем. Для организации внутренней логики могут использоваться стандартные функциональные блоки.

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

Очередность выполнения функциональных блоков

Инструмент для работы с очередностью (schedule building tool) используется для составления очередности работы функциональных блоков и расписания LAS.

Очередности содержат время старта в отчете от «абсолютного времени старта» (absolute link schedule start time). Абсолютное время старта известно всем устройствам, которые подключены к шине.

В течение одного цикла в зависимости от обозначенного времени старта поочередно запускаются функциональные блоки (первым запускается блок с временем 0, далее блок с временем 20 и т. д.).

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

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

При подключении нового устройства к шине происходит следующее:

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

Для удобства обслуживания технология Foundation Fieldbus предусматривает службы, позволяющие искать устройства или переменные, используя тэги.

Запрос «find tag query» является широковещательным. Сразу после принятия такого запроса устройство начинает поиск тэга в VFD и возвращает полный путь (в случае если тэг найден), включая сетевой адрес, номер VFD, номер VCR и номер в «словаре объектов». После первичного изучения полного пути устройства хост может обращаться к данным по тэгу.

Устройство поставляется с тремя файлами:

два файла описания устройства (Device Description File);
один файл описания возможностей устройства (Capability File).

Критически важная характеристика для устройств Foundation Fieldbus — совместимость. Для достижения совместимости, в дополнение к стандартным функциональным блокам и описанию поведения, используется технология описания устройства (Device Description — DD).

DD предоставляет расширенное описание каждого объекта, содержащегося в виртуальном полевом устройстве. Эта информация необходима для систем управления или хоста для возможности работы с данными, которые содержит VFD. То есть файл DD представляет собой «драйвер» устройства.

Файл описания возможностей устройства предоставляет хосту информацию о том, какие функциональные блоки и прочие ресурсы доступны устройству. Таким образом, хост «уверен» какой функционал поддерживается устройством, а какой нет.

Соответствие технологии FF модели OSI

Технология Foundation Fieldbus H1 представлена тремя уровнями модели OSI:

Физический уровень

По шине, помимо передачи данных, также выполняется питание устройств, что позволяет использовать существующую инфраструктуру для передачи аналоговых сигналов 4. 20 мА. Для реализации искробезопасных применений Fieldbus поддерживает специально разработанную концепцию искробезопасности для полевых шин FISCO (Fieldbus Intrinsicaly Safe Concept).

Канальный уровень — коммуникационный стек H1

В спецификации DLL определены два типа устройств:

Простое устройство (Basic Device)
Мастер соединения (Link Master)

Мастер соединения может использоваться в качестве активного планировщика связей (Link Active Scheduler — LAS). В качестве мастера соединений, как правило, выступают контроллеры. Простые устройства (Basic Device) не могут выступать в роли LAS.

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

Виртуальная коммуникационная связь (VCR — Virtual Communication Relationship) использует сервисы канального уровня для передачи данных. Проводя аналогию с телефонными линиями, VCR позволяет реализовать скоростной набор, т. е. вместо набора кода страны, номера, кода абонента, достаточно знать номер быстрого набора. Так и в Foundation Fieldbus — достаточно знать VCR номер для доступа к устройству. После того, как устройство сконфигурировано, для доступа к нему необходим только номер VCR. Для разных типов передачи данных используются различные типы VCR:

Шина может иметь несколько устройств мастеров соединения. Если активный LAS по какой-то причине выйдет из строя, то резервный мастер соединений станет активным планировщиком связей и работа шины продолжится в нормальном режиме.

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

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

Вся необходимая для системы управления информация (например, расписание работы функциональных блоков) содержится в описании устройства, которое называется виртуальным полевым устройством системы управления (System Management Virtual Field Device — VFD). VFD предоставляет доступ к информационному блоку управления системой — SMIB (System Management Information Base) и информационному блоку управления сетью — NMIB (Network Management Information Base).

Читайте также: