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

Формула изобретения

1. Способ связи с использованием инфраструктуры, выполненной в соответствии со стандартом FDT, с устройством, работающим в среде управления процессами и имеющим коммуникационное соединение с линией связи, включающий в себя:

генерирование экземпляра DTM устройства, выполненного с возможностью сканирования, который представляет указанное устройство в инфраструктуре FDT;

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

сканирование указанной линии связи с целью обнаружения указанного устройства с использованием указанного экземпляра, выполненного с возможностью сканирования DTM; и

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

2. Способ по п.1, отличающийся тем, что дополнительно включает в себя:

соединение указанного экземпляра, выполненного с возможностью сканирования DTM, с приложением инфраструктуры; и

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

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

3. Способ по п.2, отличающийся тем, что дополнительно включает в себя:

сохранение адреса обнаруженного устройства в памяти;

продолжение сохранения адреса в памяти в случае, если линия связи становится недоступной; и

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

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

5. Способ по п.4, отличающийся тем, что сканирование линии связи включает в себя:

отправление коммуникационному DTM сообщения, включающего команду, адресованную устройству; и

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

6. Способ по п.1, отличающийся тем, что дополнительно включает в себя получение по меньшей мере одного из параметров, а именно типа устройства или марки изготовителя, перед сканированием линии связи;

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

7. Способ по п.1, отличающийся тем, что сканирование линии связи включает получение диапазона адресов, а также обнаружение устройства, имеющего адрес, входящий в диапазон адресов.

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

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

10. Способ по п.1, отличающийся тем, что линия связи поддерживает протокол связи HART^®; а сканирование линии связи включает отправление HART-команды "0" по каждому доступному адресу.

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

12. Способ по п.1, отличающийся тем, что дополнительно включает в себя:

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

13. Способ по п.1, отличающийся тем, что дополнительно включает в себя:

соединение указанного экземпляра, выполненного с возможностью сканирования DTM, со вторым каналом связи, соответствующим второй линии связи;

сканирование второй линии связи с целью обнаружения второго устройства, имеющего коммуникационное соединение со второй линией связи; и

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

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

15. Менеджер типов устройств (DTM) типа "устройство", выполненный с возможностью сканирования и работающий в инфраструктуре приложений, выполненной в соответствии со стандартом FDT, причем DTM представляет собой по меньшей мере одно устройство, работающее в среде управления процессами, содержащий:

функциональный модуль для поддержания функций, относящихся к по меньшей мере одному устройству;

первый интерфейс, соединенный с функциональным модулем для взаимодействия с инфраструктурой приложений;

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

16. DTM по п.15, отличающийся тем, что дополнительно включает в себя постоянную память для хранения адреса по меньшей мере одного обнаруженного устройства.

17. DTM по п.15, отличающийся тем, что коммуникационный DTM, работающий в инфраструктуре приложений FDT, обеспечивает канал связи.

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

19. DTM по п.15, отличающийся тем, что первая линия связи поддерживает протокол связи HART ^®, а вторая линия связи поддерживает протокол связи Foundation Fieldbus H1.

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

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

22. Способ связи с устройством, работающим в сети управления процессами, включающий в себя:

соединение с каналом связи, использующим протокол связи, экземпляра DTM типа "устройство", выполненного с возможностью сканирования и работающего в инфраструктуре приложений, выполненной в соответствии со стандартом FDT;

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

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

24. Способ по п.22, отличающийся тем, что дополнительно включает в себя:

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

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

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

27. Способ по п.22, отличающийся тем, что дополнительно включает в себя:

присвоение идентификатора каждому обнаруженному устройству;

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

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

Описание изобретения к патенту

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

В настоящей заявке используются материалы заявки на патент США № 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 устройства могут быть реализованы из разных классов, каждый из которых разработан конкретно под определенный протокол. С этой целью выполненный с возможностью сканирования DTM 300 или 304 устройства может включать функцию сканирования, отвечающую за выполнение одной или нескольких операций сканирования, или "обнаружения" на определенной линии связи (например, электрической линии, логическом канале, шине и т.п.). Изготовитель соответствующего устройства, или иной поставщик выполненного с возможностью сканирования DTM 300 или 304 устройства может обеспечивать функцию сканирования в виде встроенного элемента DTM 300 или 304. В другом варианте, функция сканирования может быть обеспечена в виде дополнительного компонента (плагина), совместимого с определенным DTM устройства, благодаря чему DTM устройства может приобрести способность к сканированию при подключении плагина.

Функция сканирования может быть выполнена с возможностью распознавания определенных специфических аспектов протокола, по которому соответствующий экземпляр выполненного с возможностью сканирования DTM устройства выполняет операцию сканирования. Например, функция сканирования выполненного с возможностью сканирования DTM 304 устройства может быть запрограммирована на отправление HART-команды "0" на коммуникационный DTM 260. Как понятно человеку, знакомому с HART, указанная команда может принять короткий либо длинный адрес HART и, при условии правильной доставки на устройство HART, заставить устройство HART ответить сообщением, содержащим идентификационные параметры устройства. В других вариантах выполнения, функция сканирования может отправлять другую команду или последовательность команд с целью обнаружения устройств HART на определенном канале, таком как канал связи 263. В целом, функция сканирования может сканировать на наличие сигналов тревог, опрашивать датчики (например, первичные датчики), запрашивать информацию о состоянии, или выполнять сходную неинтрузивную или минимально интрузивную операцию с целью обнаружения полевых устройств. В некоторых вариантах выполнения, функция сканирования опрашивает устройства и одновременно получает дополнительную полезную информацию, такую как состояние устройства. В других вариантах выполнения, функция сканирования может иметь мало или вовсе не иметь информации об одном или нескольких протоколах, поддерживаемых коммуникационным DTM 260, и может сканировать линию или канал связи, посылая команды высокого уровня на DTM 250 связи. Коммуникационный DTM может соответствующим образом передавать указанные команды физическим устройствам, а также передавать соответствующие отклики выполненному с возможностью сканирования DTM 304 устройства.

Как показано на фиг.3, выполненный с возможностью сканирования DTM 304 может давать отчет о списке устройств внешнему модулю 310 ПО по завершении операции обнаружения устройств функцией сканирования. Выполненный с возможностью сканирования DTM 304 может быть запрограммирован на обнаружение устройств любого типа на конкретном канале. Внешний модуль 310 ПО может отображать список устройств и, при желании, состояние каждого обнаруженного устройства для пользователя, и может затем принимать команды для конкретного устройства. Как описано выше, внешний модуль 310 ПО может обмениваться данными с каждым обнаруженным полевым устройством при помощи выполненного с возможностью сканирования DTM 300 или 304 устройства путем указания адреса устройства, полученного от DTM 300 или 304, или логического идентификатора, присвоенного DTM 300 или 304. Таким образом, один экземпляр выполненного с возможностью сканирования DTM устройства, такой как DTM 304, может автоматически обнаруживать устройства, доступные на канале связи 263, и может обеспечить связь с каждым из множества устройств 268. Выполненный с возможностью сканирования DTM устройства, выполненный согласно настоящему изобретению, может таким образом устранить необходимость в реализации отдельного объекта DTM устройства для каждого устройства, а также необходимость запроса адресной информации от пользователя.

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

Фиг.4 иллюстрирует еще один возможный вариант выполненного с возможностью сканирования DTM. В этом примере реализации приложения 311 инфраструктуры FDT, выполненный с возможностью сканирования DTM 312 устройства выполняет все функции, связанные с DTM устройства в любой инфраструктуре FDT. В частности, выполненный с возможностью сканирования DTM 312 может включать данные и функции, специфичные для полевых устройств 242 и 244, и может взаимодействовать с графической средой, обеспеченной приложением 311 инфраструктуры FDT. Сходным образом, выполненный с возможностью сканирования DTM 314 устройства может включать специфичную для устройств информацию, соответствующую одному или нескольким устройствам, соединенным при помощи HART-модема 262. Выполненный с возможностью сканирования DTM 312 не требует прямого предоставления адресов полевых устройств 242 и 244. Вместо этого, выполненный с возможностью сканирования DTM 312 сканирует канал связи аналогично DTM 300 или 304 и автоматически обнаруживает полевые устройства совпадающего типа. После завершения процесса обнаружения выполненный с возможностью сканирования DTM 312 может связываться с обоими полевыми устройствами 242 и 244. Однако в других вариантах может быть предпочтительным выполнение отдельного экземпляра, выполненного с возможностью сканирования DTM 312 для каждого устройства, например, с целью упрощения управления устройствами в среде FDT. В одном возможном варианте осуществления отдельный экземпляр выполненного с возможностью сканирования DTM 312 может быть выполнен для каждого автоматически обнаруживаемого полевого устройства и может быть связан с адресом обнаруженного полевого устройства. Приложение 311 инфраструктуры FDT может отображать пользователю описание устройства, физический адрес, и прочую сопутствующую информацию для каждого обнаруженного устройства при помощи стандартных интерфейсов FDT.

Сходно с вариантом выполнения, показанным на фиг.3, пользователю могут дополнительно предоставляться опции, связанные с определением устройства, такие как марка изготовителя и тип устройства. Приложение 311 инфраструктуры FDT может обеспечивать указанные и другие опции при помощи стандартных графических и пользовательских интерфейсов FDT. Для знакомого с данной областью техники человека очевидно, что в некоторых приложениях, таких как управление ресурсами, может быть интересен полный список всех устройств, соединенных с определенной линией связи или шиной, в то время, как в других приложениях, таких как управление клапанами, может быть интересен конкретный тип устройства. Таким образом, различные опции обнаружения устройств могут быть предпочтительны в различных приложениях 302 или 311 инфраструктуры FDT, или внешних приложениях 310 ПО.

Как показано на фиг.5, приложение 320 инфраструктуры FDT может включать способный к множественному сканированию DTM 322, взаимодействующий с внешним ПО 324. Предполагается, что в соответствии с возможным расширением существующего стандарта FDT один экземпляр DTM устройства может быть способен взаимодействовать с несколькими коммуникационными DTM. Как показано на фиг.5, способный к множественному сканированию DTM 322 устройства связывается с коммуникационным DTM 260 HART и с коммуникационным DTM 220 FF H1. В соответствии с данным возможным вариантом выполнения, DTM 322 может также связываться с другими коммуникационными DTM, поддерживающими протоколы HART, FF, PROFIBUS или иные протоколы. В этом варианте выполнения, DTM 322 может включать функцию сканирования, осуществляющую вложенный поиск. В частности, функция сканирования DTM 322 может проходить по каждому из коммуникационных DTM, с которыми соединен DTM 322, определять и устанавливать связь с доступными полевыми устройствами и сообщать о результатах обнаружения внешнему ПО 324.

Фиг.5А иллюстрирует другой возможный вариант выполнения, согласно которому приложения 326 и 328 инфраструктуры FDT параллельно работают на платформе 202. Оба приложения 326 и 328 инфраструктуры FDT могут взаимодействовать с внешним модулем 310 ПО. Оба приложения 326 и 328 инфраструктуры FDT могут быть автономными и могут, например, поддерживать отдельные базы 210 и 330 данных. Приложение 326 инфраструктуры FDT может в первую очередь поддерживать связь по протоколу FF и может частично отвечать за управление сегментом 224 FF H1 посредством коммуникационного DTM 220. В то же время, приложение 328 инфраструктуры FDT может отвечать за связь по протоколу HART и может управлять HART-модемом 262 при помощи коммуникационного DTM 260. Подобно варианту осуществления, описанному выше со ссылкой на фиг.3, выполненный с возможностью сканирования DTM 300 устройства может обнаруживать, сообщать о и управлять полевыми устройствами при помощи коммуникационного DTM 220, а выполненный с возможностью сканирования DTM 304 устройства может управлять устройствами HART при помощи коммуникационного DTM 260. Естественно, каждое из приложений 326 и 328 инфраструктуры FDT может иметь несколько выполненных с возможностью сканирования DTM, ответственных за различные сегменты FF H1, модемы HART, и другие каналы связи. Более того, внешний модуль 310 ПО может быть выполнен в равной степени совместимым с единичными или множественными приложениями инфраструктуры FDT, ответственными за различные или сходные линии связи. При этом соединения между приложениями инфраструктуры FDT и внешним ПО, таким как модуль 310 ПО, могут быть "прозрачными" для пользователя во время установки, конфигурации или работы внешнего модуля 310 ПО.

Еще в одном варианте выполнения внешний модуль 310 ПО или сходное программное приложение, работающее вне инфраструктуры FDT, может связываться с несколькими приложениями инфраструктуры FDT, работающими на различных физических серверах. Например, терминал 120 может выполнять приложение 326 инфраструктуры FDT, а терминал 122 может выполнять приложение 328 инфраструктуры FDT. Каждый из терминалов 326 и 328 может работать на различных версиях ОС Windows, или, в случае возможного расширения FDT, на другой операционной системе, поддерживающей стандарт FDT. Внешний модуль 310 ПО может работать на терминалах 120 и 122 распределенным образом. В другом варианте выполнения внешнее ПО может работать на едином интеллектуальном сервере или терминале, таком как терминал 120. В этом и сходных случаях, внешний модуль 310 ПО может связываться с приложениями инфраструктуры FDT при помощи протоколов TCP/IP или UDP/IP, удаленного вызова процедур (RPC) или других подходящих средств удаленной связи между процессами. В другом варианте выполнения, как внешний модуль 310 ПО, так и приложения 326 и 328 инфраструктуры FDT могут основываться на технологии распределенной объектной модели программных компонентов (Distributed Component Object Model, DCOM) для обмена данными.

Как в целом показано на фиг.3, 5 и 5А, выполненный с возможностью сканирования DTM 300 или 304 устройства, а также выполненный с возможностью множественного сканирования DTM 322 устройства может быть дополнительно выполнен с возможностью восстановления соединения внешнего модуля 310 или 324 ПО с соответствующим полевым устройством, если соединение через выполненный с возможностью сканирования DTM потеряно. В частности, выполненный с возможностью сканирования DTM устройства может хранить адрес каждого обнаруженного устройства, тем самым устраняя необходимость перезапуска функции сканирования каждый раз, когда утеряно одно или несколько соединений с устройствами. Также в отношении фиг.3-5А в целом необходимо отметить, что выполненный с возможностью сканирования DTM устройства или выполненный с возможностью множественного сканирования DTM устройства может соединяться с коммуникационным DTM при помощи DTM шлюза. Например, выполненный с возможностью сканирования DTM 300 устройства может соединяться с коммуникационным DTM 220 через DTM шлюзного типа, который обеспечивает трансляцию протоколов PROFIBUS/FF H1.

Фиг.6 иллюстрирует блок-схему процедуры 350, которая может быть выполнена способной к сканированию DTM 300, 304, 312 или 314 устройства. На шаге 352 экземпляр выполненного с возможностью сканирования DTM устройства создается и инициализируется в приложении инфраструктуры FDT. Как описано выше, один экземпляр выполненного с возможностью сканирования DTM устройства может одновременно поддерживать несколько полевых устройств, если выполненный с возможностью сканирования DTM устройства запрограммирован или сконфигурирован с обеспечением достаточного количества относящейся к устройству информации. Созданный выполненным с возможностью сканирования DTM устройства может соединяться с подходящим коммуникационным DTM как часть последовательности инициализации, выполняемой на шаге 352. На шаге 354 процедура 350 получает границы диапазона адресов, связанного с конкретным мультиплексором, сегментом FF Н1 или подобным соединением. Процедура 350 может также получать границы адресов от внешнего ПО, работающего вне приложения инфраструктуры FDT. В другом варианте, процедура 350 может получать границы адресов от приложения инфраструктуры FDT при помощи стандартных интерфейсов FDT. Еще в одном варианте, границы устройств могут быть предоставлены в виде списка и могут содержать несколько неперекрывающихся диапазонов адресов. Однако иллюстрируемая процедура 350 относится к варианту выполнения, поддерживающему один диапазон адресов, ограниченный всего двумя адресами.

Затем процедура 350 может пройти по каждому адресу в заданном диапазоне, пытаясь обнаружить физическое устройство по каждому адресу. На шаге 356 процедура 350 может генерировать следующий адрес путем повышения значения предыдущего адреса, или, например, понизить границу диапазона. На шаге 358 процедура 350 может проверить, превысил ли следующий адрес верхнюю границу заданного диапазона адресов. Если следующий адрес находится в рамках заданного диапазона, процедура 350 может определить наличие или отсутствие физического устройства по следующему адресу. В частности, процедура 350 может запустить функцию опроса согласно одному из вариантов выполнения, описанному выше.

Если на шаге 362 процедура 350 обнаруживает физическое устройство, процедура 350 может добавить адрес обнаруженного устройства в список. Указанный шаг проиллюстрирован в блоке 364. Как описано выше, процедура 350 может также получить дополнительную информацию, такую как рабочее состояние устройства, список необработанных сигналов тревоги, сгенерированных устройством, необработанные измерения, собранные устройством, и сходные данные. Процедура 350 может хранить указанную информацию для каждого обнаруженного устройства вместе с физическим адресом обнаруженного устройства. Выполненный с возможностью сканирования DTM устройства, запускающий процедуру 350, может затем предоставить собранную информацию внешнему ПО или приложению инфраструктуры FDT, которое, в свою очередь, может отобразить указанную информацию в текстовом или графическом виде. Наконец, процедура 350 может сообщить о завершении сканирования внешнему ПО или пользователю, работающему с приложением инфраструктуры FDT, на шаге 366.

На фиг.7 процедура 380 может соответствовать другому возможному варианту выполнения способного к сканированию DTM устройства. Выполненный с возможностью сканирования DTM устройства подобным образом может быть создан на шаге 382. На шаге 384 процедура 380 может получить данные о марке изготовителя для сравнения указанных данных с информацией, сообщенной каждым физическим устройством, присутствующим на определенном канале связи. Затем процедура 380 может получить данные о типе устройства, чтобы дополнительно сузить поиск одного или нескольких искомых устройств. Естественно, другие варианты выполнения процедуры 380 могут включать в себя лишь один из типов данных о марке изготовителя или о типе устройства.

На шаге 388, процедура 380 может сканировать канал связи для обнаружения физических устройств. В данном варианте выполнения процедура 380 получает полный список физических устройств и отфильтровывает полученный список на шаге 390. Другими словами, процедура 380 может отправить общую команду через коммуникационный DTM, к которому присоединен выполненный с возможностью сканирования DTM, и как только каждое доступное устройство предоставит достаточную информацию об изготовителе и типе устройства, процедура 380 может сравнить информацию, полученную от каждого устройства, с критериями, полученными на шагах 384 и 386. В другом варианте процедура 380 может включать, по крайней мере в некоторых случаях, команду, специфичную для типа устройств или изготовителя, указанного на шагах 384 и 386. В этом случае, процедура 380 может снизить нагрузку на канал связи путем использования широковещательной или многоадресной команды, либо итерационного отправления команды на каждый возможный адрес, ожидая ответа лишь от тех устройств, которые соответствуют заданному типу устройств или марке изготовителя. Наконец, процедура 380 может передать доступную информацию о каждом обнаруженном устройстве внешнему ПО или приложению инфраструктуры FDT на шаге 392.

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

Немаловажно, что другие варианты выполнения, основывающиеся на раскрытии настоящего изобретения, могут сочетать некоторые элементы процедур 350 и 380, например, с целью поиска устройств определенного типа, которые также находятся в определенном диапазоне адресов. Также нужно отметить, что несмотря на то, что описанные выше варианты выполнения ссылаются на существующий стандарт FDT, принципы и алгоритмы, обозначенные выше, также применимы к другим версиям FDT, включая те, которые могут быть разработаны в будущем, а также к сходным инфраструктурам для обеспечения связи между модулем ПО и физическим устройством. В частности, инфраструктура FDT может использовать иную платформу, нежели ОС Windows. Следовательно, FDT может использовать иные технологии вместо (или в дополнение к) СОМ и ActiveX, а также может переопределить некоторые интерфейсы, используемые приложениями инфраструктуры и DTM. Необходимо отметить, что варианты выполнения, описанные выше, могут быть применены с другими платформами и определениями интерфейса.

Из настоящего описания сведущему в области техники человеку ясно, что выполненный с возможностью сканирования DTM устройства (такой как выполненный с возможностью сканирования DTM 300, 304, 312, 314 или 322 устройства) позволяет разработчику или пользователю приложения инфраструктуры FDT реализовать объект DTM, который включает функциональность, соответствующую конкретному устройству, а также обеспечивает связь между указанным устройством и модулем ПО без необходимости четкого конфигурирования объекта DTM с адресом устройства. Другими словами, выполненный с возможностью сканирования DTM значительно упрощает конфигурирование и управление устройствами в инфраструктуре FDT и снижает вероятность человеческой ошибки путем либо полного устранения этапа конфигурирования DTM устройства с соответствующим адресом, либо, при других сценариях и вариантах осуществления, путем предоставления списка обнаруженных устройств и/или адресов пользователю. Более того, некоторые варианты выполнения выполненного с возможностью сканирования DTM устройства позволяют модулю ПО связываться с несколькими физическими устройствами через один экземпляр выполненного с возможностью сканирования DTM устройства. Таким образом, представляя одно или несколько физических устройств в программной инфраструктуре, выполненный с возможностью сканирования DTM устройства обеспечивает высокий уровень независимости, особенно удобный для эффективного управления сложными системами (например, управление процессами на производственном предприятим, имеющем сотни полевых устройств).

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

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