Сетевое сканирование и организация управления в менеджере типов устройств

Сетевое сканирование и организация управления в менеджере типов устройств

Иллюстрации

Показать все

Реферат

Ссылка на родственную заявку

В настоящей заявке используются материалы заявки на патент США №60/956328, озаглавленной "Сетевое сканирование и организация работы в менеджере типов устройств ", поданной 16 августа 2007 г., содержание которой включается в настоящий документ в виде ссылки.

Область техники, к которой относится изобретение

Настоящее изобретение относится по сути к устройствам управления в среде управления процессами, и, в частности, к функции сканирования менеджера типов устройств (Device Type Manager, далее для краткости - DTM), работающего в инфраструктуре, выполненной в соответствии со стандартом инструментария полевых устройств (Field Device Tool, далее для краткости - FDT).

Уровень техники

Системы управления процессами, подобные используемым в химических, нефтяных или других процессах, обычно включают по меньшей мере один централизованный или децентрализованный контроллер процесса, соединенный с возможностью связи по меньшей мере с одним сервером (головным компьютером) или терминалом оператора, и по меньшей мере с одним измерительно-контрольным устройством процесса, таким как, например, полевые устройства, при помощи аналоговых, цифровых или смешанных аналого-цифровых шин. Полевые устройства, представляющие собой, например, клапаны, позиционеры клапанов, переключатели, передатчики и датчики (например, датчики температуры, давления и скорости потока), находятся в среде производственного предприятия, и выполняют функции в рамках процесса, такие как открытие или закрытие клапанов, измерение параметров процесса, усиление или уменьшение потока жидкости и т.д. Интеллектуальные полевые устройства, такие как полевые устройства, соответствующие широко известным протоколам, таким как FOUNDATION™ Fieldbus, Device-Net^™ или HART^®, также могут выполнять контрольные вычисления, сигнальные функции и прочие функции управления, обычно являющиеся частью контроллера процесса.

Контроллеры процесса, обычно располагающиеся в среде производственного предприятия, получают сигналы, отражающие измерения в ходе процесса, либо переменные процесса, полученные при помощи полевых устройств или связанные с ними, и/или иную информацию, касающуюся полевых устройств, а также выполняют приложения контроллера. Приложения контроллера реализуют, например, различные управляющие модули, принимающие решения, связанные с управлением процессом, вырабатывают управляющие сигналы на основе полученной информации и осуществляют координацию с управляющими модулями или блоками полевых устройств, таких как полевые устройства HART^® и Fieldbus. Управляющие модули в контроллерах процесса посылают управляющие сигналы по линиям связи или сигнальным каналам к полевым устройствам для управления таким образом работой процесса.

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

Недавнее введение технологии Fieldbus и связанных с ней стандартов в области управления процессами сделало возможным объединение полевых устройств, контроллеров процесса, мультиплексоров, терминалов и прочего оборудования предприятия в единую сеть. По сути, Fieldbus предоставляет основу для распределенного управления в реальном времени за счет предоставления возможности множеству устройств соединяться с одной двухпроводной линией, которая, в свою очередь, может соединяться с контроллером, головным компьютером или другим интеллектуальным головным устройством. Однако эффективность Fieldbus значительно ограничена большим числом стандартов протокола, обуславливающих связь при помощи Fieldbus. Например, на данный момент существуют такие конкурирующие протоколы Fieldbus, как Foundation Fieldbus (FF) и Profibus, в дополнение к другим типам протоколов связи, таким как HART^® или CAN. Кроме того, существует значительное число рабочих устройств, по-прежнему использующих диапазон 4-20 мА, которые требуют дополнительного аппаратного обеспечения для подключения к линии Fieldbus.

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

В последние годы была предпринята попытка решить проблему несовместимости данных процесса, документации, конфигурации устройств и человеко-машинного интерфейса (ЧМИ) с помощью внедрения стандарта FDT. Целью стандарта FDT является предоставление конечному пользователю унифицированного способа связи с гетерогенными полевыми устройствами и прочими компонентами управления процессом путем определения различных интерфейсов и единой программной инфраструктуры. В частности, объединенная общими интересами группа (Joint Interest Group), включающая множество крупных производителей, согласовала внедрение нескольких определений интерфейса, доступных для широкого круга лиц, и выбрала программную платформу для разработки различных приложений высокого уровня. Дополнительную информацию об FDT можно найти по адресу www.fdt-jig.org. Сама технология FDT не предоставляет готовых утилит, но она предоставляет набор инструментальных средств для разработки так называемых приложений инфраструктуры для таких разнообразных целей, как управление ресурсами, конфигурация устройств, или моделирование управления процессом и диагностика.

FDT основывается на нескольких широко распространенных стандартах и технологиях, благодаря чему приложения инфраструктуры способны работать на компьютерах, оснащенных операционной системой Microsoft Windows. В частности, FDT основывается на объектной модели программных компонентов Microsoft (Component Object Model, СОМ) с целью обеспечения объектно-ориентированной разработки, не зависящей от языка программирования; на расширяемом языке разметки (Extensible Markup Language, XML) для обмена данными; и на технологии ActiveX для определения графического интерфейса. Знакомому со средой Microsoft Windows^® человеку известно, что модель СОМ позволяет разрабатывать динамические объекты и обеспечивает взаимодействие процессов между собой вне зависимости от языка программирования. Кроме того, объекты СОМ демонстрируют свою функциональность и характеристики через хорошо определенные интерфейсы. С целью обеспечения графического пользовательского интерфейса (Graphical User Interface, GUI), стандарты FDT требуют использования ActiveX. С одной стороны, технология ActiveX компании Microsoft является расширением стандарта СОМ, направленным конкретно на использование графических интерфейсов, интерфейсов пользовательского ввода и интерфейсов обмена данными в среде Windows. Наконец, FDT использует XML -открытый стандарт, широко используемый в различных сферах промышленности и приложениях для определения данных. XML предоставляет лексические правила, при помощи набора команд (тэгов) определяющие тип и границы структур данных. Для специалиста, знакомого со смежными областями, такими как веб-программирование, очевидно, что правильно выполненные XML-документы могут быть прочитаны как человеком, так и машиной. Немаловажно, что XML также обеспечивает легкость расширения при помощи определяемых пользователем тэгов.

FDT использует XML для определения правил связи между объектами, такими как, например, приложение инфраструктуры FDT и менеджер типов устройств (DTM). DTM представляет собой компонент программного обеспечения, включающий программные приложения, выполненные для конкретного устройства. В соответствии с общими принципами СОМ, DTM представляет собой двоичный объект с набором интерфейсов, соответствующих правилам инфраструктуры FDT. Обычно производитель устройства предоставляет DTM для конкретного типа устройства, благодаря чему DTM может включаться в приложение управления процессом, программное обеспечение управления ресурсами или в другой тип разрабатываемого DTM-приложения. Указанный DTM включает диалоги пользователя и пользовательские интерфейсы, правила для соответствующего устройства и во многих случаях справочную информацию для приложения, которое может относиться к устройству.

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

Имеются различные типы объектов DTM, используемые приложениями инфраструктуры FDT. Например, DTM типа "устройство" (обозначаемый здесь как "DTM устройства") представляет собой полевое устройство, а коммуникационный DTM соответствует модулю с прямым доступом к ресурсу связи. Таким образом, цифровой контроллер клапана серии DVC6000, выпускаемый компанией Emerson Process Management™, может быть представлен DTM устройства, осуществляющим связь при помощи интерфейса FDT с коммуникационным DTM, представляющим собой HART-модем. Более конкретно, приложение инфраструктуры, работающее на терминале оператора, например, обрабатывает объект конкретного класса DTM устройств и объект конкретного класса коммуникационных DTM. В среде FDT, DTM устройства не "знает" деталей протокола, поддерживаемого конкретным коммуникационным DTM, а коммуникационный DTM не "знает" особенностей DTM устройства. В ходе конфигурации, диагностики или операции другого типа, DTM устройства может послать команду с соответствующими командными параметрами на коммуникационный DTM, а коммуникационный DTM, в свою очередь, отформатирует команду в соответствии с требованиями протокола и передаст данные правильному интерфейсу терминала оператора. Если говорить коротко, DTM устройства определяет функциональные свойства конкретного устройства, а коммуникационный DTM определяет функциональные свойства конкретного протокола. DTM устройства также может осуществлять связь с соответствующим физическим устройством при помощи встроенных каналов приложения инфраструктуры, либо использовать как встроенные каналы, так и канальные функции, обеспечиваемые одним или несколькими коммуникационными DTM.

Далее, DTM шлюза обеспечивает маршрутизацию между различными протоколами. Например, DTM шлюза может обеспечивать трансляцию протокола PROFIBUS в протокол HART. В некоторых случаях DTM шлюза может обеспечивать и другие функции с целью облегчения взаимодействия между полевыми устройствами и аппаратными устройствами связи, в дополнение к или вместо трансляции протоколов. В определенных вариантах выполнения, DTM шлюза может быть соединен с DTM устройства и коммуникационным DTM. В других вариантах, DTM шлюза может соединяться с двумя коммуникационными DTM, поддерживающими разные протоколы или схемы связи. Кроме того, могут быть разработаны и другие типы DTM для таких нужд, как, например, соединение приложения FDT с внешним приложением.

Интерфейсы и функции, обеспечиваемые существующей средой FDT/DTM, обычно требуют реализации отдельного DTM для каждого физического устройства. Кроме того, DTM устройства может соединяться лишь с одним каналом связи коммуникационного DTM. Таким образом, несмотря на то, что инструментарий FDT предоставляет инженерам и операторам мощный набор программных утилит, разработка и конфигурирование приложений инфраструктуры FDT для крупных систем управления процессами может быть весьма долгой и трудоемкой. В частности, операторы должны конфигурировать каждый DTM устройства с адресом соответствующего физического устройства. Кроме того, конфигурация каждого устройства должна осуществляться отдельно, даже если несколько устройств имеют множество общих параметров конфигурации. Например, если несколько сходных устройств выполнены на одной линии подключения FF H1, каждый DTM устройства необходимо отдельно реализовывать, конфигурировать с правильным физическим адресом, и дополнительно конфигурировать перед использованием.

Раскрытие изобретения

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

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

С одной стороны, выполненный с возможностью сканирования DTM устройства соответствует стандарту инфраструктуры FDT, определенному Joint Interest Group. В этом отношении выполненный с возможностью сканирования DTM устройства полностью совместим с приложениями инфраструктуры FDT. В одном варианте осуществления выполненный с возможностью сканирования DTM устройства заменяет DTM устройства для конкретного устройства и может быть предоставлен в качестве заменяющего DTM изготовителем устройства. Заменяющий DTM может иметь все функции DTM устройства для соответствующего устройства, а также дополнительную функцию сканирования, реализованную согласно материалам настоящей заявки. В другом варианте выполненный с возможностью сканирования DTM устройства соединяет приложение, работающее вне инфраструктуры FDT, с коммуникационным DTM в инфраструктуре FDT. Внешнее приложение может изначально поддерживать функции конкретного устройства, а выполненный с возможностью сканирования DTM устройства может обеспечивать внешнее приложение функцией обнаружения, а также может служить в качестве соединения между внешним приложением и инфраструктурой FDT.

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

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

Краткое описание чертежей

Фиг.1 схематически иллюстрирует систему управления процессами, которая может быть конфигурироваться и управляться при помощи приложения инфраструктуры FDT.

Фиг.2 представляет собой схематичное отображение нескольких объектов DTM известных типов, взаимодействующих в приложении инфраструктуры FDT.

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

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

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

Фиг.5А представляет собой схематичное отображение программного приложения, работающего вне инфраструктуры FDT и взаимодействующего с несколькими выполненными с возможностью сканирования объектами DTM устройства, реализованными в отдельных приложениях инфраструктуры FDT.

Фиг.6 иллюстрирует пример программы, которую может выполнить выполненный с возможностью сканирования DTM устройства в ходе процесса сканирования устройств.

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

Осуществление изобретения

Фиг.1 представляет собой схематичное отображение системы управления процессами, в которой программные утилиты, разработанные в инфраструктуре FDT, позволяют операторам просматривать, конфигурировать или иным образом поддерживать связь с элементами системы управления процессами, вне зависимости от специфических параметров изготовителя или модели конкретного элемента. В частности, система управления процессами 100 включает один или несколько контроллеров процесса 110, имеющих коммуникационное соединение с одним или несколькими головными терминалами или компьютерами 120-122 (которые могут быть представлены любым типом персональных компьютеров, терминалов и т.п.), снабженными по меньшей мере одним дисплеем. Контроллеры 110 также соединены с полевыми устройствами 130 при помощи плат ввода-вывода 140. Архиватор данных 145 может представлять собой устройство сбора данных любого типа, снабженное памятью любого типа и любым требуемым или известным программным обеспечением, аппаратным обеспечением или аппаратно реализованным программным обеспечением для хранения данных, и может быть выполнен отдельно от терминалов 120-122, либо в виде составной части одного из указанных терминалов. Контроллер 110, который может быть, например, контроллером DeltaV™, выпускаемым компанией Fisher-Rosemount Systems, Inc., имеет коммуникационное соединение с головными компьютерами 120-122 посредством, например, локальной сети Ethernet, либо иной желаемой сети передачи данных 150. Сеть передачи данных 150 может быть выполнена в виде локальной вычислительной сети (ЛВС), глобальной вычислительной сети (ГВС), сети телекоммуникаций и т.п., и может быть выполнена с использованием проводной или беспроводной технологии. Контроллер 110 имеет коммуникационное соединение с полевыми устройствами 130 при помощи любого желаемого аппаратного и программного обеспечения, относящегося, например, к стандартным устройствам диапазона 4-20 мА, и/или любого «интеллектуального» протокола связи, такого как протокол FOUNDATION Fieldbus (Fieldbus), протокол HART и т.п.

Полевые устройства 130 могут представлять собой устройства любого типа, такие как датчики, клапаны, передатчики, позиционеры и т.п., а платы ввода-вывода 140 могут представлять собой устройства ввода-вывода любого типа, совместимые с любым желаемым протоколом связи или контроллера. В варианте выполнения, показанном на фиг.1, полевые устройства 130 представляют собой устройства HART, осуществляющие связь при помощи стандартных аналоговых линий 131 в диапазоне 4-20 мА с HART-модемом 140, а полевые устройства 133 представляют собой интеллектуальные устройства (с программным управлением), такие как полевые устройства Fieldbus, осуществляющие связь по цифровой шине 135 с платой ввода-вывода 140 при помощи протокола связи Fieldbus. Естественно, полевые устройства 130 и 133 могут быть совместимы с любыми другими желаемыми стандартами или протоколами, включая любые стандарты или протоколы, которые будут разработаны в будущем.

Дополнительно, полевое устройство 142 может быть соединено с цифровой шиной 135 при помощи шлюза 143. Например, полевое устройство 142 может принимать только команды HART, а цифровая шина 135 может использовать протокол PROFIBUS. В этом случае, шлюз 143 может обеспечивать двустороннюю трансляцию протоколов PROFIBUS/HART.

Контроллер 110, который может быть одним из нескольких распределенных контроллеров в рамках предприятия, снабженных по меньшей мере одним процессором, выполняет или контролирует осуществление одной или нескольких программ управления, которые могут включать замкнутые схемы регулирования, хранящиеся внутри них или иным образом связанные с ними. Контроллер 110 также взаимодействует с устройствами 130 или 133, головными компьютерами 120-122 и архиватором данных 145 для управления процессом любым желаемым способом. Необходимо отметить, что любые программы управления или элементы, описанные здесь, могут быть при необходимости частично выполнены или осуществлены при помощи других контроллеров или иных устройств. Сходным образом, программы управления или элементы, описанные здесь и выполняемые в рамках системы управления процессами 100, могут иметь любую форму, включая программное обеспечение, аппаратно реализованное (встроенное) программное обеспечение, аппаратное обеспечение и т.п. В целях настоящего описания, элемент управления процессом может представлять собой любую часть или составляющую системы управления процессами, включая, например, программу, блок или модуль, хранящийся на любом считываемом компьютером носителе. Программы управления, которые могут быть модулями либо любой частью программы (процедуры) управления, такой как подпрограммы, части подпрограммы (например, строки кода программы), и т.п., могут быть реализованы в любом программном формате, например, с использованием принципиальной схемы, схемы последовательных функций, функциональной схемы, объективно-ориентированного программирования, или любого другого языка программирования ПО или проектного решения. Сходным образом, программы управления могут быть жестко запрограммированными в, например, одном или нескольких ЭППЗУ, ЭСППЗУ, интегральных схемах прикладной ориентации (ИСПО), или любых других аппаратных элементах или элементах аппаратно реализованного программного обеспечения. Кроме того, программы управления могут быть выполнены с помощью любых средств проектирования, включая средства графического проектирования или любой другой тип программного обеспечения, аппаратного обеспечения, аппаратно реализованного программного обеспечения или средств проектирования. Таким образом, контроллер 110 может быть спроектирован с возможностью выполнения стратегии управления или программы управления любым желаемым способом.

Терминалы 120-122 могут выполнять одно или несколько приложений инфраструктуры FDT, каждое из которых может работать в распределенном или нераспределенном режиме. Например, терминал 120 может выполнять функции хранения определенного приложения FDT по управлению ресурсами, а компьютер 122 может выполнять функции формирования запросов того же приложения. Как показано на фиг.1, приложение 200 инфраструктуры FDT может работать на терминале 120 и может отвечать за управление ресурсами. Сходным образом, приложение 200 инфраструктуры FDT может также управлять одним из других аспектов автоматизации предприятия, таким как техническое обеспечение (разработка, моделирование и т.п.), установка, ввод в эксплуатацию, производство или эксплуатационное обслуживание. Кроме того, ниже отмечается, что приложение 200 инфраструктуры FDT не ограничено перечисленными выше функциями и может выполнять одну или несколько функций, обеспечиваемых инфраструктурой FDT.

Как показано на фиг.2, приложение 200 инфраструктуры FDT может работать в распределенном или нераспределенном режиме на платформе 202. В показанном выше примере, платформа 202 может представлять собой операционную систему Windows, предоставляемую терминалом 122. Однако платформа 202 может, в некоторых вариантах выполнения, распространяться на несколько головных компьютеров, таких как терминалы 120 и 122 при использовании одного из известных из уровня техники способов выполнения распределенной архитектуры программного обеспечения. В примере, показанном на фиг.2, приложение 200 инфраструктуры FDT выполнено с использованием известных способов и представлено здесь в качестве примера.

Приложение инфраструктуры FDT 200 может осуществлять вывод экрана, отображающего панель меню 204, панель инструментов 206 и различные навигационные клавиши 208. Как описано выше, приложение 200 инфраструктуры FDT основывается на технологии СОМ и ActiveX компании Microsoft для доступа к стандартным графическим интерфейсам Windows, и тем самым позволяет пользователю осуществлять ввод данных при помощи клавиатуры, мыши или иного указывающего устройства или устройства ввода данных. Приложение 200 инфраструктуры FDT может также включать в себя базу данных 210, взаимодействующую с различными объектами FDT при помощи интерфейсов, представленных в стандарте FDT. Приложение 200 инфраструктуры FDT может дополнительно содержать несколько экземпляров объектов DTM. В частности, коммуникационный DTM 220 может отвечать за связь посредством Foundation Fieldbus (FF) H1 на определенном сегменте, доступном физическому FF-интерфейсу 222 платформы 202. Как показано на фиг.2, FF-интерфейс 222 может включать d ct, z несколько модулей, таких как компьютерные карты расширения, совместимые, например, со стандартом соединения периферийных компонентов (Peripheral Computer Interconnect, PCI), либо отдельный аппаратный модуль. В другом варианте, коммуникационный DTM в общем и DTM 220 в частности может соответствовать любому физическому выполнению устройства или модуля связи. В описанном здесь примере коммуникационный DTM 220 соответствует аппаратному модулю 224, ответственному за определенный сегмент H1.

В ходе работы коммуникационный DTM 220 генерирует и передает команды, совместимые с протоколом FF H1, на аппаратный модуль 224 через соединение 230.

Соединение 230 может включать стандартные интерфейсы, предоставляемые операционной системой, последовательные интерфейсы, такие как RS232, и иные известные способы связи с периферийным устройством. Аппаратный модуль 224 может связываться с одним или несколькими полевыми устройствами 240-244 при помощи цифровой шины 235, которая может быть сходной с шиной 135. В частности, полевое устройство 240 может иметь адрес A₁, полевое устройство 242 может иметь адрес A₂, а полевое устройство 244 может иметь адрес А₃. При отправлении или получении команд и данных, приложение 200 инфраструктуры FDT в общем случае обращается к конкретному адресу A₁-А₃ для точного определения целевого устройства. В известной среде FDT, коммуникационный DTM 220 получает команду и адрес целевого устройства, соединенного с цифровой шиной 235, от DTM устройства, соответствующего целевому устройству. Таким образом, приложение 200 инфраструктуры FDT обрабатывает объект 250 DTM устройства, соответствующий полевому устройству 240, объект 252 DTM устройства, соответствующий полевому устройству 242, и объект 254 DTM устройства, соответствующий полевому устройству 244.

Каждый из стандартных объектов 250-254 DTM устройств конфигурируется с адресом соответствующего полевого устройства. Например, DTM 250 устройства не может связываться с соответствующим физическим устройством 240, пока он не получит адрес A₁ путем явного конфигурирования. Таким образом, при нынешнем уровне техники, если определенная система имеет пять сегментов FF H1, и на каждом сегменте H1 находятся восемь устройств определенного типа, приложение FDT требует по меньшей мере 40 отдельных экземпляров DTM устройства указанного типа, чтобы осуществлять функционирование и мониторинг каждого полевого устройства. Как показано на фиг.2, коммуникационный DTM 260 может соответствовать HART-модему 262 и сходным образом требовать наличия количества DTM 266 устройства, равное числу полевых устройств 268, соединенных с HART-модемом 262. Коммуникационный DTM 260 может связываться с HART-модемом 262 по каналу связи 263.

В описанном выше примере, каждое из обычных DTM 250-254 и 266 устройства реализуется конкретно для протокола, поддерживаемого коммуникационным DTM, к которому прикреплен DTM устройства. Как отмечено выше, DTM устройства может также быть соединен с DTM шлюза, поддерживающим трансляцию между протоколами. Как показано на фиг.2, DTM 270 устройства, соответствующий полевому устройству, поддерживающему только PROFIBUS, может быть соединен с DTM шлюза 272, обеспечивающему трансляцию PROFIBUS/HART. DTM 272 шлюза, в свою очередь, соединен с коммуникационным DTM 260, обеспечивающим HART-коммуникации.

Как показано на фиг.3, выполненный с возможностью сканирования DTM 300 устройства по настоящему изобретению, работающий в приложении 302 инфраструктуры FDT, может взаимодействовать с внешним модулем 310 программного обеспечения (ПО) при помощи интерфейсов, соответствующих действующим стандартам FDT. В другом варианте выполнения, соединение между выполненным с возможностью сканирования DTM 300 устройства и внешним модулем 310 ПО расширяет стандарт FDT или основывается на схеме связи, находящейся вне сферы FDT; однако, работа выполненного с возможностью сканирования DTM 300 устройства в приложении 302 инфраструктуры FDT предпочтительно соответствует стандарту FDT. Внешний модуль 310 ПО может представлять собой, например, приложение AMS ValveLink^® Software от компании Emerson Process Management™, являющееся частью пакета PlantWeb^®. Нужно отметить, что несмотря на то, что на фиг.3 изображен внешний модуль 310 ПО, как принадлежащий платформе 202, этот и прочие примеры внешнего ПО, описанные ниже, могут также работать на другой платформе или на нескольких платформах в распределенном режиме. Поскольку внешний модуль 310 ПО не является частью приложения 302 инфраструктуры FDT, модуль 310 ПО не имеет прямого доступа ни к одному из коммуникационных DTM. В целом, приложение 302 инфраструктуры FDT сходно с приложением 200 инфраструктуры FDT в том, что оно опирается на стандартные интерфейсы FDT и может работать на той же платформе 202 ОС. Более того, приложения 200 и 302 инфраструктуры FDT соответствуют тем же самым конфигурациям физических устройств, таких как полевые устройства и модемы. Как показано на фиг.3, выполненный с возможностью сканирования DTM 300 устройства может соединяться с коммуникационным DTM 220, ответственным за определенный сегмент FF Н1.

В ходе работы, внешний модуль 310 ПО может связываться с полевым устройством 240, посылая специфичные для устройства команды. В одном варианте выполнения, внешний модуль 310 ПО знает специфичные для устройства параметры и команды и требует лишь канала связи для работы с полевым устройством 240. Например, полевое устройство 240 может представлять собой цифровой контроллер клапана DVC6000, а модуль 310 ПО может представлять собой приложение AMS ValveLink Software, управляющее работой клапана при помощи контроллера DVC6000 и предоставляющее пользователю графическое и текстовое отображение.

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

Как в частности показано на фиг.3, выполненный с возможностью сканирования DTM 300 устройства может быть примером класса выполненных с возможностью сканирования DTM устройства, запрограммированных на взаимодействие с коммуникационным DTM определенного типа протокола. Выполненный с возможностью сканирования DTM 300 устройства может быть реализован для работы конкретно с протоколом FF H1, а выполненный с возможностью сканирования DTM 304 устройства может быть примером того же класса, реализованным для работы с протоколом HART. В другом варианте выполнения, выполненные с возможностью сканирования DTM 300 и 304 устройства могут быть реализованы из разных классов, каждый из ко