СОЗДАНИЕ ИНТЕГРИРОВАННЫХ ПРЕДУПРЕЖДЕНИЙ В ТЕХНОЛОГИЧЕСКОЙ УСТАНОВКЕ Российский патент 2009 года по МПК G06F1/00 

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

Настоящая заявка частично продолжает и претендует на приоритет в отношении патентной заявки США №10/104586 «Integrated Device Alerts in a Process Control System», поданной 22 марта 2002 года, которая частично продолжает и претендует на приоритет в отношении патентной заявки США № 09/896967 «Enhanced Hart Device Alerts in a Process Control System», поданной 29 июня 2001 года, которая, в свою очередь, частично продолжает и претендует на приоритет в отношении патентной заявки США №09/861790 «Enhanced Fieldbus Device Alerts in a Process Control System», поданной 21 мая 2001 года, которая, в свою очередь, не является предварительной и претендует на приоритет в отношении предварительной патентной заявки США № 60/273164 «Asset Utilization Expert in a Process Control Plant», поданной 1 марта 2001 года.

Помимо этого, настоящая заявка частично продолжает и претендует на приоритет в отношении патентной заявки США №10/087308 «Data Sharing in a Process Plant», поданной 1 марта 2002 года, которая не является предварительной и претендует на приоритет в отношении предварительной заявки США №60/273164 «Asset Utilization Expert in a Process Control Plant», поданной 1 марта 2001 года. Патентная заявка США № 10/087308 также частично продолжает и претендует на приоритет в отношении патентной заявки США №09/953811 «Fusion of Process Performance Monitoring with Process Equipment Monitoring and Control», поданной 17 сентября 2001 года, которая, в свою очередь, частично продолжает и претендует на приоритет в отношении патентной заявки США № 09/707580 «Integrated Alarm Display in a Process Control Network», поданной 7 ноября 2000 года, и которая также частично продолжает и претендует на приоритет в отношении патентной заявки США № 09/256585 «Diagnostics in a Process Control System», поданной 22 февраля 1999 года.

Вышеупомянутые патентные заявки целиком и во всех своих аспектах включены в настоящее описание в качестве ссылки.

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

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

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

Системы управления технологическими процессами типа тех, которые используются в технологических процессах химической, нефтяной или других отраслей, обычно включают в себя один или несколько централизованных или децентрализованных технологических контроллеров, имеющих связь по меньшей мере с одной ведущей рабочей станцией или рабочей станцией оператора и с одним или несколькими управляющими и контрольно-измерительными устройствами, такими как устройства, работающие в полевых условиях, через аналоговые, цифровые или комбинированные аналого-цифровые шины. Устройства, работающие в полевых условиях (далее «полевые устройства»), которые могут представлять собой, например, вентили, вентильные позиционеры, переключатели, первичные измерительные преобразователи и датчики (например, датчики температуры, давления и расхода), выполняют такие функции в технологическом процессе, как открывание или закрывание вентилей и измерение параметров технологического процесса. Технологический контроллер принимает сигналы, показывающие результаты технологических измерений, или переменные технологического процесса, сформированные полевыми устройствами или связанные с ними, и/или другую информацию, относящуюся к полевым устройствам, использует эту информацию для реализации программы управления, а затем формирует сигналы управления, которые посылаются по одной или нескольким шинам на полевые устройства для управления ходом технологического процесса. Обычно обеспечивается доступность информации от полевых устройств и контроллера одному или нескольким приложениям, выполняющимся на рабочей станции оператора, чтобы дать возможность оператору реализовать требуемые функции в отношении технологического процесса, такие как наблюдение за текущим состоянием технологического процесса, модификация хода выполнения технологического процесса и т.д.

В системе управления технологическим процессом Delta^TM, поставляемой компанией Fisher Rosemount Systems, Inc., для выполнения операций управления используются функциональные блоки, размещенные или установленные в контроллерах или других полевых устройствах. Контроллеры, а в некоторых случаях, полевые устройства способны хранить и обеспечивать выполнение одного или нескольких функциональных блоков, каждый из которых принимает входные сигналы от других функциональных блоков и/или выдает выходные сигналы на другие функциональные блоки (либо в том же самом устройстве, либо в других устройствах), и выполнять некоторую операцию управления технологическим процессом, такую как измерение или определение параметра технологического процесса, управление устройством или выполнение такой операции управления, как реализация программы пропорционально-интегрально-дифференциального (PID) управления. Другие функциональные блоки в системе управления технологическим процессом выполнены с возможностью осуществления их связи друг с другом (например, в одном устройстве или по шине) для формирования одного или нескольких контуров управления технологическим процессом, отдельные операции которых могут быть распределены по всей системе управления технологическим процессом. Кроме того, как известно, вдобавок к функциональным блокам устройства FOUNDATION Fieldbus (далее просто Fieldbus) могут иметь каждое один или несколько связанных ресурсных блоков и/или блоков преобразователей, которые представляют различные возможности этого устройства. Например, первичный измерительный преобразователь температуры Fieldbus, имеющий два чувствительных элемента для измерения температуры, может включать в себя два блока преобразователей (то есть по одному на каждый чувствительный элемент) и функциональный блок, который считывает выходные сигналы двух чувствительных элементов (через блоки преобразователей) для формирования среднего значения температуры.

Обычно функциональные блоки, блоки преобразователей и источников либо устройства, в которых эти блоки реализованы, сконфигурированы для обнаружения ошибок, отказов или выявления проблем, которые появляются в контурах управления технологическим процессом, блоках, устройствах и т.д., и для посылки сигнала (либо автоматически, как в случае с устройствами Fieldbus, либо как реакция на запрос при опросе, как в случае с устройствами HART), такого как аварийное сообщение или предупредительное сообщение, для уведомления оператора на рабочей станции оператора или другом пользовательском интерфейсе о том, что в системе управления технологическим процессом или в контуре управления системы управления технологическим процессом возникла нежелательная ситуация. Такие аварийные сигналы или предупреждения могут указывать, например, что блок потерял связь, что блок принял или сформировал выходной сигнал, лежащий вне диапазона входных или выходных значений, что в блоке произошел отказ или возникла иная нежелательная ситуация и т.д. В существующих на сегодня системах обработки и отображения аварийных сигналов приложение, выполняемое, например, в интерфейсе/рабочей станции оператора, может быть сконфигурировано для приема сообщений, содержащих технологические аварийные сигналы, относящиеся к ходу технологического процесса, и для отображения этих технологических аварийных сигналов в ясном и удобном виде, чтобы дать возможность оператору организованно и логично распорядиться этими аварийными сигналами. Такая система интерфейса оператора описана в патенте США № 5768119 “Process Control System Including Alarm Priority Adjustment”, содержание которого включено в настоящее описание в качестве ссылки.

В прошлом известные полевые устройства использовались в системах управления технологическими процессами для посылки аналоговых сигналов, таких как, например, сигналы в диапазоне от 4 до 20 миллиампер (мА), в технологический контроллер и приема этих сигналов от контроллера через аналоговую шину или аналоговые линии. Однако эти сигналы в диапазоне от 4 до 20 мА ограничены по своей природе, поскольку они показывают только результаты технологических измерений, выполненных устройством, либо сигналы управления технологическим процессом, сформированные контроллером, который необходим для управления работой устройства во время его эксплуатации. В результате, стандартные устройства, работающие в диапазоне 4-20 мА, не способны создавать аварийные сигналы или предупреждения, относящиеся к работоспособности или состоянию устройств. Таким образом, аварийные сигналы, связанные со статусом или состоянием этих устройств, в системах управления технологическими процессами обычно отсутствуют.

В последнее время в индустрии управления технологическими процессами в большом количестве появились «интеллектуальные» полевые устройства, которые включают в себя микропроцессор и память. Был разработан ряд открытых протоколов связи для «интеллектуальных» устройств, таких как протоколы Fieldbus, HART®, PROFIBUS®, WORLDFIB®, Device-Net® и CAN, позволяющие использовать интеллектуальные полевые устройства, выпущенные различными производителями, вместе в одной и той же сети управления технологическими процессами. Вдобавок, для выполнения основной функции в технологическом процессе интеллектуальное полевое устройство может запоминать данные, относящиеся к этому устройству, осуществлять связь с контроллером и/или другими устройствами в цифровом или комбинированном, то есть цифроаналоговом формате, а также может решать вторичные задачи, такие как самокалибровка, идентификация, диагностика и т.д. Важно, что устройства, совместимые по меньшей мере с некоторыми из этих протоколов (такими как протоколы HART и Fieldbus), способны обнаруживать проблемы, возникающие в самом устройстве, и способны формировать и посылать сообщения с аварийными сигналами или предупреждениями, указывающие на обнаруженные проблемы, соответствующим операторам, обслуживающему персоналу, инженерному персоналу и соответствующим системам, ответственным за функционирование системы управления технологическим процессом.

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

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

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

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

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

Общеизвестно, что блоки (то есть, блоки преобразователей, ресурсные и функциональные блоки) в устройствах Fieldbus способны предоставлять аварийное уведомление или посылать параметр BLOCK_ALM и параметр описания или состояния (статуса) аварийной ситуации BLOCK_ERR. В сущности говоря, параметр BLOCK_ALM позволяет устройству Fieldbus сообщать пользователю или оператору системы через контроллер и рабочую станцию о том, что в устройстве Fieldbus существует аварийное состояние (статус). Таким образом, параметр BLOCK_ERR определяет, какие из различных шестнадцати возможных статусов аварийных сигналов или предупреждений были обнаружены устройством Fieldbus, которое сообщает об активном статусе аварийного сигнала через параметр BLOCK_ALM. Как известно, параметр BLOCK_ERR включает в себя шестнадцать бит, каждый из которых представляет один из шестнадцати возможных заранее определенных статусов аварийного сигнала или предупреждения, которые могут возникнуть в связи с конкретным блоком конкретного устройства Fieldbus. Шестнадцать ранее определенных статусов аварийного сигнала или предупреждения включают в себя: статус, требующий технического обслуживания устройства в ближайшем будущем; статус, требующий немедленного технического обслуживания устройства; статус отказа на входе; статус отказа на выходе; статус отказа памяти; статус потери статических данных, иной статус и так далее. Вдобавок к шестнадцати заранее определенным обнаруживаемым статусам аварийного сигнала или предупреждения некоторые производители устройств Fieldbus поставляют устройства Fieldbus, которые содержат функцию диагностики для обнаружения других статусов. Например, устройство Fieldbus может обнаружить трубопроводы с засоренными вентилями или отказ привода вентиля, может обеспечить сигнал рабочего хода и может сообщить о статусах других типов, установив бит «иное» в состояние «1» в параметре BLOCK_ERR, и сообщить об ином статусе через параметр BLOCK_ALM. В альтернативном варианте или как дополнение, некоторые изготовители устройств Fieldbus могут сообщать о статусах этих других типов (то есть о тех статусах, которые не совпадают ни с одним из шестнадцати заранее определенных статусов), используя специальные аварийные сигналы и/или параметры поставщика, которые могут значительно варьироваться от поставщика к поставщику устройств.

К сожалению, шестнадцать заранее определенных статусов аварийных сигналов или предупреждений Fieldbus группируются вместе под параметром BLOCK_ERR, и любой один активный статус (то есть статус аварийного сигнала или предупреждения, который был обнаружен устройством) приведет к тому, что параметр BLOCK_ALM сообщит о наличии у устройства активного аварийного сигнала или предупреждения. Таким образом, если первый статус аварийного сигнала или предупреждения становится активным в стандартном устройстве Fieldbus, то параметр BLOCK_ALM доносит этот первый аварийный сигнал или предупреждение, а статусы аварийных сигналов или предупреждений, которые активизируются вслед за первым аварийным сигналом, не сообщаются, пока не будет стерт или подтвержден первый сообщенный аварийный сигнал или предупреждение. В результате статус аварийного сигнала или предупреждения с относительно низким приоритетом может маскировать сообщение о более серьезном статусе, пока пользователь или оператор системы не сотрет или подтвердит первый сообщенный статус с более низким приоритетом. Например, блок в устройстве Fieldbus может обнаружить статус «устройство в ближайшее время нуждается в техническом обслуживании» и сообщить о нем с использованием параметров BLOCK_ERR и BLOCK_ALM. Если после этого устройство обнаруживает статус «устройство нуждается в незамедлительном техническом обслуживании», то этот следующий обнаруженный статус может быть отражен (например, путем установки соответствующего бита в состояние «1») в параметре BLOCK_ERR. Однако параметр BLOCK_ALM не сможет сообщить о более серьезном статусе «устройство нуждается в незамедлительном техническом обслуживании», пока аварийный сигнал или предупреждение, сообщенное в связи со статусом «устройство нуждается в техническом обслуживании в ближайшем будущем», не будет стерто или иным образом подтверждено пользователем системы.

Вдобавок, дополнительно усложняется контроль, обработка и извещение об аварийных сигналах или предупреждениях от интеллектуального полевого устройства согласованным образом, когда множество типов интеллектуальных полевых устройств интегрированы в единую систему управления технологическим процессом. Например, устройства, совместимые с протоколом HART (то есть, HART устройства), часто используют вместе с устройствами Fieldbus для выполнения технологического процесса.

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

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

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

Кроме того, многие технологические установки имеют связанные с ними другие компьютеры, которые выполняют приложения, относящиеся к коммерческим функциям или функциям технического обслуживания. Например, некоторые установки включают в себя компьютеры, которые выполняют приложения, связанные с формированием заказов на сырье, заменой деталей или устройств установки, приложения, относящиеся к прогнозированию продаж и производственных нужд и т.д. Аналогично многие технологические установки и особенно те, в которых используются интеллектуальные полевые устройства, включают в себя приложения, используемые для поддержки контроля и технического обслуживания устройств в установке независимо от того, являются ли эти устройства устройствами управления технологическим процессом и контрольно-измерительными устройствами либо устройствами других типов. Например, приложение Asset Management Solutions (AMS) (Решения по управлению активами), поставляемое фирмой Fisher-Rosemount Systems, Inc., позволяет передавать и запоминать данные, относящиеся к полевым устройствам, для определения и отслеживания рабочего состояния полевых устройств. Пример такой системы раскрыт в патенте США № 5960214 «Integrated Communication Network for use in a Field Device Management System». В некоторых случаях приложение AMS можно использовать для связи с устройствами с целью изменения параметров в устройстве, для того чтобы заставить устройство выполнить такие приложения, как программы самокалибровки или программы самодиагностики, для получения информации о состоянии и степени исправности устройства и т.д. Эта информация может быть сохранена и использована персоналом, обеспечивающим техническое обслуживание, для контроля и технического обслуживания этих устройств. Аналогично имеются приложения других типов, которые используют для контроля устройств других типов, таких как вращающееся оборудование и устройства для производства и подачи электроэнергии. Эти другие приложения обычно доступны персоналу, выполняющему техническое обслуживание, и используются для контроля и технического обслуживания устройств в технологической установке. Однако во многих случаях услуги, относящиеся к контролю хода выполнения технологического процесса и оборудования, могут выполняться внешними обслуживающими организациями. В этих случаях внешние обслуживающие организации получают необходимые им данные, выполняют собственные фирменные приложения для анализа данных и просто выдают результаты и рекомендации персоналу технологической установки. Хотя это было бы полезным, персонал установки практически не способен оценивать необработанные данные измерений либо использовать данные анализа каким-либо другим путем.

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

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

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

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

Кроме того, в настоящее время известен экспертный механизм, который использует переменные управления технологическим процессом и ограниченную информацию о рабочем состоянии программ управления или функциональных блоков или модулей, связанных с программным управлением технологическим процессом, для обнаружения неправильно работающих контуров и предоставления оператору информации о предлагаемых действиях для решения возникшей проблемы. Такой экспертный механизм раскрыт в патентной заявке США № 09/256585 «Diagnostics in a Process Control System», поданной 22 февраля 1999 года, и в патентной заявке США № 09/499445 “Diagnostics Expert in a Process Control System», поданной 7 февраля 2000 года, содержание которых специально включено в настоящее описание в качестве ссылки. Аналогичным образом известны оптимизаторы управления, такие как оптимизаторы, работающие в установке в реальном времени, для оптимизации операций управления технологической установкой. В таких оптимизаторах обычно используются комплексные модели установки для прогнозирования того, как можно изменить входные сигналы для оптимизации работы установки применительно к ряду оптимизируемых переменных, таких как, например, прибыль.

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

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

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

Поскольку по большей части очень разные приложения, используемые для выполнения различных функций в установке, например, операций управления технологическим процессом, операций технического обслуживания и коммерческих операций, разделены, то разные приложения, используемые для решения этих разных задач, не интегрированы и, следовательно, совместно не используют общие данные или информацию. В действительности, многие установки включают в себя только некоторые, а не все приложения указанных разных типов. Более того, даже если в установке имеются все указанные приложения, поскольку эти разные приложения и инструменты анализа используются разным персоналом и поскольку эти инструменты обычно физически находятся в разных местах в установке, имеются небольшие (если они вообще есть) потоки информации из одной функциональной области установки в другую даже в том случае, когда эта информация могла бы оказаться полезной для других функций в установке. Например, такой инструмент, как инструмент для анализа данных по вращающемуся оборудованию, может быть использован обслуживающим персоналом для обнаружения неправильно работающего силового генератора или части вращающегося оборудования (на основе данных типа «нетехнологическая переменная»). Этот инструмент может обнаружить проблему и предупредить обслуживающий персонал о том, что устройство нуждается в калибровке, ремонте или замене. Однако оператор, управляющий технологическим процессом (либо человек, либо экспертная программа), не сможет получить выгоду от использования этой информации, хотя плохо работающее устройство может создать проблемы, которые повлияют на работу контура или какой-то другой компоненты, находящейся под контролем системы управления технологическим процессом. Аналогичным образом, персонал, решающий коммерческие задачи, не узнает об этом факте, хотя неправильно работающее устройство может оказаться тем критическим звеном, которое будет препятствовать оптимальной работе установки с точки зрения требований, предъявляемых коммерческим персоналом. Поскольку эксперт, управляющий технологическим процессом, не знает о проблемах в устройстве, которые могут привести, в конце концов, к неправильному функционированию контура или блока в системе управления технологическим процессом, и поскольку оператор или эксперт, управляющий технологическим процессом, полагает, что данное оборудование работает идеально, то эксперт, управляющий технологическим процессом, может неправильно оценить проблему, которую он обнаружил в контуре управления технологическим процессом, либо может попытаться применить какой-то инструмент, например, настройщик контура, который в действительности никогда не сможет решить эту проблему. Аналогично коммерческий персонал может принять коммерческое решение по работе установки таким образом, что желаемые коммерческие эффекты (такие как оптимизация доходов) не будут достигнуты из-за неправильно работающего устройства.

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

Сущность изобретения

Описанный здесь способ интеграции предупреждений с приоритетами позволяет отображать рабочую информацию, связанную с различными технологическими объектами в технологической установке, во множество общих статусов состояния. Поскольку рабочая информация от различных технологических объектов преобразуется в общие статусы состояния, можно без труда установить относительную важность рабочей информации. Система отображения принимает рабочую информацию, связанную с технологическим объектом в технологической установке. Например, система отображения может принять рабочую информацию, связанную с полевыми устройствами, программными средствами управления технологическим процессом, аппаратными средствами (например, технологическими контроллерами, устройствами ввода/вывода, рабочими станциями оператора и т.д.), системами контроля и диагностики и т.д. Затем система отображения может отобразить рабочее состояние в один из множества статусов состояний. Соответствующий статус состояния может базироваться на информации о рабочем состоянии, а также на дополнительных факторах (например, местоположение технологического объекта или секции технологической установки, в которой находится технологический объект, частота, с которой полевое устройство, программный модуль управления технологическим процессом и т.д. создает предупреждения, аварийные сигналы, статусы состояния и т.д., тип полевого устройства и т.д.). Затем может быть создано предупредительное сообщение, связанное с технологическим объектом, причем предупредительное сообщение указывает на один статус состояния из множества статусов состояния.

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

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

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

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

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

Фиг.5А и 5В - иллюстрация одного способа организации и запоминания данных, собранных от многочисленных источников данных, в базе данных конфигурации таким образом, что они становятся общедоступными другим приложениям;

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

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

Фиг.7В - блок-схема модели, используемой для имитации работы блока в модели области по фиг.7А;

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

Фиг.9 - пример таблицы, которая иллюстрирует один возможный способ создания индексов для различных уровней системной иерархии;

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

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

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

Фиг.13 - пример отображения в виде графика, которое может быть предоставлено графическим интерфейсом пользователя;

Фиг.14 - пример графического отображения, которое может быть предоставлено графическим интерфейсом пользователя;

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

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

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

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

Фиг.19 - блок-схема информационных потоков, касающихся экспертной программы использования активов в установке по фиг.1;

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

Фиг.21 - более подробная блок-схема средств дистанционного контроля по фиг.20;

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

Фиг.23 - блок-схема рабочей станции, где реализована система отображения и интерфейса для аварийной сигнализации, которую можно использовать в системе управления технологическим процессом, показанной на фиг.1;

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

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

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

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

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

Фиг.29 - более подробная блок-схема системы управления событиями, показанной на фиг.7; и

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

Подробное описание изобретения

Обратимся к фиг.1, где типовая установка 10 для управления технологическим процессом включает в себя ряд систем для решения коммерческих задач и других компьютерных систем, соединенных с несколькими системами управления и технического обслуживания через одну или несколько систем. Показанная установка 10 для управления технологическим процессом также включает в себя одну или несколько систем 12 и 14 управления технологическим процессом. Система 12 управления технологическим процессом может представлять собой стандартную систему управления технологическим процессом, такую как система PROVOX или RS3 или любую другую распределенную систему управления (DCS). Система 12, показанная на фиг.1, включает в себя интерфейс 12А оператора, подсоединенный к контроллеру 12В и платам 12С ввода/вывода (I/O), которые в свою очередь соединены с различными полевыми устройствами, такими как аналоговые полевые устройства 15 типа HART (дистанционные первичные измерительные преобразователи с магистральной адресацией). Система 14 управления технологическим процессом, которая может представлять собой распределенную систему управления технологическим процессом, включает в себя один или несколько интерфейсов 14А оператора, подсоединенных к одному или нескольким распределенным контроллерам 14В через шину, такую как шина Ethernet. Контроллеры 14В могут являться, например, контроллерами DeltaV^TM, поставляемыми фирмой Fisher Rosemount Systems, Inc. of Austin, Texas, или контроллерами любого другого требуемого типа. Контроллеры 14В подсоединены через устройства ввода-вывода к одному или нескольким полевым устройствам 16, таким как, например, полевые устройства HART или Fieldbus, либо любым другим интеллектуальным или не интеллектуальным полевым устройствам, в том числе, например, устройствам, которые используют любой из протоколов: PROFIBUS®, WORLDFIB®, DeviceNet®, AS Interface и CAN. Как известно, полевые устройства 16 могут предоставлять аналоговую или цифровую информацию контроллерам 14В, связанным с переменными технологического процесса, а также с другой информацией об устройстве. Интерфейсы 14А оператора могут хранить и выполнять инструменты, доступные оператору, управляющему технологическим процессом, для управления ходом технологического процесса, в том числе, например, оптимизаторы управления, экспертные диагностические программы, нейронные сети, средства настройки и т.д.

Кроме того, для выполнения операций технического обслуживания и контроля к системам 12 и 14 управления технологическими процессами либо к отдельным устройствам в них могут быть подсоединены системы технического обслуживания, такие как компьютеры, выполняющие приложение AMS, либо любые другие приложения для контроля и связи с устройствами или оборудованием. Например, компьютер 18 технического обслуживания может быть подсоединен к контроллеру 12В и/или к устройствам 15 через любые требуемые линии или сети связи (в том числе, беспроводные сети или сети для переносных устройств) для осуществления связи и в некоторых случаях реконфигурации либо выполнения других операций по техническому обслуживанию в устройствах 15. Аналогичным образом приложения технического обслуживания, такие как приложение AMS, могут быть установлены и выполняться одним или несколькими интерфейсами 14А пользователя, связанными с распределенной системой 14 управления технологическим процессом, для выполнения функций технического обслуживания и контроля, включая сбор данных, относящихся к рабочему состоянию устройств 16.

Показанная установка 10 для управления технологическим процессом также включает в себя различное вращающееся оборудование 20, такое как турбины, двигатели и т.д., которые подсоединены к компьютеру 22 технического обслуживания через какую-либо постоянно действующую или временную линию связи (такую как шина, система беспроводной связи или переносные устройства, которые подсоединяют к оборудованию 20 для снятия показаний, а затем убирают). Компьютер 22 технического обслуживания может хранить и выполнять известные приложения 23 контроля и диагностики, предоставляемые, например, системами CSI, либо любые другие известные приложения, используемые для диагностирования, контроля и оптимизации рабочего состояния вращающегося оборудования 20. Обслуживающий персонал обычно использует приложения 23 для технического обслуживания и наблюдения за функционированием вращающегося оборудования 20 в установке 10, для выявления проблем, касающихся вращающегося оборудования 20, и определения того, когда вращающееся оборудование 20 следует отремонтировать или заменить, если это потребуется. В некоторых случаях внешние консультанты или обслуживающие организации могут временно собирать данные или проводить измерения, связанные с оборудованием 20, и использовать эти данные для анализа оборудования 20 с целью выявления проблем, неэффективного функционирования или других факторов, влияющих на работу оборудования 20. В этих случаях компьютеры, выполняющие такой анализ, не обязательно подсоединены к остальной части системы 10 через какую-либо линию связи либо имеют с ней лишь временное соединение.

Аналогичным образом система 24 производства и распределения электроэнергии, имеющая оборудование 25 для производства и распределения электроэнергии, которое связано с установкой 10, подсоединена, например, через шину к другому компьютеру 26, который приводит в действие и наблюдает за работой оборудования 25 для производства и распределения электроэнергии в установке 10. Компьютер 26 может выполнять известные приложения 27 для управления и диагностики производства электроэнергии, такие как приложения, предоставляемые, например, компаниями Liebert и ASCO либо другими обслуживающими компаниями, для управления и технического обслуживания оборудования 25 для производства и распределения электроэнергии. Опять же во многих случаях внешние консультанты или обслуживающие организации могут время от времени выполнять измерения или собирать данные, относящиеся к оборудованию 25, и использовать эти данные для анализа оборудования 25 с целью выявления проблем, неэффективного функционирования или других факторов, влияющих на работу оборудования 25. В этих случаях компьютеры (такие как компьютер 26), выполняющие анализ, не обязательно подсоединены к остальной части системы 10 через какую-либо линию связи либо могут иметь с ней лишь временное соединение.

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

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

Для решения этой проблемы предложена система сбора и распределения данных для получения данных от различных источников данных, форматирования этих данных в общеизвестный формат или структуру данных, а затем предоставления этих данных, если это необходимо, любому из комплекта приложений, выполняющихся, например, в компьютерной системе 30, либо используемых рабочими станциями по всей сети управления технологическим процессом. Для обеспечения комбинированного или интегрированного использования данных от ранее несопоставимых и автономных систем предлагается комплект приложений, обеспечивающий более качественное измерение, оценку, управление и представление информации о работе всей установки 10. Как показано на фиг.1, компьютерная система 30 имеет связь с компьютерами или интерфейсами, связанными с различными функциональными системами в установке 10, в том числе функциями 12 и 14 управления технологическим процессом, функциями технического обслуживания, такими как функции, реализованные в компьютерах 18, 14А, 22 и 26, и коммерческими функциями, такими как контроль эффективности технологического процесса. В частности, компьютерная система 30 имеет связь со стандартной системой 12 управления технологическим процессом и интерфейсом 18 технического обслуживания, связанным с этой системой управления, при этом система 30 подсоединена к интерфейсам 14А управления технологическим процессом и/или технического обслуживания распределенной системы 14 управления технологическим процессом и подсоединена к компьютеру 22 технического обслуживания вращающегося оборудования и компьютеру 26 производства и распределения электроэнергии, причем все эти соединения выполнены через шину 32. Шина 32 может использовать любой требуемый или подходящий протокол локальной сети (LAN) или глобальной сети (WAN) для обеспечения связи. Конечно, компьютерная система 30 может быть соединена с указанными различными частями установки 10 через другие линии связи, в том числе стационарные или не стационарные линии связи, проводные линии или линии радиосвязи либо любую физическую среду, такую как провода, беспроводные средства, коаксиальный кабель, телефонный модем, оптическое волокно, оптическая среда, систему метеорной радиосвязи, спутники, с использованием одного из протоколов связи Fieldbus, IEEE 802.3, Bluetooth, X.25 или X400, и т.д.

Как показано на фиг.1, компьютер 30 может также быть соединен через ту же самую или другую сетевую шину 32 с системными компьютерами для решения коммерческих задач и компьютерами 35 и 36 планирования технического обслуживания, которые могут выполнять функции систем планирования ресурсов предприятия (ERP), планирования материальных ресурсов (MRP), моделирования технологического процесса для моделирования показателей эффективности, бухгалтерского учета, оформления производственных заказов клиентов, планирования технического обслуживания, либо любыми другими необходимыми коммерческими приложениями, такими как приложения для оформления заказов на детали, поставки и сырье, приложения для планирования производства и т.д. Компьютер 30, например, через шину 32 также может быть соединен с сетью LAN 37 установки, корпоративной сетью WAN 38, а также с компьютерной системой 40, которая позволяет осуществлять дистанционный контроль или связь с установкой 10 из удаленных мест.

В компьютере 30 может также быть предусмотрена вышеупомянутая система сбора и распределения данных, либо эта система может быть разнесена по множеству мест по всей технологической сети 10 для получения и обработки данных от любого источника данных, такого как системы 12 и 14 контроллеров, системы 22 и 26 контроля, финансовые системы 35, 36 и т.д. Если система сбора и распределения данных находится в компьютере 30, она может получать данные от различных источников данных, таких как контроллеры, приложения для контроля оборудования и финансовых операций, избирательно используя разные форматы данных либо используя общий формат. В одном варианте сообщения по шине 32 передаются с использованием протокола XML. Здесь данные от каждого из компьютеров 12А, 18, 14А, 22, 26, 35, 36 и т.д. упаковываются в упаковщике XML и посылаются на сервер данных XML, который может находиться, например, в компьютере 30. Поскольку XML является описательным языком, этот сервер может обрабатывать данные любого типа. Если необходимо, данные на сервере инкапсулируются и отображаются в новый упаковщик XML, то есть эти данные отображаются из одной схемы XML в одну или несколько других схем XML, которые создаются для каждого приложения, принимающего эти данные. Один способ предоставления такой связи описан в одновременно рассматриваемой патентной заявке США № 09/902201, поданной 10 июля 2001 года под заголовком «Transactional Data Communications for Process Control System», содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки. При использовании этой системы каждый источник данных может упаковывать свои данные, используя схему, понятную или известную этому устройству или приложению, а каждое принимающее приложение может принимать эти данные в другой схеме, используемой или понимаемой принимающим приложением. Сервер конфигурируется для отображения одной схемы в другую в зависимости от источника и адресата (адресатов) данных. Если требуется, сервер может также выполнять некоторые функции обработки данных либо другие функции на основе принятых данных. Правила функции отображения и обработки устанавливаются и запоминаются в сервере перед началом работы описанного здесь набора приложений интеграции данных. Таким образом, данные могут посылаться из одного любого приложения в одно или несколько других приложений.

В другом варианте приложения для сбора и распределения данных могут быть разнесены по сети 10, и сбор данных может выполняться в распределенных пунктах. Затем собранные данные могут быть преобразованы в общий формат в распределенных пунктах и посланы в одно или несколько центральных баз данных для последующего распределения. Таким образом, в общем случае для сбора данных от разных источников данных и предоставления этих данных в общем или согласованном формате в набор приложений, которые могут использовать эти данные, такие как приложения в компьютере 30, предусмотрены одна или несколько стандартных программ сбора данных. Приложения для сбора и распределения данных называются здесь системой сбора и распределения данных, в то время как приложения, которые используют собранные данные (например, которые объединяют эти данные), называются здесь в целом комплектом 50 использования активов.

Приложения в комплекте 50 использования активов используют собранные данные и другую информацию, созданную системами 12 и 14 управления технологическим процессом, системами 18, 22 и 26 технического обслуживания и системами 35 и 36 моделирования коммерческих операций и технологического процесса, а также информацию, созданную средствами анализа данных, реализуемыми в каждой из этих систем. В сущности говоря, набор 50 использования активов может включать в себя одно или несколько приложений дисплея пользователя, таких как приложения, описанные в заявках на патент США №№ 09/256585 или 09/499445, и одну или несколько диагностических экспертных программ или экспертных системных приложений другого типа на основе, например, экспертной системы OZ, поставляемой в настоящее время компанией NEXUS. Однако набор 50 использования активов может использовать экспертную систему любого другого необходимого типа, в том числе, например, систему любого типа для извлечения информации (из данных). Набор 50 использования активов может также включать в себя другие приложения, которые объединяют данные от различных функциональных систем с любой другой целью, такой как обеспечение информацией пользователя, диагностические цели, а также для того, чтобы предпринять такие действия в технологической установке, как операции управления технологическим процессом, операции по замене или ремонту оборудования, изменение типа или объема производимой продукции, формируемое на основе финансовых факторов, показателей эффективности технологического процесса и т.д.

Например, комплект 50 использования активов может включать в себя экспертную программу 59 использования активов, которая собирает данные и другую информацию, созданную системами 12 и 14 управления технологическим процессом, системами 18, 22 и 26 технического обслуживания и системами 35 и 36 для решения коммерческих задач, а также информацию, созданную инструментами анализа данных, выполняемыми каждой из этих систем. Экспертная программа 59 использования активов может базироваться, например, на экспертной системе OZ, поставляемой в настоящее время компанией NEXUS. Однако экспертная программа 59 использования активов может представлять собой экспертную систему любого другого требуемого типа, в том числе, например, систему любого типа для извлечения информации из данных. Важно, что экспертная программа 59 использования активов работает как центр обмена данными и информацией в технологической установке 10 и способна координировать распределение данных или информации от одной функциональной области, такой как область технического обслуживания, в другие функциональные области, такие как функциональные области управления технологическим процессом или коммерческих задач. Экспертная программа 59 использования активов может также использовать собранные данные для создания новой информации или данных, которые могут быть распределены по одной или нескольким компьютерным системам, связанным с различными функциями в установке 10. Кроме того, экспертная программа 59 использования активов может выполнять или следить за выполнением других приложений, которые используют собранные данные для создания данных новых типов, подлежащих использованию в технологической установке 10. Экспертная программа 59 использования активов может также быть реализована как часть системы сбора и распределения данных.

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

В одном случае набор 50 использования активов может обеспечивать несколько приложений, которые используют данные от функций управления технологическим процессом и функций контроля оборудования, и, если требуется, от функций контроля эффективности процесса, выполняемых в сети управления технологическим процессом. Эти приложения могут предоставить координированный дисплей пользователя для отображения информации или атрибутов, касающихся установки, которая использует два или более типа данных управления технологическим процессом, данные моделирования эффективности технологического процесса или данные контроля оборудования. Приложение, связанное с набором 50 использования активов, может также диагностировать состояния или проблемы в установке 10 для управления технологическим процессом на основе данных от двух или более приложений для контроля управления технологическим процессом, приложений для контроля эффективности технологического процесса и приложений для контроля оборудования. Кроме того, приложения, связанные с набором 50 использования активов, могут предпринять действия в технологической установке 10 в соответствии с диагностированной или обнаруженной проблемой, либо могут рекомендовать действия, которые должен предпринять пользователь, который может быть, например, оператором, управляющим технологическим процессом, техником по техническому обслуживанию или менеджером в «головном офисе» установки 10, который отвечает за всю работу установки 10.

В частности, в одном варианте набор 50 использования активов может включать в себя или выполнять программные средства 51 создания индексов, которые собирают или создают индексы, связанные с устройствами типа устройств для управления технологическим процессом и контрольно-измерительных устройств, устройств для производства электроэнергии, вращающегося оборудования, блоков, областей и т.д., либо которые связаны с объектами управления технологическим процессом, такими как контуры и т.д., в установке 10. Затем эти индексы могут быть предоставлены приложениям для управления технологическим процессом, чтобы помочь оптимизировать управление технологическим процессом, и могут быть предоставлены программным средствам или приложениям, решающим коммерческие задачи, для предоставления персоналу, решающему коммерческие задачи, более полной или понятной информации, связанной с работой установки 10. В одном варианте программные средства 51 создания индексов могут быть реализованы как часть экспертной программы 59 использования активов.

Набор 50 использования активов может также предоставлять данные о техническом обслуживании (такие как информация о состоянии устройств) и коммерческие данные (такие как данные, связанные с запланированными заказами, выделенными временными интервалами и т.д.) экспертной программе 52 управления, связанной, например, с системой 14 управления технологическим процессом, чтобы помочь оператору в выполнении операций управления, таких как оптимизация управления. Экспертная программа 52 управления может находиться, например, в интерфейсе 14А пользователя либо в любом другом компьютере, связанном с системой 14 управления, либо, если это потребуется, - в компьютере 30.

Экспертная программа 52 управления, если это потребуется, может представлять собой, например, экспертную программу управления, описанную в заявках на патенты США №№09/256585 и 09/499445, идентифицированных выше. Однако эти экспертные программы управления могут дополнительно включать в себя или использовать данные, относящиеся к состоянию устройств или других аппаратных средств в установке 10 управления технологическим процессом, или данные по эффективности, созданные с использованием моделей эффективности технологического процесса, при принятии решений этими экспертными программами управления. В частности, в прошлом экспертные программы управления для принятия решений или выдачи рекомендаций оператору процесса обычно использовали только данные о переменных процесса и ряд ограниченных данных о состоянии устройств. При использовании информации, предоставляемой или собранной набором 50 использования активов, особенно информации, относящейся к состоянию устройств, такой как информация, предоставляемая компьютерными системами 18, 14А, 22 и 26 и реализованными в них средствами анализа данных, экспертная программа 52 управления может принимать и использовать при принятии решений наряду с информацией о переменных технологического процесса информацию о состоянии устройств, такую как информация о степени исправности, эффективности, загрузке и изменчивости.

Вдобавок, набор 50 использования активов может предоставлять информацию, касающуюся состояний устройств и выполнения действий по управлению в установке 10, системам 35 и 36, решающим коммерческие задачи, при этом приложение или программа 54 формирования нарядов на работу может, например, автоматически формировать наряды на работу и заказы на детали с учетом проблем, обнаруженных в установке 10, либо заказ на поставки может быть оформлен на основе выполняемой работы. Аналогичным образом изменения в системе управления, обнаруженные экспертной программой 59 использования активов, могут заставить системы 35 или 36 для коммерческих задач выполнять приложения, которые осуществляют планирование и поставку заказов, используя, например, программу 54. Таким же образом в системы 35 или 36 для решения коммерческих задач могут быть внесены изменения, касающиеся заказов потребителей и т.д., и эти данные могут посылаться в набор 50 использования активов и в стандартные программы управления или экспертную программу 52 управления, чтобы в результате изменений в управлении начать, например, изготовление новых заказанных продуктов или реализовать изменения, сделанные в системах 35 и 36 для решения коммерческих задач. Конечно, если потребуется, каждая компьютерная система, соединенная с шиной 32, может иметь приложение, функцией которого является получение соответствующих данных от других приложений в компьютере и посылка этих данных, например, в экспертную программу 59 использования активов.

Вдобавок, набор 50 использования активов может посылать информацию в одну или несколько моделей технологического процесса, используемых, например, оптимизаторами 55 в установке 10. Модель 56 технологического процесса и оптимизатор 55 управления могут находиться в компьютере 14А и выполнять одну или несколько стандартных программ 55А, 55В и т.д. оптимизации управления. Вдобавок, или как альтернативный вариант, модели 56 технологического процесса и стандартные программы 55 оптимизатора могут храниться в компьютере 30 и выполняться им либо любым другим компьютером, а необходимые данные могут посылаться экспертной программой 59 использования активов. Результаты, полученные в моделях 56, могут быть введены в экспертную программу 59 использования активов или экспертную программу управления или другую экспертную программу, такую как экспертная программа 52 управления, для выполнения функций моделирования, цели которого более подробно описаны ниже. Однако, в сущности говоря, модели 56 можно использовать для определения эффективности блока или области, данные о которой могут быть затем введены в стандартные программы 55 оптимизатора или отображены пользователю либо использованы для других целей. Модели 56 могут представлять собой такие модели, как модели, разработанные и поставляемые компанией MDC Technology, расположенной в Teeside, England, либо могут быть моделями любых других требуемых типов. Конечно, имеется множество других приложений, которые могут быть предусмотрены в установке 10 и которые могут использовать данные из экспертной программы 59 использования активов, и описанная здесь система не ограничивается упомянутыми здесь конкретными приложениями. Однако набор 50 использования активов в целом помогает оптимизировать использование всех активов в установке 10, позволяя совместно использовать данные и координировать использование активов между всеми функциональными областями установки 10.

Также, в сущности говоря, одна или несколько стандартных программ 58 интерфейса пользователя могут храниться и выполняться одним или несколькими компьютерами в установке 10. Например, компьютер 30, интерфейс 14А пользователя, системный компьютер 35 для решения коммерческих задач либо любой другой компьютер может выполнять стандартную программу 58 интерфейса пользователя. Каждая стандартная программа 58 интерфейса пользователя может принимать или подписываться на информацию от набора 50 использования активов и может предоставлять информацию в набор 50 использования активов, и те же самые или разные наборы данных могут посылаться в каждую из стандартных программ 58 интерфейса пользователя. Любая из стандартных программ 58 интерфейса пользователя может предоставлять информацию различных типов, используя разные экраны для разных пользователей, если это потребуется. Например, одна из стандартных программ 58 интерфейса пользователя может предоставлять экран или набор экранов управляющему оператору или коммерческому персоналу, чтобы позволить этому персоналу установить ограничения или оптимизировать переменные для использования в стандартной программе управления или в стандартной программе оптимизатора управления. Стандартная программа 58 интерфейса пользователя может обеспечить инструмент наведения, который позволяет пользователю координированным образом следить за эффективностью технологического процесса и индексами, создаваемыми программными средствами 51 создания индексов или моделями 56 эффективности технологического процесса. Это средство наведения оператора может также позволить оператору либо любому другому персоналу получать информацию о состояниях устройств, контуров управления, блоков и т.д., и легко найти информацию, касающуюся проблем с этими объектами, если эта информация была обнаружена другими программными средствами в технологической установке 10. Стандартная программа 58 интерфейса пользователя может также предложить экраны контроля эффективности, используя данные контроля эффективности, обеспечиваемые или создаваемые средствами 23 и 27, программами технического обслуживания, такими как приложение AMS, либо любыми другими программами технического обслуживания, или данные, создаваемые моделями, вместе с набором 50 использования активов. Конечно, стандартная программа 58 интерфейса пользователя может предоставить доступ любому пользователю и позволить ему изменить предпочтения или другие переменные, используемые в любой или всех функциональных областях установки 10.

Обратимся теперь к фиг.2, где упрощенная функциональная блок-схема 100 иллюстрирует связи и потоки данных, связанные с описанной здесь системой 102 сбора и распределения данных или используемые ею, причем наличие таких связей и потоков данных позволяет набору 50 использования активов использовать данные от разнородных источников данных. В частности, схема 100 включает в себя систему 102 сбора и распределения данных, которая принимает данные от многочисленных источников данных. Например, источник 104 данных для управления технологическим процессом (который может включать в себя традиционные операции и приложения для управления технологическим процессом, такие как приложения для контроля и управления технологическим процессом, диагностические приложения для управления технологическим процессом, приложения аварийной сигнализации для управления технологическим процессом и т.д.) предоставляет данные системе 102 сбора и распределения данных. Блок 104 может посылать данные, получаемые или создаваемые стандартными или автономными технологическими контроллерами, системой DCS, системой DeltaV, программируемыми контроллерами PLC и т.д. в среде управления технологическим процессом.

Источник 106 данных о степени исправности оборудования или технологического процесса (который может включать в себя традиционные приложения для контроля оборудования, приложения для диагностики оборудования, приложения аварийной сигнализации для оборудования, приложения для анализа нештатных ситуаций, приложения для контроля окружающей среды и т.д.) также посылает данные в систему 102 сбора и распределения данных. В результате источник 106 может посылать данные, получаемые или создаваемые традиционными приложениями или источниками для контроля и диагностики оборудования любого типа, такие как данные, обеспечиваемые CSI, приложением AMS, поставляемым компанией Fisher Rosemount Systems, Inc., приложениями Nexis и т.д.

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

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

Следует заметить, что вдобавок или вместо источников данных, показанных на фиг.2, могут быть предусмотрены любые другие источники данных. Кроме того, данные, предоставляемые источниками данных по фиг.2, могут представлять собой необработанные данные измерений, данные, полученные в результате анализа либо другой процедуры на основе измеренных данных либо некоторую комбинацию тех и других данных. Также понятно, что данные, поступающие от любого или всех источников данных по фиг.2, могут быть измерены, сформированы или переданы в любом формате, в том числе в оригинальных, фирменных форматах, используемых различными организациями или приложениями, которые могут измерять или создавать такие данные. Таким образом, различные полевые устройства могут, например, собирать и создать данные в разных форматах, а затем посылать эти данные в систему 102 сбора и распределения данных. Аналогичным образом, источники 110 финансовых данных, источник 114 данных о коррозии, источники 116 данных аварийной сигнализации и т.д. могут предоставлять данные, измеренные или созданные в любом стандартном или оригинальном, фирменном формате, и могут использовать любые фирменные или общедоступные приложения для измерения или создания данных. Таким образом, в сущности говоря, любые приложения или устройства, используемые в настоящее время (или разработанные для использования в будущем) в среде для управления технологическим процессом для измерения или создания данных, выдачи результатов, заключений, рекомендаций и т.д., могут действовать как источник данных для системы 102 сбора и распределения данных даже в том случае, если эти источники данных частично или полностью являются фирменными по своей природе.

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

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

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

Обратимся теперь к фиг.3, где показана более подробная схема 200 потоков данных, иллюстрирующая потоки данных в установке 10 управления технологическим процессом. Начиная с левой части диаграммы 200, данные, связанные с технологической установкой 10, собираются в разных функциональных областях или разными источниками данных в установке 10. В частности, данные 201 для управления технологическим процессом собираются, например, типовыми устройствами управления технологическим процессом, такими как полевые устройства, устройства ввода/вывода, переносные или дистанционные первичные измерительные преобразователи либо любые другие устройства, которые могут, например, иметь связь с технологическими контроллерами. Аналогичным образом, данные 202 контроля оборудования, связанные с традиционными операциями контроля оборудования, собираются, например, датчиками, устройствами, первичными измерительными преобразователями или любыми другими устройствами в установке 10. Данные 203 об эффективности процесса могут собираться теми же самыми или другими устройствами в установке 10. Если потребуется, финансовые данные могут собираться другими приложениями, выполняемыми в компьютерах установки управления технологическим процессом, как часть данных контроля эффективности. В некоторых случаях собранные данные могут поступать от приложений или источников вне традиционной сети управления технологическим процессом, таких как приложения, принадлежащие обслуживающим организациям или поставщикам услуг и работающие под их управлением. Разумеется, собранные данные могут быть любыми, но не только, из следующих данных: данные об угловом положении вращающегося оборудования, скорости, ускорении (а также результаты преобразования этих данных для получения спектральной плотности, частоты, амплитуды и т.д.), данные о механических напряжениях в оборудовании, данные о деформациях, данные о толщине стенок, данные о распространении и скорости коррозионных процессов, данные о коррозионной активности технологических жидкостей, данные о смазке и износе, данные о состоянии подшипников и уплотнений, данные о скорости утечек и составе утекающих жидкостей и газов, в том числе, но не только, данные о летучих органических и неорганических соединениях, данные о температуре подшипников, данные от акустических преобразователей, данные физических измерений и измерений состава веществ в технологическом процессе и так далее. Эти данные могут быть собраны любым способом, в том числе автоматически или вручную. Таким образом, средства сбора данных могут включать в себя: переносные устройства сбора; стационарные или временно подключаемые устройства для лабораторного химического анализа и физических измерений; устройства, которые периодически получают телеметрические данные (например, по радиоканалам) от удаленных устройств, измеряющих параметры технологического процесса и оборудования; или удаленные мультиплексоры и/или концентраторы либо любые другие устройства сбора данных.

Данные об управлении технологическим процессом, данные контроля оборудования и данные об эффективности технологического процесса могут быть согласованы, проверены, подтверждены и/или отформатированы приложениями 204 для сбора и согласования данных (которые могут являться частью системы 102 сбора и распределения данных по фиг.2), выполняющимися в устройстве сбора данных или в любом другом устройстве, таком как центральный архив данных, технологические контроллеры, приложения для контроля оборудования и т.д., или в любом другом устройстве, которое принимает или обрабатывает эти данные. Конечно, собранные данные могут быть согласованы или переданы любым известным или желаемым образом. Например, данные могут быть представлены в общем формате или масштабе, могут быть преобразованы в различные или стандартные (общие) блоки, могут быть проанализированы с целью обнаружения выбросов, ошибочных или неправильных данных, могут быть проверены или подтверждены любым известным или желаемым способом и т.д. Существует множество известных способов или приемов согласования данных, и можно использовать способ согласования, передачи, проверки или сбора данных. Кроме того, данные различных типов могут быть собраны с помощью общего средства сбора или процедур сбора данных, даже если эти данные возможно представлены в разных форматах, протоколах и т.д.

После согласования любым известным или желаемым образом либо в некоторых случаях вообще без согласования собранные данные могут быть предоставлены одному или нескольким приложениям, обычно связанным с различными функциональными областями системы 10 управления технологическим процессом. Например, как известно, различные приложения 208 для контроллеров или управления технологическим процессом, показанных на фиг.3 как часть функционального блока 206 для управления технологическим процессом, могут использовать собранные данные 201 для управления технологическим процессом по ряду причин или целей. Эти приложения для управления технологическим процессом могут включать в себя традиционные системы DCS, PLC и SCADA, компьютерные управляющие системы, гибридные системы и системы цифрового управления любого типа, известные в настоящее время или разработанные для применения в будущем. Таким образом, приложения 208 для технологических контроллеров, применяя известные или требуемые программные средства или способы управления технологическим процессом, используют данные 201 для управления технологическим процессом для контроля и управления текущими функциями технологического процесса. Указанные приложения могут осуществлять управление технологическим процессом любого вида, в том числе, например, такие действия по управлению технологическим процессом, как PID-регулирование, нечеткая логика, операции прогнозирования на моделях, операции управления на основе нейронной сети и т.д. Приложения 208 для управления технологическим процессом могут создавать, порождать или пересылать данные аварийной сигнализации или сообщения аварийной сигнализации оператору технологического процесса, обнаруживать проблемы или ситуации, вызывающие беспокойство, либо выполнять проверки, связанные с деятельностью органов государственного регулирования, в том числе, связанными с ограничениями, установленными Агентством по защите окружающей среды (EPA), ограничениями, установленными Управлением по контролю за продуктами и лекарствами (FDA), и могут выполнять другие известные функции управления технологическим процессом, список которых слишком велик для перечисления здесь. Кроме того, одно или несколько диагностических приложений 210 могут использовать собранные данные 201 для управления технологическим процессом с целью выполнения диагностики управления технологическим процессом. Такие диагностические приложения могут включать в себя, например, приложения, которые помогают оператору сосредоточить внимание на проблемах, возникающих в контурах, приборах, исполнительных механизмах и т.д. для управления технологическим процессом, такие как приложения, раскрытые в заявке на патент США № 09/256585 «Diagnostics in a Process Control System», поданной 22 февраля 1999 года, права на которую принадлежат правопреемнику настоящей заявки и содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки. Диагностические приложения 210 могут также включать в себя экспертные диагностические механизмы, такие как механизмы, раскрытые в заявке на патент США № 09/499445 «Diagnostic Expert in a Process Control System», поданной 7 февраля 2000 года, права на которую принадлежат правопреемнику настоящей заявки и содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки. Конечно, диагностические приложения 210 для технологического процесса могут быть представлены в виде любых других типовых или стандартных диагностических приложений для технологического процесса, и они не сводятся к конкретным упомянутым здесь вариантам. Кроме того, выходные данные этих диагностических приложений 210 могут быть представлены в любом виде и могут, например, указать на отказавшие или неэффективно функционирующие контуры, функциональные блоки, области, блоки и т.д. в системе управления технологическим процессом, могут показать, в каких местах контуров требуется настройка и т.д.

Как также показано на фиг.3, для запоминания ранее собранных данных 201 для управления технологическим процессом или выходных данных приложений 208 для контроля управления технологическим процессом и диагностических приложений 210 для управления технологическим процессом либо любых других требуемых технологических данных можно использовать архив 212 управления технологическим процессом. Конечно, приложения 208 для контроля управления технологическим процессом и диагностические приложения 210 могут использовать данные, хранящиеся в архиве 212, любым известным или желаемым образом. Кроме того, приложения 208 и 210 могут использовать технологические модели 214 (которые могут составлять часть моделей 56 по фиг.1 и часть функциональной области для контроля эффективности), которые могут быть разработаны для моделирования всех или части технологических блоков или областей в технологическом процессе 10.

Корме того, функциональный блок 220 контроля оборудования принимает данные 208 о состоянии оборудования или согласованную версию таких данных, если выполняется согласование этих данных. Функциональный блок 220 контроля оборудования включает в себя приложения 222 для контроля оборудования или состояний, которые могут, например, получать или создавать аварийные сигналы, указывающие на проблемы, возникшие в различных частях оборудования, обнаруживать неэффективно функционирующее или отказавшее оборудование в установке 10 либо обнаруживать другие проблемы или ситуации с состоянием оборудования, которые могут представлять интерес для обслуживающего персонала. Приложения для контроля оборудования широко известны и обычно включают в себя программы (утилиты), адаптированные к оборудованию различных конкретных типов в установке. В подробном обсуждении этих приложений нет необходимости. Аналогичным образом могут быть реализованы диагностические приложения 224 для оборудования, предназначенные для обнаружения и диагностирования проблем, касающихся оборудования, на основе необработанных данных измерений, относящихся к оборудованию. Такие диагностические приложения 224 для оборудования могут включать в себя, например, приложения для датчиков вибрации, приложения для вращающегося оборудования, приложения для измерений мощности и т.д. Разумеется, имеется множество других типов известных приложений для контроля и диагностики состояния оборудования, которые могут создавать множество различных типов данных, связанных с состоянием или рабочими ситуациями в различных частях оборудования установки для управления технологическим процессом. Кроме того, в архиве 226 могут храниться необработанные данные, полученные устройствами контроля оборудования, данные, созданные приложениями 222 и 224 для контроля и диагностики состояния оборудования, а архив 226 может предоставлять данные этим приложениям, когда это необходимо. Аналогичным образом могут быть предусмотрены модели 228 оборудования (которые могу являться частью моделей 56 по фиг.1, а значит, частью функциональной области контроля эффективности), причем эти модели могут использоваться приложениями 222 и 224 для контроля и диагностики состояния оборудования любым желаемым образом. Способы создания и использования указанных моделей хорошо известны специалистам в данной области техники и не нуждаются здесь в более подробном описании.

Аналогичным образом, функциональный блок 230 контроля эффективности технологического процесса, показанный на фиг.3, принимает данные 203 об эффективности технологического процесса, которые могут быть или не быть согласованы, отформатированы и т.д. устройством 204 сбора данных. Функциональный блок 230 контроля технологического процесса включает в себя приложения 231 контроля эффективности технологического процесса, которые могут использовать, например, модели 214 управления технологическим процессом, модели 228 технологического оборудования или модели 232 эффективности для выполнения контроля эффективности технологического процесса любым известным или желаемым образом. Другой набор приложений 233 может использовать выходные данные контроля эффективности технологического процесса для разработки рекомендаций или советов пользователю, каким образом следует изменить конфигурацию технологического оборудования для более рациональной реализации технологического процесса, или разработки более эффективного или экономически выгодного технологического процесса. Архив 234 контроля эффективности технологического процесса может хранить необработанные данные, полученные устройствами контроля 231 эффективности технологического процесса, хранить данные, созданные приложениями 231 контроля эффективности технологического процесса и приложениями 233, разрабатывающими рекомендации, и может предоставлять эти данные другим приложениям, когда это потребуется. Создание и использование технологических моделей и приложений для контроля эффективности технологического процесса хорошо известно и дополнительно здесь не описывается.

Для преодоления ограничения, состоящего в том, что доступ к данным от различных внешних источников ограничен либо невозможен, предусмотрена система 102 сбора и распределения данных для сбора данных, преобразования этих данных, если это необходимо, в общий формат или протокол, который может быть доступен и использоваться приложениями в наборе 50 использования активов, показанном на фиг.3. Таким образом приложения в наборе 50 использования активов принимают различные типы данных из других функциональных областей или источников данных, в том числе функциональной области 206 для управления технологическим процессом, функциональной области 220 для контроля оборудования и функциональной области 230 для контроля эффективности, и интегрируют эти данные любым из нескольких способов, что непосредственно и благоприятно сказывается на работе установки 10. Целью функционирования набора 50 использования активов может быть создание более полного представления об установке 10, позволяющего лучше понять общее состояние установки 10 и принять более качественные решения, касающиеся управления или использования установки 10, либо активов установки 10 на основе всех данных по установке и, в конце концов, обеспечить более оптимальную работу установки 10. Интеграция функциональных данных различных типов может обеспечить или позволит повысить безопасность персонала, увеличить время безотказной работы технологического процесса и оборудования, избежать катастрофических процессов и/или отказов оборудования, увеличить эксплуатационную работоспособность (время безотказной работы) и производительность установки, повысить пропускную способность благодаря увеличению времени безотказной работы и возможности надежного и безопасного выполнения технологического процесса при точном и своевременном соблюдении гарантийных ограничений, повысить производительность за счет возможности работы при экологических ограничениях и повысить качество благодаря исключению или минимизации отклонений в технологическом процессе, связанных с работой оборудования. В отличие от этого в прошлом различные функциональные области, например, контроль технологического процесса, контроль оборудования и контроль эффективности выполнялись независимо, и в каждой из этих областей предпринимались попытки собственной оптимизации безотносительно тех последствий для других функциональных областей, которые могли бы повлечь такие действия. В результате, например, проблема с оборудованием, имеющим низкий приоритет, могла вызвать большую проблему при достижении требуемой или критической эффективности управления технологическим процессом, но этой проблемой не занимались, поскольку не считали ее очень важной в контексте технического обслуживания оборудования. Однако при наличии системы 102 сбора и распределения данных, предоставляющей данные в набор 50 использования активов, персонал может иметь доступ к отображению установки 10 на основе двух или более видов данных: контроля оборудования, эффективности технологического процесса и контроля управления технологическим процессом. Аналогично, диагностика, выполняемая для установки 10, может принимать во внимание данные, связанные с ходом технологического процесса и работой оборудования, и обеспечивать более комплексный диагностический анализ. Таким образом, приложения в наборе 50 использования активов могут использовать данные для управления технологическим процессом, данные контроля оборудования и данные по эффективности технологического процесса для принятия более качественных или более полных решений, которые будучи не строго оптимальными для одной функциональной области, могут оптимизировать работу установки в целом, чего нельзя достичь при независимом функционировании различных функциональных областей.

Хотя система 102 сбора и распределения данных может находиться между источниками 206, 220, 230 и 239, собирающими или создающими функциональные данные, и набором использования активов, система 102 вместо этого может также находиться в любом другом месте в системе 10 в зависимости от того, что из себя представляют различные источники данных, которые собирают данные совершенно разных типов. В действительности, система 102 сбора и распределения данных может находиться в любом месте в схеме по фиг.3 в зависимости от того, что из себя представляют источники данных и какие источники уже интегрированы и поставляют данные в стандартном или распознаваемом формате. Как было указано выше, система 102 сбора и распределения данных может находиться между набором 50 использования активов и функциональными областями 206, 220, 230 и 239, что является стандартным случаем. Однако система 102 сбора и распределения данных может находиться перед любой или всеми функциональными областями 206, 220, 230 или 239 либо представлять некоторую комбинацию того и другого варианта. Кроме того, хотя система 102 сбора и распределения данных показана в централизованном виде, то есть, в одном месте, она может быть разнесена и реализована во множестве мест в системе 10. Таким образом, компоненты программных средств системы сбора и распределения данных могут выполняться во множестве различных устройств, чтобы обеспечить возможность сбора данных в большем количестве или более высокого качества от различных источников данных. Каждое из указанных приложений для сбора данных может собирать данные от одного или нескольких источников в зависимости от потребностей и расположения этих приложений, и каждое приложение может затем предоставить собранные и отформатированные данные в одну или несколько централизованных баз данных в системе, которая может обеспечить доступ к этим данным со стороны других приложений.

Вновь обратимся к фиг.3, где показан набор 50 использования активов, включающий в себя несколько приложений, которые используют данные, собранные из различных функциональных областей или источников данных в установке 10 для управления технологическим процессом, в том числе, в целях иллюстрации - из функциональной области 230 контроля эффективности, функциональной области 206 управления технологическим процессом и функциональной области 220 контроля оборудования. Конечно, набор 50 использования активов может принимать любые данные из этих областей, в том числе необработанные данные, согласованные данные, данные, хранящиеся в архивах 212, 226 и 234, данные, созданные приложениями 208 и 222 контроля, данные, созданные моделями 232 эффективности, и данные, созданные диагностическими приложениями 210 и 224. Если потребуется, набор 50 использования активов может также использовать модели 214 технологического процесса и модели 228 оборудования. Понятно, что, хотя здесь показано, что набор 50 использования активов включает в себя конкретное количество приложений, набор 50 может включать любое количество приложений, в том числе одно или несколько приложений, которые выполняют любую одну или несколько из описанных здесь функций.

В частности, набор 50 использования активов, показанный на фиг.3, может включать в себя одно или несколько интегрированных приложений 240 для контроля состояния установки. Указанные приложения 240 для контроля состояния установки могут включать в себя приложение 51 по фиг.1 для создания индексов, которое создает индексы, связанные с такими устройствами, как устройства управления технологическим процессом и контрольно-измерительные устройства, устройства для производства электроэнергии, вращающееся оборудование, блоки, области и т.д., и/или связанные с объектами управления технологическим процессом, такими как блоки, контуры, области и т.д. в установке 10, на основе двух или более видов информации: информации для управления технологическим процессом, информации об устройствах и информации об эффективности. Создание и отображение этих индексов более подробно описано ниже. Однако, в сущности говоря, эти индексы могут базироваться на данных управления технологическим процессом, а также данных об эффективности процесса или контроля оборудования и могут отображаться в согласованном формате пользователю через интегрированный дисплей.

Как показано на фиг.3, набор 50 использования активов может включать в себя приложение 244 для интегрированного отображения (которое может представлять собой любое или все приложения 58 интерфейса по фиг.1), которое отображает различные данные любому пользователю в интегрированном или общем виде. В сущности говоря, приложение 244 для отображения реализовано с возможностью предоставления различной информации любому пользователю, где отображенная информация отражает или базируется на двух или более видах данных: данных 201 для управления технологическим процессом, данных 202 контроля оборудования и данных 203 об эффективности технологического процесса. Приложение 244 принимает входные данные от других приложений в наборе 50 и может предоставить пользователю возможность просмотра необработанных данных 201, 202 и 203, возможность перехода с одного экрана на другой для просмотра других частей или аспектов установки 10 на основе необработанных или обработанных данных, возможность просмотра пользователем обработанных данных, таких как данные, созданные приложениями 222, 208 и 231 состояния оборудования, контроля технологического процесса или контроля эффективности, технологическими моделями 214, диагностическими приложениями 224 и 210 для оборудования или технологического процесса, либо данные, созданные другими приложениями в наборе 50 использования активов.

Набор 50 использования активов может также включать в себя приложение 246 для интегрированной аварийной сигнализации, которое может принимать аварийные сигналы от технологического процесса и устройств и отображать эти аварийные сигналы пользователю в согласованном формате. Такое приложение для интегрированного отображения аварийных сигналов раскрыто в заявке на патент США № 09/707580 «Integrated Alarm Display in a Process Control Network», поданной 7 ноября 2000 года, права на которую принадлежат правопреемнику настоящей заявки и содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки. Приложение 246 для интегрированной аварийной сигнализации может создавать отображения 248 для пользователя, которые предоставляют информацию о принятых аварийных сигналах, баннер аварийной сигнализации, под которым объединены аварийные сигналы и т.д.

Набор 50 использования активов может также включать в себя одно или несколько приложений 250 для интегрированной диагностики, которые интегрируют данные 201 для управления технологическим процессом, данные 205 об эффективности технологического процесса и данные 202 о состоянии оборудования для выполнения диагностики на базе всей установки. Например, имеется множество случаев, когда данные по технологическому оборудованию и данные по управлению технологическим процессом могут быть объединены для обеспечения более качественного диагностического анализа ситуации в установке 10, чем в случае использования данных только одного из указанных типов. Аналогично могут быть объединены выходные данные диагностического приложения 224 состояния оборудования и выходные данные диагностического приложения 210 для управления технологическим процессом для обеспечения более полного диагностического анализа технологической установки, чем в случае использования выходных данных любого из отдельных приложений. Интегрированные диагностические приложения 250 могут включать в себя экспертные механизмы любого требуемого типа, технологические модели и/или модели оборудования и приложения для прогнозирования, которые выполняют прогноз параметров в установке 10 на основе полученных данных или других диагностических решений, полученных от других приложений. Конечно, интегрированное диагностическое приложение 250 может предоставить пользователю отображение через приложение 244 интерфейса, показав результаты различных диагностических анализов. Кроме того, интегрированное диагностическое приложение 250 может предоставить пользователю возможность конфигурации приложения 250 для создания конкретных интегрированных диагностических описаний. Например, пользователю может быть представлен экран конфигурации, на котором он выбирает различные диагностические приложения, подлежащие выполнению (в том числе, например, как диагностические приложения 210 для технологического процесса, так и приложения 224 для контроля оборудования), и может затем объединить результаты или получить другие диагностические решения на основе выходных данных выбранных диагностических приложений. В этом случае пользователь может соединить выходные данные некоторых известных приложений для контроля или диагностики технологического процесса и оборудования с новой функцией (которой может быть, например, функцией эффективности технологического процесса), которая объединяет или оценивает эти выходные данные определенным образом, чтобы получить результаты диагностики. В альтернативном варианте новое диагностическое приложение, использующее как данные 201 для управления технологическим процессом, так и данные 202 для контроля оборудования, может быть создано для диагностирования установки. В этих примерах диагностическое приложение 250 может выдавать пользователю отображение, например, через приложение 244 интерфейса пользователя.

Стандартные диагностические приложения 250, выявляющие отказы, могут также включать в себя приложение для обратного отслеживания, которое использует как данные 201 для управления технологическим процессом, так и данные 202 о состоянии оборудования для определения источника обнаруженной проблемы. Приложения для обратного отслеживания, которые пытаются определить местоположение источников обнаруженных проблем, либо на основе данных управления технологическим процессом, либо на основе данных о состоянии оборудования, существуют, но такое приложение для обратного отслеживания не использовалось для акцентирования внимания на проблемах, возникающих в установке, на основе данных управления технологическим процессом и данных о состоянии оборудования. Использование приложения для обратного отслеживания, где учитываются как данные о технологическом процессе, так и данные об оборудовании, может дать более точный или полный ответ о причине возникновения проблемы или ситуации в технологической установке 10, чем используемые ранее приложения для обратного отслеживания, которые используют что-то одно: либо данные о технологическом процессе, либо данные об оборудовании. Конечно, эти приложения для обратного отслеживания интегрируют данные управления технологическим процессом и данные контроля оборудования и, если потребуется, обрабатывают данные об эффективности для выявления причины возникшей проблемы. Такой причиной может быть комбинация факторов, возможно имеющих разный вес, выявление состояний технологического процесса и оборудования, которые не должны существовать одновременно (например, работа насоса при закрытом запорном вентиле) и т.д. Эти проблемы могут быть представлены в терминах вероятностей, весовых коэффициентов, прогнозируемых состояний и т.д. В указанных приложениях для обратного отслеживания либо других диагностических приложениях могут использоваться формальные модели технологического процесса и оборудования, а также производные от входных и выходных переменных и действительные результаты измерений этих переменных для вычисления полной производной выходных переменных относительно входных переменных и оценки этой полной производной с использованием реальных измерений в технологическом процессе для вычисления причинных вкладов отдельных потенциальных источников. Причинные данные также могут быть проверены, подтверждены и согласованы с действительными выходными данными от установки 10, чтобы определить, насколько хорошо подтверждаются прогнозы.

В любом случае для выполнения некоторых действий, связанных с диагностическими решениями, принятыми интегрированным диагностическим приложением 250 либо в ответ на аварийные сообщения или другие состояния, могут быть предусмотрены одно ли несколько других приложений 260 для выполнения таких действий. Например, приложение 260 может предоставить список потенциальных действий или рекомендаций пользователю через приложение 244 интерфейса пользователя или приложение 262 для прогнозирования, которое может спрогнозировать результат указанных рекомендаций и отобразить указанные результаты пользователю через приложение 244 для интегрированного отображения. Эти рекомендации, например, могут быть рассчитаны на выполнение действий, направленных на решение проблемы, получение более длительного срока службы установки 10, обеспечение более экономичной работы установки 10 или ее работы в рамках установленных финансовых или EPA ограничений, избежания проблем в будущем на основе текущих или прогнозируемых функциональных возможностей технологического процесса и оборудования и т.д. Приложение 260 также может предоставить пользователю возможность имитации работы установки 10 на основе предложенных действий, чтобы увидеть смоделированный эффект от этих приложений до реализации упомянутых действий. Приложение 260 также может предпринять действия по сбору данных в большем объеме или лучшего качества для принятия более качественного диагностического решения. Сбор этих данных может повлечь за собой автоматический запуск приложений для контроля состояния оборудования, либо приложений для контроля технологического процесса, либо приложений для контроля эффективности, чтобы собрать данные различных типов или в большем объеме.

Приложение 260 при соответствующей его конфигурации может также автоматически предпринять в установке 10 такие действия, как сброс уставок в исходное состояние, настройку контуров, реконфигурацию оборудования и т.д., как это указано трактом 264 обратной связи на основе диагностических решений, принятых приложением 250, аварийных сигналов и т.д. Эти действия могут или не могут быть предприняты с использованием приложений для управления технологическим процессом, приложений для контроля управления оборудованием с целью реализации изменений в системе. Эти действия также могут повлечь за собой реконфигурацию установки 10, чтобы перейти к производству с одного продукта на другой либо к производству продукта одного типа в большем объеме, либо для иной реконфигурации установки 10 с целью обеспечения максимума финансовых показателей или решения других вопросов. Кроме того, приложение 260 может вызвать другие приложения, такие как приложение 270 для автоматического формирования нарядов на работу (которое может представлять собой приложение 54 по фиг.1), для оформления заказов на необходимые для оборудования детали, для заказа сырья, необходимого для производства новых продуктов, и т.д. Конечно, приложение 260 может использовать интегрированную аварийную сигнализацию, финансовые ограничения или инструкции либо другие данные, чтобы предпринять незамедлительные действия по управлению для внесения, автоматически или в ручную, необходимых изменений в установку 10 и т.д., когда это необходимо.

Понятно, что интерфейс 244 пользователя может отображать любой или все экраны пользователя различных типов на основе приложения в выполняемом наборе 50. Таким образом, интерфейс 244 пользователя может, например, отображать экраны с данными об эффективности оборудования, экраны с необработанными данными, диаграммы 242 насыщения и т.д. Интерфейс 244 пользователя может также отображать экраны 248 интегрированной аварийной сигнализации, созданные приложением 246 интегрированной аварийной сигнализации. Аналогичным образом любое из приложений 250 для диагностики неисправностей может создать диагностические дисплеи 273, экраны 274 с рекомендациями и экраны 275 и 276, показывающие запланированную продукцию и использование оборудования. Аналогичным образом приложениями 260, предпринимающими определенные действия, могут быть созданы экраны 277 любого рода для планирования производства и финансовых показателей. Конечно, эти и другие приложения могут создать другие типы экранов и отображений на основе данных, полученных от многочисленных источников данных.

Заметим, что, хотя на фиг.3 приложения для управления технологическим процессом, контроля и диагностики оборудования и контроля эффективности показаны отдельно от набора приложений 50, эти конкретные приложения могут являться частью или использоваться набором интегрированных приложений 50, если это потребуется. Кроме того, хотя на фиг.3 показаны данные, связанные с одним вариантом установки 10, это не значит, что на фиг.3 указаны физические положения любого приложения в наборе приложений 50. Таким образом, любое и все приложения и аппаратные средства, показанные на фиг.3, могут находиться в любых требуемых местах в установке (или даже вне установки 10, если это необходимо), то есть, вовсе не обязательно, чтобы эти приложения находились в одном месте. Кроме того, поток данных между устройствами сбора данных и системой 102 сбора и распределения данных, а также между системой 102 сбора и распределения данных и приложениями, показанными на фиг.3, может передаваться по любой желаемой сети, такой как LAN или WAN, Интернет, любой интрасети и т.д. Данные могут передаваться любым желаемым образом с использованием любых требуемых аппаратных средств, в том числе, например, любого физического носителя, любого способа транспортировки информации по выделенным или общим каналам, в том числе без ограничения использования проводных, беспроводных устройств, коаксиальных кабелей, телефонных модемов, волоконно-оптических и оптических средств, системы метеорной радиосвязи, спутниковых устройств и т.д. Эта связь также может использовать любой требуемый протокол, в том числе, но не только, протоколы Fieldbus, XML, TCP/IP, IEEE802.3, Bleutooth, X25, X400, либо любой другой протокол, известный в настоящее время или разработанный для применения в будущем.

Кроме того, данные, используемые приложениями 50 для интеграции или посылаемые из этих приложений, могут быть нормализованы или сжаты на любом этапе пересылки. Конечно, при этом можно использовать любое известное или требуемое сжатие, в том числе, например, импульсное представление сигнала, преобразование Фурье, Адамара и т.д., передачу коэффициентов Фурье и т.п., обработку исключительных ситуаций, сжатие данных “Swinging Door” (Качающаяся дверь) т.д.

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

В одном варианте диагностическое приложение 250 может дать возможность пользователю оценивать характеристики и тенденции изменения выходных сигналов датчиков контроля состояния оборудования и технологического процесса и/или аварийные сигналы и/или инициировать изменения в управлении при изменении этих характеристик. Эта функциональная возможность может быть реализована с помощью распознавания образов с аварийными границами на наборе признаков либо путем анализа составляющих Фурье, а также тенденций и/или аварийных сигналов, и/или инициирования управляющих воздействий на основе ограничений на отдельные коэффициенты Фурье или на взвешенную комбинацию коэффициентов Фурье или некоторую их функцию (например, квадратура, общая мощность на переменном токе, коэффициенты PSD (спектральная плотность мощности) и т.д.).

В одном варианте для сбора преобразования и обработки или буферизации входных данных контроля состояния, полученных в результате операций контроля технологического процесса и оборудования, могут быть предусмотрены одна или несколько плат, такие как платы ввода/вывода (I/O), подсоединенные к одному или нескольким технологическим контроллерам 12 или 14 по фиг.1, причем эти платы могут реализовать часть либо всю систему 102 сбора и распределения данных. Эти платы I/O (которые могут являться процессорами, составленными из субблоков, с реализованными в них стандартными программами сбора данных) могут выполнять операции по сбору данных для некоторых или всех устройств, областей и т.д. технологической установки 10, чтобы обеспечить данные, необходимые интегрированным приложениям в установке 10. Эти платы можно сконфигурировать для сбора любых или всех данных для управления технологическим процессом, данных контроля оборудования или данных об эффективности технологического процесса от множества различных типов устройств или источников в системе управления технологическим процессом. Указанные источники данных опять же могут включать в себя, например, переносные устройства сбора, источники данных лабораторных химических и физических измерений, онлайновые источники входных сигналов и удаленные источники. Кроме того, для запоминания и реализации одного или нескольких описанных здесь интегрированных приложений может быть предусмотрена другая плата, такая как плата ввода/вывода, соединенная с контроллером. Таким образом, хотя на фиг.1 показаны приложения для сбора и распределения данных, а также интегрированные приложения в наборе использования активов, реализуемом в центральном компьютере 30, эти приложения и операции по сбору данных для этих приложений могут быть реализованы в одной или нескольких выделенных платах или других устройствах, распределенных по всей технологической установке 10. Эти платы или сборные процессоры могут быть непосредственно подсоединены к интерфейсу пользователя и контроллеру через системную шину, такую как шина 32 по фиг.1, или могут являться частью системы ввода/вывода, связанной с одним или несколькими контроллерами, либо могут находиться в каком-либо другом месте. Конечно, одна такая выделенная плата может выполнять все интегрированные приложения либо любой поднабор из них в зависимости от конфигурации и характера технологической установки 10, в которой она используется. В некоторых случаях может выполняться некоторая предобработка данных, собранных на уровне контроллера, и эти предварительно обработанные или частично обработанные данные могут затем быть переданы на другое устройство, такое как компьютерная система 30, которая может завершить интегрированную обработку. Таким образом, интегрированные приложения 50 могут быть распределенными по своей природе при их реализации в технологической среде.

Теперь со ссылками на фиг.4-6 будет обсужден один способ сбора и интеграции данных от различных источников данных. Понятно, что в этом примере данные, собранные от различных источников данных, преобразуются в формат, используемый системой управления технологическим процессом, которая реализована с использованием системы управления технологическим процессом DeltaV^TM, поставляемой компанией Fisher Rosemount Systems, Inc. В результате данные для управления технологическим процессом не являются данными от удаленного источника данных. Однако другие данные, такие как данные технического обслуживания, данные контроля эффективности, данные моделирования технологического процесса, финансовые данные и т.д. поступают от внешних источников данных. В сущности говоря, эта система сконфигурирована с использованием системы конфигурации, которая запоминает и отслеживает данные о конфигурации системы. В прошлом указанная система конфигурации ограничивалась размещением и взаимодействием устройств для управления технологическим процессом, программных средств и стратегий и в ограниченной степени включала в себя информацию о техническом обслуживании, касающуюся некоторых устройств, таких как полевые устройства. Однако, поскольку основной целью системы было обслуживание операторов, управляющих технологическим процессом, информация, отображаемая пользователю и отслеживаемая системой конфигурации, обычно ограничивалась данными для управления технологическим процессом. В этой известной системе в базе данных конфигурации хранилась информация, отображаемая приложением проводника и касающаяся устройств для управления технологическим процессом, а также данные, собранные и созданные этими устройствами.

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

На фиг.4 показана архитектура системы 300, которая выполняет сбор данных от разнородных источников данных вместе с системой управления технологическим процессом. Обычно система 300 включает в себя секцию 302 информационно-технологической системы (ITS), которая может включать в себя систему 304 управления техническим обслуживанием, систему 306 управления инвентаризацией продукции, систему 308 планирования производства, а также другие системы, подсоединенные через LAN, Интернет и т.д. ITS 302 подсоединена к секции 310 web-служб чрез сервер 312 транзакций XML. Сервер 312 посылает свернутые данные XML в web-службы 310, показывающие данные, используемые или создаваемые блоками 304, 306 и 308.

Web-службы 310 включают в себя ряд приемников 314 web-служб, которые «прослушивают» или подписываются на некоторые данные от других источников данных и предоставляют эти данные подписавшимся приложениям. Подписавшиеся приложения могут быть связаны с приложениями в ITS 302 или системе управления технологическим процессом. Web-службы прослушивания (которые могут являться частью системы 102 сбора и распределения данных) могут прослушивать и перераспределять аварийные сигналы и данные о событиях, данные контроля состояния технологического процесса и данные контроля состояния оборудования. Интерфейсы для этих данных используются для преобразования данных в стандартный формат или протокол, такой как протокол Fieldbus или DeltaV или протокол XML, когда это требуется.

Web-службы 310 находятся на связи и принимают данные от других внешних источников данных через Web-серверы 316. Эти внешние источники могут включать в себя источники данных контроля вибрации, источники данных оптимизации в реальном времени, источники данных экспертного системного анализа, источники данных предупредительного технического обслуживания, источники данных контроля контуров или другие источники данных. Конечно, каждый источник может быть подсоединен через отличный от других внешний сервер, либо два или более источников данных могут совместно использовать серверы, когда это возможно. Аналогично, эти источники данных могут быть встроены в среду управления технологическим процессом или могут существовать отдельно от нее и быть подсоединены к внешним серверам через Интернет или другую сеть LAN или WAN. В любом случае Web-серверы 316 могут выполнять ряд функций системы 102 сбора и распределения данных путем форматирования принятых данных, если это потребуется.

Система 318 поддержки исполнения программ управления технологическим процессом находится в контакте с Web-службами 310 и внешними серверами 316. Система 318 поддержки исполнения программ включает в себя управляющие приложения, приложения интерфейса оператора, приложения аварийной сигнализации и событий и приложения для данных в реальном времени, любое из которых может использовать данные от внешних серверов или от Web-служб (а значит, от ITS 302). Для организации сбора данных от Web-серверов 316 и Web-служб 310, чтобы сделать эти данные доступными в общем или согласованном формате, используемом системой 318 поддержки исполнения программ управления технологическим процессом, предусмотрена система 320 Interop. Система 320 Interop включает в себя интерфейсы преобразования, такие как интерфейсы ROC, OPC, PI и Virtual Controller DLL I/F, которые могут выполнять преобразование и распознавание данных, полученных от Web-серверов 316 и приемников 314 Web-служб.

Наконец, для хранения и организации данных от системы 320 Interop и системы 318 поддержки исполнения программ управления технологическим процессом, в том числе любых данных от удаленных источников данных, к примеру, данных от внешних Web-серверов 316 и ITS 302, используется база данных 322 конфигурации. Конечно, ITS 302 может также подписаться на данные от системы управления технологическим процессом и удаленных источников данных и получать их через Web-службы 310.

На фиг.5А и 5В показан пример отображения 350, созданного средством навигации типа анализатора, которое можно использовать для хранения, организации и доступа к данным, собранным системой 102 сбора и распределения данных, хранящихся в базе данных 322 конфигурации. Отображение или иерархия 350 включает в себя множество различных сегментов, которые можно использовать для различных целей. Однако иерархия 350 отражает организацию данных или других элементов, доступных системе, иллюстрирует их общий вид и обеспечивает к ним доступ. Таким образом, иерархия 350 используется для представления данных, хранящихся в базе данных конфигурации, а также для манипулирования этими данными с целью изменения конфигурации системы некоторым образом. Как видно из этих фигур, иерархия по фиг.4 включает в себя несколько различных сегментов, в том числе сегмент «библиотека», сегмент «стратегии управления» и сегмент «сеть», каждый из которых можно использовать для различных целей или для представления различных данных или различных организаций данных, хранящихся в базе данных конфигурации или доступных этой базе.

В сущности говоря, сегмент библиотеки включает в себя списки различных элементов, хранящихся в или связанных с конфигурацией, и обеспечивает доступ к этим элементам. Эти элементы могут быть аппаратными или программными элементами, в том числе, например, программными модулями шаблонов, полевыми устройствами, контроллерами, рабочими станциями и т.д. Для представления, организации и обеспечения доступа к данным от разнородных источников данных библиотека может также включать в себя один или несколько внешних серверов, которые будут использованы в качестве каналов для потоков данных от разнородных источников данных в интегрированную систему. На фиг.4 эти серверы показаны в виде Web-серверов 316. Используемая здесь интегрированная система включает в себя все аппаратные и программные элементы, упомянутые выше в связи с системой 102 сбора и распределения данных по фиг.2. Другими словами, интегрированная система включает в себя элементы, использующие один и тот же формат данных в системе 10.

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

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

Обратимся теперь к части иерархии 350, относящейся к стратегиям управления, которые организованы, например, по географическим областям, таким как Область 1, Область 2 и т.д. Каждая область может быть разбита на различные блоки, такие как Блок 1, Блок 2 и т.д. Кроме того, каждый блок может иметь множество связанных с ним модулей. Эти модули могут представлять собой любые модули, к примеру, разработанные в сети управления технологическим процессом в согласованном формате, или модули, связанные с разнородными источниками данных. Эти модули обычно используются для конфигурации, обеспечивающей конкретный вариант совместной работы разных приложений, и их связи друг с другом. Эти функциональные возможности будут более подробно описаны в связи с фиг.6.

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

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

Для предоставления возможности сбора и использования данных от различных источников данных отображение или иерархия 350 представляет различные источники данных в виде модулей или комбинации модулей. Указанные модули могут затем быть размещены в иерархии конфигурации, и ими можно манипулировать таким же образом, как в базе данных конфигурации манипулируют модулями, связанными с объектами в интегрированной системе, такими как модули управления технологическим процессом. При создании модуля для ранее неизвестного или не подсоединенного источника данных пользователь определяет тип, характер или значение данных, принимаемых от этого источника данных, в контексте модуля. При использовании этой информационной конструкции данные, действительно принятые от этого источника данных, можно затем разбить на категории, пометить, опознать и использовать в интегрированной системе таким же образом, как данные от других модулей элементов в интегрированной системе. Таким путем данные любого типа, принятые от другого, разнородного источника данных, можно собирать и хранить даже в том случае, если указанное приложение или устройство, которое в действительности создает эти данные, создано организацией или лицом, совершенно не связанным с интегрированной системой. Конечно, ясно, что данные от этого источника данных передаются в базу данных конфигурации после их преобразования с использованием одной из технологий преобразования, таких как OPC, PI, Fieldbus и т.д. Как было указано выше, эта функция выполняется системой 102 сбора и распределения данных, которая в иерархии 350 на фиг.5 в действительности не показана. Более подробное описание модулей для паровой турбины приведено в связи с фиг.6.

Сетевой сегмент иерархии 350 показывает физические и рабочие соединения в сети. Конечно, обычно имеется множество типов устройств и элементов, связанных с сетью. Однако одним из показанных элементов является узел управления областью (ACN), который включает в себя узел контроллера. Узел контроллера, в свою очередь, имеет стратегии управления, такие как хранящиеся в нем программные средства управления и связи. CAN включает в себя также одно или несколько устройств ввода/вывода (I/O), которые могут быть устройствами I/O Fieldbus, устройствами I/O HART и т.д. Конечно, каждое устройство ввода/вывода может иметь разные порты, устройства, функциональные блоки и т.д., подсоединенные к устройству ввода/вывода или имеющими с ним линию связи. С CAN также могут быть связаны одна или несколько рабочих станций. Эти рабочие станции могут являться интерфейсами пользователя либо рабочими станциями других типов. Рабочая станция, показанная на фиг.5, поддерживает или реализует многочисленные приложения или другие функциональные элементы, в том числе в данном примере приложения для обработки или отображения аварийных сигналов и предупреждений и приложения стратегий управления, такие как те, которые используются для конфигурации контроллера, полевых устройств и т.д. для получения информации о контроллере и полевых устройствах.

Чтобы иметь возможность сбора данных от различных или разнородных источников данных, рабочая станция также обеспечивает либо выполняет сегмент взаимодействия (IOP). Сегмент IOP (который также показан на фиг.4) включает в себя один или несколько внешних серверов, идентифицированных в сегменте библиотеки иерархии 350. Здесь внешний сервер RTO+ (названный внешним сервером 1) поддерживается рабочей станцией, показанной в ACN. Конечно, на этой рабочей станции, на других рабочих станциях в этом CAN или в других CAN, если потребуется, могут быть предусмотрены другие внешние серверы, связанные с другими источниками данных, такими как те, что описаны в связи с фигурами 2 и 3. Внешний сервер может поддерживать любое рациональное количество устройств. Хотя все эти устройства могут быть связаны с приложением или службой RTO+, не все устройства, поддерживаемые сервером, нуждаются в связи с одним конкретным источником данных. Таким образом, один сервер может поддерживать множество различных источников данных.

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

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

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

Модули можно создать путем перетаскивания по экрану одного из множества образцов 360 (на левой стороне экрана на фиг.6) и оставления выбранного образца на экране 362 конфигурации. Затем модуль может быть присвоен конкретному устройству или источнику данных, такому как турбина, в службах IOP или в библиотеке иерархии по фиг.5 с использованием всплывающих окон с характеристиками и т.п. Как только модуль будет соединен с конкретным внешним устройством или источником данных через службу IOP и внешний сервер, этот модуль может быть определен для включения в него некоторых параметров, связанных с упомянутым устройством. Такими параметрами могут быть характеристики модуля, которые доступны из этого модуля, например, выходные сигналы из этого модуля. Некоторые либо все данные о параметрах определенного модуля могут быть отражены со связями с внешним устройством или источником данных в иерархии 350 по фиг.5.

В этом случае модуль 364 паровой турбины включает в себя параметр 366 - кпд и параметр 368 - мощность, которые доступны в качестве выходов этого модуля. Другие элементы модуля 364, отраженные в иерархии 350 по фиг.5, также предусмотрены как часть модуля, включающего в себя функциональные блоки, входы и выходы устройства, аварийные сигналы, связанные с устройством, и т.д. Модуль 364 турбины, связанный с или созданный для паровой турбины бойлера в иерархии 350 по фиг.5, также включает в себя аварийные сигналы, являющиеся аварийными сигналами, идентифицированными или разрешенными пользователем в сегментах IOP или библиотеки в иерархии 350. Один их этих аварийных сигналов доступен как выходной сигнал. Выходные сигналы модуля - это данные, связанные с турбиной, которые предоставляются через внешний сервер от самого устройства или других программных средств, связанных с этим устройством. Эти выходы могут являться параметрами, измеренными значениями и т.д. в зависимости от того, как определен модуль 364. Входами в модуль являются входные сигналы от приложений и т.д., которые могут быть посланы через внешний сервер на реальное устройство или программное средство, связанное с этим устройством для воздействия на это устройство определенным образом. В действительности, входными сигналами модуля 364 являются сигналы данных или управления, которые соответствующее устройство будет принимать или распознавать. Назначение этих входных сигналов будет определено устройством или программными средствами, связанными с этим устройством. Эти входные сигналы позволяют посылать во внешний источник данных или устройство данные от других модулей, таких как модули в интегрированной системе или модули, связанные с другими внешними источниками данных, через службы IOP, а значит, через внешний сервер, подсоединенный к внешнему источнику данных. Внешний источник данных может использовать эти входные данные любым способом, который потребуется. Например, он может управляться этими входными данными или использовать эти входные данные для более качественных или точных расчетов параметров устройства и т.д. Если потребуется, модули для внешних источников данных могут также включать в себя программные средства, которые используют входные сигналы, выходные сигналы, параметры и т.д. для выполнения вычислений определенного характера.

В предпочтительном варианте системы конфигурации модули, созданные для устройств, приложений и т.д. в интегрированной системе и внешних источниках данных, основаны на концепции модулей Fieldbus или DeltaV, которые весьма схожи. Здесь модуль 364, поскольку он связан с внешним источником данных, в котором не используется модульная организация, представляет собой теневой функциональный блок или теневой модуль. В сущности говоря, теневой функциональный блок или теневой модульный элемент является функциональным блоком или модулем в базе данных конфигурации интегрированной системы, который конфигурируется для использования в качестве модуля. Однако этот теневой модуль находится в контакте с источником данных или устройством и имеет свои выходные сигналы, создаваемые или обеспечиваемые этим внешним устройством. Кроме того, теневой модуль подает входные сигналы, которые он принимает, во внешний источник данных. Таким образом, теневой модуль просто имеет входные и выходные сигналы и состояние, которое отражает его входные сигналы, выходные сигналы и состояние действительного устройства или источника данных, определенного данными, принятыми от источника данных. Однако использование теневого модуля делает входные и выходные сигналы внешнего устройства или источника данных доступными другим модулям в интегрированной системе, таким как модули, связанные с приложениями в наборе 50 использования активов. Таким путем теневой функциональный блок или модуль действует как информационный канал между внешним источником данных и приложениями в интегрированной системе путем преобразования данных, принятых от внешнего источника данных, в формат, используемый другими приложениями в интегрированной системе. Описание и использование теневых функциональных блоков описано в заявке на патент США № 09/151084 «A Shadow Function Block Interface For Use in a Process Control Network», поданной 10 сентября 1998 года, права на которую принадлежат правопреемнику настоящей заявки и содержание которой включено в настоящее описание по ссылке.

Экран 362 конфигурации по фиг.6 показывает, что пользователь сконфигурировал турбинный модуль 364 для подачи его выходных сигналов на входы другого модуля, который идентифицирован как вычислительный модуль 370 или модуль Calc. Модуль Calc 370 включает в себя входной сигнал мощности, получаемый от турбинного модуля 364, и входной сигнал, получаемый от модуля 372 PID, который может представлять собой модуль, связанный со стандартной программой управления технологическим процессом в интегрированной системе. Модуль Calc 370 использует эти входные сигналы для создания выходных данных, которые могут указывать необходимость изменения некоторых параметров турбины, связанной с модулем 364. В этом примере выходные данные модуля Calc 370 подаются на вход турбинного модуля 364, так что эти данные посылаются через службы IOP и внешний сервер в приложение (такое как приложение RTO+), которое предоставляет данные, связанные с турбиной. Понятно, что модуль Calc 370 является модулем, который реализуется и выполняется на рабочей станции в интегрированной системе. Модуль Calc 370 может быть связан с другим приложением, таким как одно из приложений в наборе 50 использования активов. Как таковой, экран 362 конфигурации по фиг.6 иллюстрирует способ, согласно которому один внешний источник данных подсоединен к приложению в интегрированной системе для предоставления данных этому приложению. Кроме того, приложение в интегрированной системе (то есть, модуль Calc 360) использует удаленные данные и данные управления технологическим процессом для выполнения вычислений и посылает другие данные или информацию внешнему источнику данных через внешний сервер. Понятно, что внешний сервер сконфигурирован для использования ОРС или любого другого требуемого протокола преобразования для связи с целью преобразования данных в подходящий формат при их передаче в любом направлении между интегрированной системой и внешним источником данных.

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

Одним из примеров манипулирования данными от внешнего источника данных в модуле, созданном для сбора и организации данных от этого источника, является использование или создание аварийных сигналов для внешнего источника данных. В частности, аварийные сигналы можно задать для модуля, чтобы собирать и отражать действительные аварийные данные, поступающие от внешнего источника. Вдобавок или как альтернативный вариант, аварийные сигналы могут создаваться в модуле на основе данных, принимаемых от внешнего источника данных, который связан с этим модулем. В случае, когда аварийные сигналы создаются в модуле, функциональный блок в модуле может получить данные от внешнего источника, а также, если требуется, от других источников и выполнить любые необходимые вычисления, чтобы определить, существует ли аварийное или предупреждающее состояние (статус). Если это подтверждается, то этот функциональный блок может установить аварийный сигнал, который будет связан с модулем и который может контролироваться приложениями аварийной сигнализации либо посылаться в эти приложения, а эти приложения будут обрабатывать указанный аварийный сигнал таким же образом, как обрабатываются другие аварийные сигналы. Такая обработка аварийных сигналов может включать в себя отображение аварийного сигнала пользователю, запоминание аварийного сигнала, разрешение подтверждения аварийного сигнала и т.д. Кроме того, возможности аварийной сигнализации модуля, такого как модуль, связанный с внешним источником данных (который может включить или выключить возможности аварийной сигнализации модуля), могут блокироваться или разблокироваться через иерархию 350 по фиг.5. Таким образом, понятно, что данные от внешних источников данных могут отображаться в аварийный сигнал в модуле либо могут быть использованы для создания аварийного сигнала для модуля, а значит, для внешнего источника данных.

Для доступа, получения или оценки данных от внешнего источника или связанного с ним источника пользователь может просмотреть сегмент библиотеки в иерархии 350 для ознакомления с информацией, связанной с внешними источниками. Вдобавок пользователь может просмотреть стратегии управления и найти конкретный модуль для внешнего источника данных. Кроме того, пользователь для обнаружения соответствующих данных может использовать путь «ACN, рабочая станция, IOP, внешний сервер, устройство» в иерархии 350.

По аналогии со службами аварийной сигнализации для внешних источников данных могут быть предусмотрены службы других типов с использованием иерархии 350 по фиг.4 и системы 102 сбора и распределения данных. Например, некоторые диагностические приложения регулярно собирают данные от модулей или об этих модулях в интегрированной системе и используют эти данные для диагностирования проблем, выявления неэффективного функционирования и т.д. Теперь одни и те же диагностические приложения можно использовать для сбора данных о внешних источниках данных с использованием модулей, созданных для этого источника данных. Таким образом, данные, необходимые для диагностического приложения, можно собирать в автоматическом режиме, коль скоро модуль, связанный с внешним источником данных, сконфигурирован для приема или сбора данных, необходимых для диагностического приложения, от внешнего источника данных. В некоторых случаях для диагностических целей можно использовать информацию о самом модуле, такую как изменчивость входных и выходных сигналов или других параметров модуля. Конечно, для указанных диагностических целей можно собирать или использовать любые требуемые данные. Подобно аварийным сигналам в иерархии 350 по фиг.5 могут быть заблокированы или разблокированы такие диагностические приложения, как приложение Inspect, поставляемое компанией Fisherosemount Systems Inc. Это диагностическое приложение подробно описано в заявке на патент США № 09/256585 «Diagnostics in a Process Control System». Конечно, другие диагностические приложения могут создавать индексы для внешнего источника данных, чтобы показать степень исправности этого источника данных либо устройства, связанного с источником данных. Такие индексы могут включать в себя индекс загрузки, индекс эффективности, индекс изменчивости или другой полезный индекс.

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

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

Как только система 102 сбора и распределения данных сконфигурирована, открывается возможность применения приложений множества других типов, которые могут использовать данные, собранные от разнородных источников данных, для выполнения новых или расширенных функций в технологической среде. Например, одно или несколько приложений в наборе 50 использования активов можно использовать для выполнения или контроля за выполнением одной или нескольких математических или программных моделей, которые моделируют работу конкретной установки или объектов в установке, таких как устройства, блоки, контуры, области и т.д. Таким образом, модели технологического процесса или устройств могут быть созданы и реализованы для использования собранных данных. В основе этих моделей могут лежать технологическое оборудование или технологические зоны. В одном варианте для создания этих моделей эксперт по моделированию разделяет установку на отдельные компоненты оборудования и создает модель для отдельных компонент на любом требуемом уровне абстрагирования. Например, модель для установки реализуется программными средствами и строится из или может включать в себя набор иерархически зависимых, связанных между собой модулей для различных областей установки. Аналогично, модель для любой области установки может быть выполнена из индивидуальных моделей для различных блоков в установке с соединениями между входами и выходами этих блоков. Таким же образом блоки могут быть построены из соединенных между собой моделей оборудования и т.д. Конечно, модели областей могут содержать модели устройств, соединенных с моделями блоков, моделями контуров и т.д. В этой примерной модельной иерархии входы и выходы моделей для объектов более низкого уровня, таких как модели устройств, могут быть соединены между собой для образования моделей объектов более высокого уровня, таких как модели блоков, входы и выходы которых могут быть соединены между собой для создания моделей более высокого уровня, таких как модели областей и т.д. Способ объединения или соединения между собой различных моделей, конечно, будет зависеть от моделируемой установки. Разумеется, эти модели могут получать необходимые данные от внешних источников данных вышеописанным образом.

Теперь со ссылками на фиг.7А и 7В будет описан пример использования иерархических программных моделей. На фиг.7А показаны модели для множества областей 380, 381 и 382 в установке для переработки нефти. Как показано на фиг.7А, модель 382 области включает в себя компонентную модель источника 384 сырья, который подает сырье, такое как сырая нефть, в модель 388 устройства предварительной обработки. Устройство 388 предварительной обработки обеспечивает некоторую переработку сырья и выдает обычно сырую нефть в технологический процесс 390 перегонки для дальнейшей переработки. В процессе 390 перегонки получают C₂H₄, обычно являющийся требуемым продуктом, и C₂H₆, который, в сущности говоря, относится к отходам. C₂H₆ подается обратно в установку 392 для крекинга С₂, выходной продукт которой поступает в устройство 388 предварительной обработки для дальнейшей обработки. Обратная связь от процесса 390 перегонки через устройство 392 для крекинга С₂ является рециркуляционным процессом. Таким образом, модель для области 382 может включать в себя отдельные модели для источника 384 сырья, устройства 388 предварительной обработки, процесса 390 перегонки и установки 392 для крекинга С₂, которые имеют входы и выходы, соединенные между собой так, как показано на фиг.7А. То есть, каждая компонентная модель может быть связана с входами и выходами других компонентных моделей так, как показано на фиг.7А, для формирования модели области 382. Разумеется, модели для других областей 380 и 381 могут иметь другие компонентные модели, имеющие связанные между собой входы и выходы. Эти модели могут быть реализованы в процессоре, связанном с внешним источником данных, и предоставлять выходные данные, такие как кпд и т.д., в интегрированную систему. В альтернативном варианте, модели могут быть реализованы в интегрированной системе и получать данные от одного или нескольких внешних источников данных.

Обратимся теперь к фиг.7В, где более подробно показана компонентная модель для процесса 390 перегонки, которая включает в себя перегонную колонну 400, имеющую верхнюю часть 400Т и нижнюю часть 400В. На входе 403 перегонной колонны 400 указаны давление и температура, которые могут быть связаны с выходом модели для устройства 388 предварительной обработки, показанного на фиг.7А. Однако эти входные данные могут быть установлены оператором либо быть установлены на базе входных данных или переменных в установке 10, полученных в результате реальных измерений. В сущности говоря, перегонная колонна 400 включает в себя несколько расположенных в ней пластин, причем во время процесса перегонки жидкость движется между этими пластинами. C₂H₄ производится в верхней части 400Т колонны 400, а сборник 402 орошающей фракции подает обратно часть этого продукта в верхнюю часть 400Т колонны 400. C₂H₆ обычно выходит из нижней части колонны 400, а ребойлер 404 закачивает полипропилен в нижнюю часть 400В колонны 400, способствуя процессу перегонки. Разумеется, при необходимости модель для процесса 390 перегонки может быть построена из компонентных моделей для перегонной колонны 400, сборника 402 орошающей фракции, ребойлера 404 и т.д., имеющих входы и выходы, соединенные так, как показано на фиг.7В, для формирования компонентной модели процесса 390 перегонки.

Как отмечалось выше, компонентная модель для процесса 390 дистилляции может быть выполнена как часть модели для области 382 либо отдельно и помимо любых других моделей. В частности, вход 403 в перегонную колонну 400 и/или выходы C₂H₄ и C₂H₆ могут реально измеряться, и эти измерения можно использовать в модели процесса 390 перегонки несколькими способами, как описано ниже. В одном варианте входы и выходы модели процесса 390 перегонки можно измерять и использовать для определения других факторов или параметров, связанных с моделью процесса 390 перегонки (таких как производительность перегонной колонны и т.д.) для того, чтобы модель процесса 390 перегонки более точно соответствовала работе реальной перегонной колонны в установке 10. Затем модель процесса 390 перегонки можно использовать вместе с вычисленными параметрами как часть более общей модели, такой как модель области или установки. В альтернативном варианте или в качестве дополнения, модель процесса 390 перегонки с вычисленными параметрами можно использовать для определения результатов виртуальных измерений датчиками или определения того, являются ли действительные результаты измерений датчиков в установке 10 ошибочными. Модель процесса 390 перегонки с определенными параметрами также можно использовать для управления или оптимизации использования активов и т.д. Кроме того, компонентные модели можно использовать для обнаружения и локализации возникающих в установке 10 проблем или чтобы понять, какие изменения в установке 10 могут повлиять на выбор параметров оптимизации для установки 10.

Если это потребуется, любая конкретная модель или компонентная модель может быть реализована для того, чтобы определить значения параметров, связанных с этой моделью. Некоторые или все эти параметры, такие как параметры эффективности, могут дать инженеру некоторую полезную информацию в контексте модели, но в общем случае они являются не измеряемыми в установке 10. В частности, компонентная модель может быть в общем случае математически описана уравнением Y=F(X,P), где выходы Y модели являются функцией входов X и набора параметров P модели. В примере модели перегонной колонны для процесса 390 перегонки по фиг.7В экспертная система может периодически собирать данные (например, каждый час, каждые 10 минут, каждую минуту и т.д.) от реальной установки, указывающие действительные входы Х и выходы Y объекта, к которому относится модель. Затем время от времени можно выполнить регрессионный анализ, такой как анализ на основе критерия максимального правдоподобия, метода наименьших квадратов или любой другой регрессионный анализ с использованием модели и множества наборов измеренных входов и выходов, чтобы определить наилучшую сходимость для неизвестных параметров Р модели на основе множества наборов измеренных данных. Таким образом параметры Р модели для любой конкретной модели можно определить, используя действительные или измеренные входы и выходы, для согласования модели с моделируемым объектом. Конечно, этот процесс может быть выполнен для любой или всех компонентных моделей, использованных в установке 10, с использованием любого подходящего количества измеренных входов и выходов. Кроме того, собранные данные либо информация, вычисленная на основе этих данных, могут быть переданы в систему 102 сбора и распределения данных и использованы в модулях, отражающих эти модели, элементах, моделируемых этими моделями, и т.д.

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

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

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

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

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

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

Кроме индексов эффективности и степени исправности блок 50 использования активов может помочь стандартной программе создания индексов при создании индексов других типов, таких как индекс загрузки и индекс изменчивости. Индекс изменчивости показывает, сколько раз некоторый входной или выходной сигнал или какой-либо другой параметр, связанный с устройством, контуром, блоком и т.д., изменяется, по сравнению с ожидаемым числом изменения этого сигнала или параметра. Данные, необходимые для создания этого индекса изменчивости, могут собираться набором 50 использования активов через систему 102 сбора и распределения данных и могут подаваться в стандартную программу создания индексов в любые требуемые или удобные моменты времени. Разумеется, стандартная величина изменения сигнала или параметра может быть установлена изготовителем, инженером, оператором или обслуживающим персоналом, знакомым с объектом, или может быть основана на статистическом показателе (таком как среднее значение, стандартное отклонение и т.д.), связанном с этими или другими аналогичными объектами в установке, и это стандартное или ожидаемое изменение может храниться или обновляться в стандартной программе создания индексов.

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

Как было указано выше, стандартная программа 244 интерфейса пользователя обеспечивает графический интерфейс пользователя (GUI), который объединен с описанным здесь набором 50 использования активов, для облегчения взаимодействия пользователя с различными возможностями использования активов, предусмотренными в наборе 50 использования активов. Однако, прежде чем подробно обсуждать интерфейс GUI, следует иметь в виду, что GUI может включать в себя одну или несколько стандартных программ, которые реализуются с использованием любых подходящих языков и технологий программирования. Кроме того, стандартные программы, образующие GUI, могут храниться и обрабатываться на одной станции или блоке обработки, таком как рабочая станция, контроллер и т.д., в установке 10 или, в альтернативном варианте, стандартные программы GUI могут храниться и выполняться на распределенной основе с использованием множества блоков обработки, которые связаны друг с другом с возможностью обмена данными в системе использования активов. Кроме того, данные, используемые интерфейсом GUI для создания определенных сценариев, могут быть доступны от внешних источников данных через систему 102 сбора и распределения данных.

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

В одном варианте по аналогии с вышеописанной фиг.5 интерфейс GUI может выполнять или представлять набор или ряд иерархических отображений, на которых определенным образом отображается на более высоком уровне более базовая или общая информация об особенностях системы управления технологическим процессом (такие как области, контуры, устройства, приложения для контроля эффективности стандартных программ контроллеров и т.д. в установке). Затем в ряде последующих отображений более низкого уровня, которые могут быть доступны путем выбора и щелчка «мышью» по любым конкретным данным на отображении более высокого уровня, можно получить дополнительную информацию: о стандартных программах управления, технического обслуживания; о соединениях между оборудованием для управления технологическим процессом; а также о данных действительных измерений; об операциях, выполняемых стандартной программой управления технологическим процессом, таких как формирование аварийных сигналов, выявление проблем и т.д.; о результатах измерения эффективности с рекомендациями по эффективности, прогнозами и т.д.; и информацию по техническому обслуживанию с указанием проблем, возникших в установке и т.д. Другие отображения более низкого уровня могут предоставить дополнительную информацию об элементах в указанных отображениях. В общем случае такое иерархическое отображение предоставляет больше информации о конкретных областях, контурах и т.д. и проблемах, с ними связанных, с точки зрения действий по управлению технологическим процессом, действий по техническому обслуживанию, а также действий в ходе технологического процесса, когда пользователь спускается или перемещается по более низким уровням в отображении.

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

Вдобавок, описанный здесь интерфейс GUI может автоматически или в ответ на запрос пользователя предоставить пользователю информацию о техническом обслуживании. Информация о техническом обслуживании может быть предоставлена любой частью набора 50 использования активов. Аналогично, GUI может отображать аварийную информацию, информацию об управлении технологическим процессом и т.д., которая также может быть предоставлена набором 50 использования активов. Кроме того, интерфейс GUI может обеспечить сообщение пользователю в связи с появившейся проблемой либо проблемой, которая возможно появится в установке 10. Эти сообщения могут включать в себя графическую и/или текстовую информацию, описывающую эту проблему, предложения по возможным изменениям в системе, которые можно реализовать для решения текущей проблемы или которые можно реализовать, чтобы избежать потенциальную проблему, а также эти сообщения указывают, в каком направлении следует действовать, чтобы решить проблему или избежать ее появление в будущем, и т.д.

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

На фиг.8 показан пример отображения, представляющего блок 500 в системе управления технологическим процессом, который может отображаться интерфейсом GUI. Как показано на фиг.8, блок 500 включает в себя множество устройств, таких как, например, вентили, насосы, первичные измерительные преобразователи температуры и т.д., которые могут быть графически изображены, как показано на этой фигуре. Вдобавок, отображение может включать в себя стрелки и любые другие указатели для представления логических и физических соединений между различными устройствами. Разумеется, такие графические представления систем управления технологическими процессами (или частей систем управления технологическими процессами) хорошо известны специалистам в данной области техники, и, поэтому, способ реализации этих графических представлений или отображений здесь подробно не описывается.

Отображение GUI, показанное на фиг.8, также включает в себя множество названий и значений 550 индексов. В частности, названия и значения 550 индексов включают в себя индекс эффективности, индекс степени исправности, индекс изменчивости и индекс нагрузки, которые кратко обсуждались выше в связи с набором 50 использования активов и его стандартной программой создания индексов. Названия и значения 550 индексов могут отображаться в табличном формате, как здесь показано, либо в любом другом требуемом формате. Названия и значения 550 индексов представляют эффективность и состояние всего блока 500 и таким образом показанные здесь значения индексов целесообразно, но не обязательно образуются из значений или полей индексов, связанных с каждым из субблоков и/или устройств, которые образуют блок 500.

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

В общем случае индексы, созданные стандартной программой генератора индексов и отображаемые через интерфейс GUI, могут вычисляться для отдельных устройств, для логических и/или физических групп устройств, для логических процессов (например, контуров управления), для логических групп технологического оборудования, таких как блоки и области, и т.д. Другими словами, индексы в принципе можно вычислять на каждом уровне оборудования и логической иерархии системы управления технологическим процессом или в более общем случае системы использования активов, которая может включать в себя одну или несколько систем управления технологическим процессом. Однако смысл конкретного индекса может зависеть от контекста (то есть, соответствует ли индекс логической или физической группе устройств и/или параметров), в котором создан и отображается индекс, и может зависеть от уровня иерархии, на котором он отображен. Например, на самом низком уровне иерархии оборудования индексы соответствуют физическим устройствам, таким как вентили, датчики температуры, исполнительные механизмы и т.д. Таким образом, каждое устройство может иметь уникальный набор индексов, который может быть создан в устройстве или для устройства на основе информации, записанной в устройстве в момент его изготовления. Соответственно, каждое устройство может создавать индексы и подавать их на более высокие уровни иерархии и в набор 50 использования активов, когда это потребуется.

Аналогичным образом, блоки или контуры, каждый из которых содержит одно или несколько устройств или функциональных блоков, могут иметь каждый уникальный набор индексов. Конечно, вычисление одного или нескольких индексов эффективности, степени исправности, изменчивости и загрузки возможно окажется нецелесообразным, не обязательным или бесполезным для каждого уровня логической иерархии и иерархии оборудования. Любой или все эти индексы могут показывать степень исправности устройства или другого объекта в системе. Например, индекс степени исправности (HI) для устройства может быть основан на использовании устройства в прошлом. В частности, изготовитель устройства может занести в память информацию, относящуюся к сроку службы устройства, и на основе использования устройства и воздействий окружающей среды на устройство во время его эксплуатации (например, изменения температуры, удары и т.д.), устройство может определить, где оно находится на кривой срока службы (то есть, оценить степень своего «старения»). Изготовитель может запрограммировать устройство таким образом, чтобы оно предоставляло значение HI, указывающее текущее состояние в контексте срока службы устройства. Например, вентиль ходового типа может иметь ожидаемый полезный рабочий срок службы, составляющий 250000 полных тактов, и изготовитель такового вентильного устройства, которое обычно является интеллектуальным полевым устройством, заносит ожидаемое количество рабочих тактов за время эксплуатации в его память, где также регистрируется текущее количество тактов, которое вентиль уже выполнил. Таким образом, в случае, когда значение HI может лежать в диапазоне от приемлемого значения, требующего технического обслуживания в ближайшем будущем (NMS) и требующего незамедлительного технического обслуживания (NMN), сформированное значение HI может базироваться на количестве тактов в диапазоне от нуля до 250000. Конечно, точная взаимосвязь между значениями HI и характеристикой срока службы (например, количество тактов) может быть нелинейной. Наоборот, многие характеристики срока службы изменяются во времени по экспоненциальному закону, в связи с чем количество отказов и случаев снижения эффективности/ухудшения работы устройств со временем и по мере нарастания количества выполненных тактов и т.д. возрастает. Конечно, имеется множество других способов определения или вычисления HI для устройства на основе определенного текущего состояния устройства и того, насколько хорошо оно работает. С другой стороны, индекс HI для контура не обязательно определять на основе функциональных блоков, которые его составляют.

Аналогично, индекс UI, вычисленный для уровней контура, области и блока, представляет степень, до которой загружен конкретный актив (например, контур) по сравнению с его пропускной способностью или требуемой загрузкой. Например, значение UI может базироваться на интервале времени, в течение которого используются контуры для реализации запланированного управления.

В математической комбинации значений индексов устройства для формирования значений индексов для уровней контуров, субблоков, блоков и областей иерархии могут использоваться результаты взвешенного суммирования или средние значения либо любая другая подходящая математическая комбинация. Конечно, вычисление одного или нескольких индексов эффективности, степени исправности, изменчивости и загрузки может оказаться ненужным или бесполезным для каждого уровня логической иерархии и иерархии оборудования. На фиг.9 показан пример таблицы, иллюстрирующей один способ возможного формирования индекса эффективности (PI), индекса степени исправности (HI), индекса изменчивости (VI) и индекса загрузки (UI) для уровней устройств, контуров, субблоков и блоков системной иерархии. Как показано на фиг.9, индекс PI можно создать для уровней блоков и субблоков. На уровнях блоков и субблоков индекс PI можно вычислить путем сравнения результата, полученного от модели (такой, как одна из моделей 56) блока или субблока, с действительной эффективностью блока или субблока либо любым другим желаемым образом. В частности, в этом контексте индекс PI (то есть, на уровнях блоков и субблоков иерархии) может представлять собой, например, кпд по отношению к теоретическому максимуму либо, в альтернативном варианте, по отношению к полученному эмпирическим путем максимальному кпд на основе действительного функционирования системы. В таблице, показанной на фиг.9, также указано, что индекс PI не обязательно вычисляется для отдельных устройств или контуров. Однако в некоторых приложениях может потребоваться вычисление PI для контуров и устройств. Например, в случае вычисления PI для устройства изготовитель устройства может ввести информацию об эффективности в память устройства, так что в процессе эксплуатации устройство может вычислять индекс PI на основе сравнения действительной характеристики эффективности (такой как, например, рабочий кпд) с хранящейся в памяти информацией об эффективности, которая может включать в себя максимальный теоретический кпд устройства. Конечно, эту функцию может также выполнять стандартная программа 51 создания индексов. В случае вычисления PI для индекса система может, например, сравнить максимальную или среднюю ошибку контура (то есть, сигнал ошибки в установившемся состоянии) с некоторым заранее определенным минимальным значением ошибки, которое в идеале может быть равно нулю. Таким образом, небольшая ошибка контура может соответствовать значению PI, указывающему на высокую эффективность.

На фиг.9 также показано, что индекс VI можно вычислять на уровнях контуров и устройств иерархии. На уровне устройств индекс VI можно вычислить путем сравнения изменений или отклонений в выходном сигнале устройства с ожидаемой или требуемой величиной изменения или отклонения. Чрезмерно высокое или чрезмерно низкое значение VI может указывать на отказ или неправильное функционирование устройства либо на возможный приближающийся отказ или неправильное функционирование в ближайшем будущем. Аналогично, на уровне контуров очень частые или большие по величине изменения выходного сигнала контура могут указывать на какую-то проблему. В любом случае вычисление VI для контуров и устройств может базироваться на сравнении действительной изменчивости параметра с ожидаемой изменчивостью параметра, которая может быть определена теоретическим или эмпирическим путем. Хотя на фиг.9 показано, что индекс VI в некоторых приложениях для уровней блоков и субблоков не вычисляется, тем не менее, возможно все же понадобится создать индекс VI для этих уровней.

Корме того, на фиг.9 показано, что индекс HI вычисляют для уровней устройств, контуров, субблоков и блоков. Индекс HI для устройства можно вычислить на основе истории использования устройства. В частности, изготовитель устройства может занести информацию, относящуюся к сроку службы устройства, в память устройства, и на основе использования устройства и воздействий окружающей среды на устройство во время его эксплуатации (например, изменения температуры, удары и т.д.) устройство может определить, где находится устройство на кривой срока его службы (то есть, насколько оно «состарилось»). Изготовитель может запрограммировать устройство, чтобы оно предоставляло значение HI, указывающее текущее состояние в контексте срока службы устройства. Например, вентили ходового типа могут иметь ожидаемый полезный рабочий срок службы 250000 полных тактов, при этом изготовитель такого вентильного устройства, которое обычно является интеллектуальным полевым устройством, заносит в его память ожидаемое количество рабочих тактов за жизненный цикл устройства, а кроме того в этой памяти фиксируется количество тактов, которое вентиль на данный момент совершил. Таким образом, в случае, когда значение HI может лежать в диапазоне от нуля до десяти (где нуль представляет низкую степень исправности, а десять представляет идеальную степень исправности), значение HI, созданное вентилем, может лежать в диапазоне от нуля до десяти, когда количество тактов возрастает от нуля до 250000. Разумеется, точная взаимосвязь между значениями HI и характеристикой срока службы (например, количество тактов) может быть нелинейной. Наоборот, многие характеристики срока службы подчиняются экспоненциальному закону, в связи с чем количество отказов и случаев снижения эффективности/ухудшения работы устройств со временем и по мере нарастания количества выполненных тактов и т.д. возрастает. Конечно, имеется множество других способов определения или вычисления HI для устройства на основе определенного текущего состояния устройства и того, насколько хорошо оно работает. Например, если в устройстве обнаружены две незначительные проблемы, его HI может уменьшиться.

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

На фиг.9 также показано, что индекс UI можно вычислить для уровней контуров, субблоков и блоков, а для уровня устройств его вычисление может не потребоваться. В сущности говоря, индекс UI представляет степень использования конкретного актива (например, контура, субблока или блока) по сравнению с его пропускной способностью или требуемой загрузкой. Например, значение UI может быть основано на интервале времени, в течение которого блок, субблок или контур используется для управления или формирования выходных сигналов. Вдобавок, или в качестве альтернативного варианта, значение UI может быть основано на объеме материала, который обрабатывается контуром, субблоком и/или блоком по сравнению с максимальным объемом, который может быть обработан этим контуром, субблоком, блоком и т.д.

На фиг.10 показан пример таблицы, иллюстрирующей один возможный способ вычисления индекса PI для блока 500, показанного на фиг.8. Как показано на фиг.10, каждый из множества контуров 575, образующих блок 500, имеет свой собственный индекс PI и весовой коэффициент, который может выбираться пользователем или выбираться на основе относительной важности данного конкретного контура для работы блока 500 в целом. Тогда индексы и вес для контуров 575 могут быть математически скомбинированы с использованием взвешенного среднего, чтобы получить значение индекса PI, равное 83,2 для блока 500.

Аналогичным образом индекс HI для блока 500 можно вычислить как взвешенное среднее значений HI для всех устройств (и/или контуров), образующих блок 500. Для представления значений, необходимых для включения во взвешенное среднее, можно использовать таблицу типа той, что показана на фиг.11. На фиг.11 также приведено текстовое описание, которое может быть связано с конкретными устройствами и значениями индексов. Эти текстовые описания могут нести диагностическую информацию, информацию о техническом обслуживании и т.д. на основе значения HI и конкретного устройства, связанного с этим значением HI.

На фиг.12 показан пример таблицы, иллюстрирующей один возможный способ вычисления VI для блока, такого как блок 500, показанный на фиг.8. Как и в случае с индексом HI, вычисление индекса VI для блока 500 на фиг.8 основано на взвешенном среднем значений VI для отдельных устройств, контуров и/или субблоков, которые образуют блок 500. Конечно, интерфейс GUI может предоставить пользователю возможность просмотра данных о взвешенных средних значениях, таких как те, что показаны на фигурах 10-12, и может предоставить пользователю возможность изменить весовые коэффициенты.

На фиг.13 показан пример графического отображения, которое может быть обеспечено интерфейсом GUI, чтобы предоставить пользователю возможность контроля характеристик блока, субблока, контура, устройства и т.д. в установке 10. Как показано на фиг.13, значения различных индексов могут быть представлены в функции времени, что позволяет пользователю наглядным образом проанализировать тенденции или какие-либо другие изменения во времени, которые могут оказаться индикаторами какой-то проблемы. Кроме того, такое графическое изображение может также помочь обнаружить важные корреляции или взаимосвязи между изменениями различных индексов. Например, пользователю возможно будет легче идентифицировать взаимосвязь между уменьшающимся или низким значением индекса HI и возрастающим или чрезвычайно высоким значением индекса VI.

Кроме того, интерфейс GUI может также обеспечивать текстовые сообщения в графическом отображении, показанном на фиг.13, либо в каком-то другом отображении или странице, которые укажут пользователю на текущие или потенциальные проблемы, возможно связанные с отображенными значениями или изменениями индексов. Эти текстовые сообщения могут предложить возможные решения идентифицированных проблем. Хотя графическая информация, представленная на фиг.13, масштабирована таким образом, что индексы выражены в процентах, а на оси времени проставлены помесячные отметки, вместо них можно использовать любые другие единицы и разрешающую способность отображения. Например, в случае, когда индексы могут изменяться быстро, интерфейс GUI может разрешить пользователю отображать значения индексов на почасовой основе, поминутно, каждые несколько секунд или чаще (то есть, с более высоким разрешением во времени), если это потребуется.

На фиг.14 показан пример графического отображения, которое может быть обеспечено интерфейсом GUI, чтобы позволить пользователю быстро проанализировать рабочее состояние и эффективность работы технологической области в установке 10. Как показано на фиг.14, интерфейс GUI может графически изобразить физическое оборудование (и соединения между элементами оборудования) в технологической области 600. Разумеется, следует понимать, что, хотя технологическая зона показана внутри отображения GUI, показанного на фиг.14, вместо нее может быть показана любая другая часть установки 10, такая как, например, блок, субблок, контур, устройство и т.д., для достижения тех же самых или аналогичных результатов. В любом случае здесь показано, что технологическая область 600 имеет пару резервуаров, множество первичных измерительных преобразователей температуры, давления, расхода и т.д. и трубы, которые могут быть соединены так, как показано на фиг.14. Кроме того, каждое из физических устройств может быть отображено вместе с соответствующим алфавитно-цифровым идентификатором (например, ТТ-394), который уникальным образом идентифицирует это устройство в установке 10, а также может быть отображено вместе с датчиком или графическим измерителем, дающим графическое представление (то есть, частично затушеванные диаграммы в виде полукруга), что позволяет пользователю быстро определить состояние измеряемого параметра, связанного с этим устройством. Например, интерфейс GUI может отображать графический измеритель или датчик, связанный с первичным преобразователем температуры и может затушевывать большую или меньшую часть измерителя в соответствии с температурой, измеряемой в данный момент первичным преобразователем температуры. Важно, что одно или несколько значений индексов VI, HI, UI и PI могут отображаться для одного или нескольких устройств, показанных в области 600. Только в качестве примера, здесь отображаются значения HI для нескольких устройств, которые соединены с резервуаром 610 в области 600. Однако, если это потребуется, то может быть отображено больше или меньше значений HI. Вдобавок, если это необходимо, то могут быть отображены и значения других индексов или группы значений индексов для любого из устройств, которые имеются в области 600. Как можно понять из отображения, показанного на фиг.14, пользователь может быстро установить, правильно ли функционирует область и будет ли она продолжать правильно функционировать. Кроме того, пользователь может быстро идентифицировать те устройства, блоки, субблоки и т.д., которые могут потребовать внимания и/или которые могут вызвать конкретную проблему.

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

На фиг.15 показан пример отображения, которое может быть предоставлено интерфейсу GUI, чтобы дать возможность пользователю просмотреть информацию в контрольном журнале вместе с любым устройством, используемым в области 600. Например, пользователь может использовать мышь, чтобы щелкнуть по данному устройству либо его алфавитно-цифровому идентификатору, или, в альтернативном варианте, может ввести идентификатор с клавиатуры, чтобы запросить всплывающее окно 650 контрольного журнала для этого устройства. Таким путем пользователь может использовать информацию в контрольном журнале для: определения того, может ли неправильное или неприемлемое значение индекса быть связано с отказом, чтобы правильно и своевременно откалибровать устройство; было ли устройство правильно или полностью сконфигурировано, и т.д.

На фиг.16 показан пример отображения, которое может быть предоставлено интерфейсом GUI, чтобы дать пользователю возможность выполнить более подробный анализ данных, который можно использовать при создании одного или нескольких индексов для конкретного устройства в области 600 или для выполнения контроля состояния. Только в качестве примера, во всплывающем окне 680 могут быть отражены результаты анализа вибраций для двигаеля 675. Пользователь может запросить указанное всплывающее окно в ответ на ненормально высокое или ненормально низкое значение индекса для блока, подвергающегося воздействию двигателя 675, и/или может запросить это окно, если значение индекса, связанное с этим двигателем, указывает на возможную проблему. Кроме того, если это потребуется, интерфейс GUI может автоматически предложить указанные всплывающие окна, содержащие подробный анализ данных для этих устройств, блоков и т.д., которые имеют одно или несколько ненормальных значений индексов. Аналогичным образом на фиг.17 показан пример отображения, которое может быть обеспечено интерфейсом GUI, чтобы дать возможность пользователю получить графическое представление или проконтролировать показатель эффективности устройства в области 600. Например, всплывающее окно 690, включая график кпд двигателя 675, предлагается в ответ на запрос пользователя или, в альтернативном варианте, в ответ на автоматический запрос со стороны экспертной программы 59 использования активов. Такое всплывающее окно можно запросить либо оно потребуется, если ненормальным оказывается одно или несколько значений индексов, связанных с частью технологического процесса, выполняемой с использованием резервуара 610. В частности, в данном примере пользователь может определить, что двигатель 675 имеет низкое значение PI и/или что область 600 имеет низкое значение PI. В результате пользователь может запросить более подробную информацию, такую как информация, содержащаяся во всплывающем окне 690, чтобы определить, существует ли проблема с двигателем 675. Также в этом примере всплывающее окно может содержать график кпд двигателя 675 в функции времени, где графически представлены данные 700 о действительном кпд по сравнению с данными 710 о максимальном кпд, полученными теоретическим или эмпирическим путем. Как обсуждалось выше, эти два набора данных по кпд можно также использовать для вычисления значения PI в функции времени для двигателя 675, например, путем использования в качестве значения PI отношения действительного кпд к его максимальному теоретическому значению.

На фиг.18 показан еще один пример отображения, которое может быть предложено интерфейсом GUI, чтобы предоставить пользователю возможность быстро проанализировать аварийную информацию, состояния (статусы) и т.д. в установке 10. Графическое изображение 750 высокого уровня для установки 10 может включать в себя баннер 760 аварийной сигнализации, имеющий один или несколько «подвешенных» аварийных сигналов. Каждый из аварийных сигналов в баннере аварийной сигнализации может быть представлен с использованием алфавитно-цифрового индикатора, который уникальным образом связан с устройством, создавшим аварийный сигнал или событие. Вдобавок, каждый из аварийных сигналов в баннере 760 может также включать в себя информационную кнопку 770, которую может выбрать пользователь для создания всплывающего окна 775, содержащего более подробную информацию, относящуюся к этому конкретному аварийному сигналу. Далее пользователь может также выбрать алфавитно-цифровое обозначение для устройства, вызвавшего конкретный аварийный сигнал, для исследования возможных причин появления этого аварийного сигнала. Когда алфавитно-цифровое обозначение выбрано, интерфейс GUI может предоставить всплывающее окно 780. Всплывающее окно 780 может предоставить одну или несколько категорий 785 ответов, которые могут помочь пользователю понять, с чем следует связать конкретный аварийный сигнал и в каком временном кадре следует это сделать. Например, всплывающее окно 780 может показать, что с конкретным устройством отсутствует связь, что это устройство отказало, что это устройство нуждается в немедленном техническом обслуживании либо что потребуется техническое обслуживание или какое-то другое внимание к этому устройству в ближайшем будущем. Конечно, вместо указанных категорий ответов можно использовать больше, меньше и/или другие категории ответов. Отображение аварийных сигналов, созданное интерфейсом GUI в этой точке, может представлять собой интегрированное отображение, раскрытое в заявке на патент США №09/707580 (поданной 7 ноября 2000 года), содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки. В общем случае это отображение аварийных сигналов может показывать аварийные сигналы и предупреждения, относящиеся к технологическому процессу, а также аварийные сигналы других типов, такие как аварийные сигналы и предупреждения для технического обслуживания. Кроме того, в GUI или экспертную программу 59 использования активов вместе с аварийным сигналом может быть послана информация о нем, к примеру, специальная информация, предусмотренная в поле 775 баннера аварийной сигнализации.

Хотя система 102 сбора и распределения данных, а также набор 50 использования активов и другие элементы были описаны в предположении, что они предпочтительно реализованы программными средствами, они могут быть реализованы аппаратными средствами, аппаратно-программными средствами и т.д., а также могут быть реализованы с помощью любого другого процессора, связанного с системой 10 управления технологическим процессом. Таким образом, описанные здесь элементы могут быть реализованы в стандартном процессоре (CPU) общего назначения или в специализированном аппаратном средстве или в аппаратно-программном средстве, таком как специализированная интегральная схема (ASIC) либо другом схемно-реализованном устройстве, если это потребуется. При программной реализации стандартная программа может храниться в любом запоминающем устройстве, считываемом компьютером, таком как магнитный диск, лазерный диск или другая запоминающая среда, в ОЗУ или ПЗУ компьютера или процессора, любой базе данных и т.д. Аналогичным образом, эти программные средства могут быть доставлены пользователю или в установку для управления технологическим процессом посредством любого известного или требуемого способа доставки, в том числе, например, на диске, считываемом компьютером, либо посредством другого транспортируемого механизма компьютерной памяти, либо по каналу связи, такому как телефонная линия, Интернет и т.д. (которые рассматриваются как идентичные или взаимозаменяемые при доставке указанных программных средств посредством транспортируемого носителя данных). Также, хотя набор 50 описан в виде экспертной программы, действующей на основе правил или как использующий такую программу, могут также быть использованы экспертные механизмы других типов, в том числе те, в которых применяются другие известные технологии извлечения информации из данных.

Обратимся теперь к фиг.19, где представлена блок-схема, иллюстрирующая потоки данных между экспертной программой 59 использования активов и другими компьютерными инструментами или приложениями в технологической установке 10. Фиг.19 описывается со ссылками на фиг.1. В частности, экспертная программа 59 использования активов может принимать информацию от множества средств сбора данных или источников данных, таких как мультиплексоры, первичные измерительные преобразователи, датчики, переносные устройства, системы управления, радиочастотные (RF) приемопередатчики, онлайновые системы управления, Web-серверы, архивы, модули управления или другие управляющие приложения в технологической установке 10, интерфейсы, такие как интерфейсы пользователя и интерфейсы ввода/вывода, а также серверы данных, такие как шины (например, шины Fieldbus, HART и Ethernet), вентили, приемопередатчики, датчики, серверы и контроллеры и другие активы установки, такие как контрольно-измерительная аппаратура для технологического процесса, вращающееся оборудование, электрическое оборудование, оборудование для производства электроэнергии и т.д. Эти данные могут быть представлены в любой желаемой форме в зависимости от того, каким образом они созданы или используются другими функциональными системами. Кроме того, эти данные могут быть посланы в экспертную программу 59 использования активов с использованием любого желаемого или подходящего протокола обмена данными и аппаратных средств связи, таких как вышеописанный протокол XML. Однако, в общем случае, установка 10 может быть выполнена таким образом, что экспертная программа 59 использования активов будет автоматически принимать данные определенных типов от одного или нескольких источников данных, и так что экспертная программа 59 использования активов сможет предпринимать заранее определенные действия в соответствии с этими данными.

Экспертная программа 59 использования активов также принимает информацию от (и может действительно выполнять) инструментов анализа данных, таких как типовые инструменты анализа данных технического обслуживания, которые предоставлены на сегодняшний день, инструменты, отслеживающие показатели эффективности, такие как инструменты, связанные с устройствами, а также инструменты, отслеживающие показатели эффективности для систем управления технологическим процессом, типа тех, что описаны в заявках на патент США №№ 09/256585 и 09/499445, указанных выше. Инструменты для анализа данных могут также включать в себя, например, приложение для диагностики коренных причин, которое обнаруживает коренные причины возникновения проблем некоторых типов, а также для обнаружения событий, как описано в патенте США №6017143, диагностики контуров регулирования, как описано в заявке на патент США № 09/303869 (поданной 3 мая 1999 года), содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки, приложения для определения засорения импульсных трубопроводов, как описано в заявке на патент США № 09/257896 (поданной 25 февраля 1999 года), содержание которой включено в настоящее описание во всей своей полноте в качестве ссылки, приложения для обнаружения других засоренных трубопроводов, приложения для определения состояния устройств, приложения для конфигурации устройств и приложения для технического обслуживания, хранение устройств, инструменты для архивов и отображения информации, такие как AMS, приложения Explorer и приложения для ведения контрольного журнала. Кроме того, экспертная программа 59 может принимать данные и любую информацию от средств анализа данных управления технологическим процессом, таких как развитая управляющая экспертная программа 52, стандартные программы управления с предсказанием на модели, такие как программы, описанные в заявках на патент США №№ 09/593327 (поданной 14 июня 2000 года) и 09/412078 (поданной 4 октября 1999 года), содержание которых включено в настоящее описание во всей своей полноте в качестве ссылки; стандартные программы настройки, стандартные программы управления на основе нечеткой логики и стандартные программы управления на основе нейронной сети, а также от виртуальных датчиков, таких как те, что описаны в патенте США № 5680409, которые могут быть предусмотрены в системе 10 управления технологическим процессом. Кроме того, экспертная программа 59 использования активов может принимать информацию от инструментов анализа данных, относящихся к вращающемуся оборудованию, такую как: информация о вибрациях в системе; информация от беспроводных радиочастотных датчиков и переносных блоков сбора данных; данные анализа смазки, связанной с вращающимся оборудованием; данные термографического анализа; информация от ультразвуковых систем и систем лазерного выравнивания и балансировки, причем все вышеперечисленное может относиться к выявлению проблем или определению состояния вращающегося оборудования в технологической установке 10. Эти инструменты известны на сегодня специалистам в данной области техники, и поэтому далее подробно не описываются. Кроме того, экспертная программа 59 использования активов может принимать данные, относящиеся к управлению режимом электроснабжения и силовому оборудованию и поставкам, к примеру, от приложений 23 и 27 по фиг.1, которые могут включать в себя любые требуемые инструменты для управления режимом электроснабжения, контроля и анализа силового оборудования.

В одном варианте экспертная программа 59 использования активов выполняет или контролирует выполнение математических программных моделей 56 части или всего оборудования установки 10, таких как моделей устройств, моделей контуров, моделей блоков, моделей областей и т.д., которые реализуются, например, компьютером 30 либо любым другим требуемым компьютером в технологической установке 10. Экспертная программа 59 использования активов может использовать данные, полученные этими моделями или связанные с этими моделями по ряду причин. Некоторые из этих данных (или сами модели) можно использовать для создания виртуальных датчиков в установке 10. Некоторые из этих данных или сами модели можно использовать для реализации управления с предсказанием или оптимального управления в реальном времени в установке 10. Некоторые из данных, созданных моделями 56, могут использоваться стандартной программой 51 создания индексов для получения индексов, которые используются в других приложениях, таких как приложения для коммерческих задач и для управления технологическим процессом.

Экспертная программа 59 использования активов принимает данные в момент их создания или на определенных периодических интервалах, например, по шине 32 или любой другой сети связи в технологической установке 10. После этого экспертная программа 59 использования активов периодически или по мере надобности перераспределяет эти данные по другим приложениям или использует их для создания и предоставления другой информации, полезной для разных аспектов управления или функционирования технологической установки 10, другим функциональным системам в установке 10. В частности, экспертная программа 59 использования активов может поставлять данные, которые инициируют создание ряда составных индексов стандартной программой 51 создания индексов, таких как индекс эффективности, индекс загрузки, индекс степени исправности и индекс изменчивости, связанных с одним или несколькими устройствами, блоками, контурами, областями или другими объектами в технологической установке 10. Создание и использование этих индексов более подробно обсуждается ниже.

Экспертная программа 59 использования активов может также предоставлять данные стандартным программам 862 управления и получать от них данные, которые могут находиться в технологических контроллерах или интерфейсах, связанных с этими контроллерами, оптимизаторам 55, приложениям 863 для коммерческих задач, приложениям 866 технического обслуживания и т.д.

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

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

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

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

Таким образом, как будет понятно далее, как только данные будут приняты в центральной базе данных и преобразованы, например, в общий формат, эти данные запоминаются в базе данных некоторым доступным образом и оказываются доступными приложениям или пользователям в экспертной программе 59 использования активов. Например, приложения, относящиеся к управлению технологическим процессом, аварийной сигнализации, техническому обслуживанию устройств, диагностике неисправностей, предупредительному техническому обслуживанию, финансовому планированию, оптимизации и т.д., могут использовать, объединять и интегрировать данные от одного или нескольких различных источников данных для более качественной работы, чем в случае, когда эти приложения могли работать в прошлом при отсутствии данных от чрезвычайно различающихся и ранее недоступных источников данных. Приложения, показанные на фиг.19 и являющиеся частью экспертной программы 59 использования активов, могут являться любыми приложениями, описанными на фиг.1, либо могут представлять собой приложения любых других типов, если это потребуется. Конечно, как источники данных, так и приложения, которые используют собранные данные, показанные на фиг.19, являются по существу лишь примерами, и можно использовать больше, меньше или другие источники данных и приложения. Аналогичным образом, сами источники данных могут быть выполнены с возможностью приема данных, собранных системой сбора и распределения данных или базой данных. Таким путем различные поставщики продукции или услуг, которые могут иметь фирменные приложения, имеют возможность собирать определенные данные, которые они не имели или были не способны получать ранее от технологической установки, что может повысить качество продуктов или услуг, предоставляемых этими поставщиками услуг.

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

Как упоминалось выше, экспертная программа 59 использования активов может выполнять или контролировать выполнение одной или нескольких математических или программных моделей 56, которые моделируют работу конкретной установки или объектов в этой установке, таких как устройства, блоки, контуры, области и т.д. Эти модели могут быть аппаратными моделями либо моделями управления технологическим процессом. В одном варианте для создания этих моделей эксперт по моделированию разделяет установку на отдельные аппаратные средства и/или части для управления технологическим процессом и предлагает модели для отдельных частей на любом желаемом уровне абстрагирования. Например, модель для установки реализуется программными средствами и строится из или может включать в себя набор соединенных между собой иерархических моделей для разных областей установки. Аналогичным образом модель для любой области установки может быть построена из отдельных моделей для разных блоков в установке вместе с соединениями между входами и выходами этих блоков. Аналогичным образом блоки могут быть построены из соединенных между собой моделей устройств и т.д. Разумеется, модели областей могут иметь модели устройств, соединенные с моделями блоков, моделями контуров и т.д. В этом примере иерархии моделей входы и выходы моделей для объектов более низкого уровня, таких как устройства, могут быть соединены друг с другом для создания моделей объектов более высокого уровня, таких как блоки, входы и выходы которых могут быть соединены другом с другом для построения моделей еще более высокого уровня, таких как модели областей и т.д. Способ объединения или соединения друг с другом различных моделей, разумеется, будет зависеть от моделируемой установки. Хотя можно использовать единую полную математическую модель для всей установки, очевидно, что по ряду причин полезно предложить разные независимые компонентные модели для различных частей или объектов в установке, таких как области, блоки, контуры, устройства и т.д., и соединить эти разные модели между собой для формирования более крупных моделей. Кроме того, желательно использовать компонентные модели, которые могут выполняться независимо друг от друга, а также вместе с другими компонентными моделями как часть более крупной модели.

Хотя для модели установки в целом или для любой или всех компонентных моделей можно использовать очень точные математические или теоретические модели (такие как модели третьего или четвертого порядка), отдельные математические модели не обязательно должны отличаться высокой точностью и могут представлять собой, например, модели первого или второго прядка либо модели других типов. Эти упрощенные модели в общем случае могут выполняться быстрее программным путем и могут быть сделаны более точными путем согласования входных и выходных данных этих моделей с реальными измерениями входов и выходов, выполненными в установке описанным здесь путем. Другими словами, отдельные модели могут быть настроены или доведены, чтобы обеспечить точное моделирование установки или объектов в установке на основе действительной обратной связи от установки.

Примеры иерархических моделей, которые можно использовать, обсуждались со ссылками на фиг.7А и 7В.

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

Кроме индексов эффективности и степени исправности экспертная программа 59 использования активов может помочь стандартной программе 51 создания индексов при создании индексов других типов, таких как индекс загрузки и индекс изменчивости. Индекс изменчивости показывает, сколько раз изменяется некоторый входной или выходной сигнал либо какой-либо другой параметр, связанный с устройством, контуром, блоком и т.д., по сравнению с ожидаемым количеством изменений этого сигнала или параметра. Данные, необходимые для создания этого индекса изменчивости, может собрать экспертная программа 59 использования активов, которая предоставляет их стандартной программе 51 для создания индексов в любые требуемые или удобные моменты времени. Конечно, нормальное количество изменений сигнала или параметра может быть установлено изготовителем, инженером, оператором или обслуживающим персоналом, знакомым с объектом, либо оно может быть основано на статистическом показателе (таком как среднее значение, стандартное отклонение и т.д.), связанном с этим или другими аналогичными объектами в установке, и это нормальное или ожидаемое значение изменения может храниться или обновляться в стандартной программе 51 для создания индексов.

Обратимся теперь к фиг.20, со ссылками на которую будет описан способ предоставления дистанционного доступа к моделям, оптимизаторам и другим инструментам для анализа данных, таким как инструменты для контроля эффективности для одной или нескольких технологических установок. Как показано на фиг.20, одна или несколько технологических установок 900, 901, 902 и 903 работают независимо. Каждая из установок 900-903 периодически собирает данные, относящиеся к установке, а затем посылает эти данные в средство обработки данных или средство 910 дистанционного контроля. Для выполнения этой функции каждая из установок 900-903 имеет интерфейс пользователя или сервер 900А-903А, причем эти серверы соединены через любую требуемую сеть связи, такую как Интернет или глобальная Web-сеть, со средством 910 дистанционного контроля.

Как показано на фиг.21, средство 910 дистанционного контроля включает в себя Web-сервер 912, через который процессы 900-903 осуществляют связь со средством 910 дистанционного контроля. Средство 910 дистанционного контроля также включает в себя один или несколько процессоров 914, имеющих соответствующие базы данных, которые запоминают и выполняют ряд приложений или инструментов для контроля технологического процесса. В частности, каждый процессор 914 может иметь доступ к и выполнять модели 916, такие как описанные здесь компонентные модели, которые были созданы для моделирования одной или нескольких установок 900-903 или объектов в этих установках. Модели 916 могут включать в себя различные компонентные модели для каждой из различных установок 900-903, причем эти модели 916 могут быть видоизменены или скорректированы персоналом в установках 900-903 посредством связи со средством 910, например, для отражения изменений в установках 900-903. Процессоры 914 могут также запоминать и выполнять программы оптимизаторов в реальном времени, либо оптимизаторов 918 любого другого вида, которые могут быть реализованы, как было описано здесь со ссылками на фиг.1 и 2, с использованием данных от технологических процессов 900-903. Кроме того, процессоры 914 могут иметь доступ и выполнять программы других инструментов 920 контроля данных, в том числе, например, любые приложения или инструменты в любой из компьютерных систем по фиг.1, такие как любой из инструментов для управления технологическим процессом, инструментов для контроля технологического процесса, инструментов для контроля оборудования или устройств, инструментов для создания индексов, инструментов для оформления нарядов на работы, инструментов для решения коммерческих задач или других описанных здесь инструментов или приложений. В одном примере для контроля параметров технологического процесса можно использовать инструмент для контроля технологического процесса, описанный в заявках на патенты США №№ 09/256585 и 09/499445.

Во время работы любой из процессов 900-903 может в подходящие моменты времени собирать входные и выходные данные, связанные с процессом, и предоставлять указанные данные в средство 910 дистанционного контроля через один из серверов 900А-903А и «Всемирную паутину», интерсеть или другую сеть связи, соединенную с сервером 912. После приема данных от установки соответствующий процессор из группы процессоров 914 обращается к этим данным и выполняет соответствующие программы инструментов контроля технологического процесса и контроля состояния для этой установки с целью выявления проблем в установке на основе собранных данных, обеспечения контроля состояния установки или технологического процесса либо выполнения оптимизации для установки. Разумеется, данные, собранные в установке и посланные в средство 910 дистанционного контроля, являются данными, определенными ранее как необходимые для выполнения требуемых моделей 916, оптимизаторов 918 или других инструментов 920 для анализа данных, которые собираются и посылаются в средство 910 на периодической или непериодической основе, подходящей для выполняемых инструментов или моделей. Таким образом, для оптимизаторов, возможно, придется собирать и посылать данные с другой частотой, чем для моделей или для инструментов контроля эффективности, технологического процесса или активов. Конечно, в качестве составной части средств, реализующих процесс оптимизации или контроля эффективности, состояния или технологического процесса, могут выполняться любые подходящие модели или другие инструменты, причем выполнение этих моделей или других инструментов обычно подчиняется принципам, обсужденным выше в связи с теми же самыми инструментами в установке 10 по фиг.1.

В любом случае после выполнения моделей, инструментов для анализа данных или оптимизации процессор 914 возвращает результаты обратно на сервер 912, откуда эти результаты могут быть взяты соответствующей установкой из набора установок 900-903 в любой требуемый момент времени. В альтернативном варианте или дополнительно, эти результаты могут быть непосредственно направлены сервером 912 в одну соответствующую установку из набора установок 900-903. Результирующие данные анализа могут представлять собой любые требуемые данные, графики или диаграммы моделирования процесса функционирования, в том числе, например, описанные выше в связи со стандартными программами интерфейса пользователя или стандартной программой 58 интерфейса GUI. Результаты могут также быть представлены, например, оптимизатором в виде предложений по внесению изменений в установки, индексы для установок, либо любые другие результаты, которые могут предложить инструменты этих типов.

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

Таким путем средство 910 дистанционного контроля может выполнять программы для контроля активов, эффективности, статуса и технологического процесса, а также выполнять одну или несколько программ оптимизации для различных установок. Это, в свою очередь, означает, что установки 900-903 не обязательно должны иметь соответствующие вычислительные возможности или приложения для этих целей, что может снизить затраты на установки. Разумеется, установки могут вносить плату за использование средства 910 дистанционного контроля по факту или на основе какого-то другого заранее определенного графика оплаты. Если потребуется, средство 910 дистанционного контроля может по договоренности получать часть доходов и/или компенсировать потери установки на основе использования инструментов в средстве 910 и реализации результатов работы этих инструментов.

Если потребуется, каждая из установок 900-903 может обновлять модели 916, хранящиеся в средстве 910 дистанционного контроля, применимом для этих установок, путем посылки новых или обновленных моделей на сервер 912 с использованием любого требуемого формата связи, такого как XML, HTML, и т.д. Кроме того, средство 910 дистанционного контроля может включать в себя исходные образцы для различных технологических установок, областей, блоков, устройств, контуров и т.д., которые могут быть загружены в каждую из установок 900-903 через сервер 912, причем эти образцы могут изменяться в установках 900-903 для отражения действительной работы этих установок. Затем обновленные модели могут быть посланы обратно в средство 910 для дистанционного контроля в виде моделей, подлежащих реализации при контроле активов, состояния или технологического процесса либо в оптимизаторах для данной установки. Таким путем в средстве 910 дистанционного контроля могу быть адекватно или точно отражены изменения в установках 900-903.

Хотя экспертная программа 59 использования активов и другие элементы процесса были описаны в предположении, что они предпочтительно реализованы программными средствами, они могут быть реализованы аппаратными средствами, аппаратно-программными средствами и т.д. и могут быть реализованы с помощью любого другого процессора, связанного с системой 10 управления технологическим процессом. Таким образом, описанные здесь элементы могут быть реализованы в стандартном процессоре (CPU) общего назначения или в специализированном аппаратном средстве или в аппаратно-программном средстве, таком как специализированная интегральная схема (ASIC) либо другом схемно-реализованном устройстве, если это потребуется. При программной реализации стандартная программа может храниться в любом запоминающем устройстве, считываемом компьютером, таком как магнитный диск, лазерный диск или другая запоминающая среда, в ОЗУ или ПЗУ компьютера или процессора, любой базе данных и т.д. Аналогичным образом эти программные средства могут быть доставлены пользователю или в технологическую установку посредством любого известного или требуемого способа доставки, в том числе, например, на диске, считываемом компьютером, либо посредством другого транспортируемого механизма компьютерной памяти, либо по каналу связи, такому как телефонная линия, Интернет и т.д. (которые рассматриваются как идентичные или взаимозаменяемые при предоставлении указанных программных средств через транспортируемую запоминающую среду). Кроме того, хотя здесь экспертная программа 59 описана в виде экспертной программы, действующей на основе правил, могут также быть использованы экспертные механизмы других типов, в том числе те, в которых применяются другие известные технологии извлечения информации из данных.

Вновь обратимся к фиг.1, где технологическая установка 10 может включать в себя одну или несколько систем 12 и 14 управления. На фиг.22 показана в качестве примера система 1000 управления технологическим процессом. Сеть или система 1000 управления технологическим процессом включает в себя один или несколько технологических контроллеров 1012, подсоединенных к одной или нескольким ведущим рабочим станциям или компьютерам 1014 (которые могут представлять собой персональный компьютер или рабочую станцию любого типа) и наборы устройств 1020, 1022 ввода/вывода (I/O), каждое из которых подсоединено к одному или нескольким полевым устройствам 1025-1039. Контроллеры 1012 могут представлять собой, например, контроллеры DeltaV^TM, поставляемые фирмой Fisher Rosemount Systems, Inc., и иметь линии связи с ведущими компьютерами 1014, например, через соединение 1040 Ethernet либо любую другую подходящую линию связи, включая Интернет. Аналогично, контроллеры 1012 имеют связь с полевыми устройствами 1025-1039 с использованием любых требуемых аппаратных и программных средств, связанных, например, со стандартными устройствами на 4-20 мА, и/или любого протокола связи, такого как протоколы Fieldbus или HART. Как известно, контроллеры 1012 реализуют или контролируют стандартные программы управления технологическим процессом, хранящиеся в этих контроллерах или связанные с ними иным образом, и осуществляют связь с полевыми устройствами 1025-1039 для управления технологическим процессом любым желаемым образом.

Полевые устройства 1025-1039 могут быть устройствами любого типа, такими как датчики, вентили, первичные измерительные преобразователи, позиционеры и т.д., в то время как платы ввода/вывода в наборах устройств 1020 и 1022 ввода/вывода могут быть устройствами ввода/вывода любого типа, соответствующего любому требуемому протоколу связи или протоколу контроллера, такому как HART, Fieldbus, Profibus и т.д. В варианте, показанном на фиг.22, полевые устройства 1025-1027 являются стандартными устройствами на 4-20 мА, которые имеют связь по аналоговым линиям с платой 1022А ввода/вывода, полевые устройства 1028-1031 показаны в виде устройств HART, подсоединенные к устройству 1020А ввода/вывода, совместимому с протоколом HART, а полевые устройства 1032-1039 являются полевыми устройствами Fieldbus, которые осуществляют связь по цифровой шине 1042 или 1044 с платами 1020В или 1022В ввода/вывода, используя связь по протоколу Fieldbus.

Каждый из контроллеров 1012 выполнен с возможностью реализации стратегии управления с использованием функциональных блоков, блоков преобразователей и ресурсных блоков. Как хорошо известно, каждый блок является частью (например, подпрограммой) общей программы управления и работает вместе с другими блоками (через линии связи) для реализации контуров управления технологическим процессом в системе 1000 управления технологическим процессом. Функциональные блоки и блоки преобразователей обычно выполняют функции ввода, такие как функции, связанные с датчиком или другим устройством для измерения параметров технологического процесса, функции управления, такие как функции, связанные со стандартной программой управления, которая реализует PID управление, управление на основе нечеткой логики, и т.д. или функции вывода, которые управляют работой какого-либо устройства, такого как вентиль, для выполнения некоторой физической функции в системе 1000 управления технологическим процессом. Разумеется, существуют блоки смешанных и других типов.

Функциональные блоки могут храниться в контроллере 1012 и выполняться им, что обычно бывает в том случае, когда функциональные блоки используются для стандартных устройств на 4-20 мА или интеллектуальных полевых устройств некоторых типов или связаны с такими устройствами, либо функциональные блоки могут храниться в полевых устройствах и реализовываться этими устройствами. Хотя описание системы управления 1000 предложено здесь с использованием стратегии управления на основе функциональных блоков, блоков преобразователей и ресурсных блоков, стратегия управления также может быть реализована с использованием других способов, таких как многоступенчатая логика, последовательные блок-схемы и т.д. и использованием любого необходимого фирменного или нефирменного языка программирования.

Система 1000 управления технологическим процессом может также включать в себя одну или несколько систем для решения коммерческих задач, которые могут быть реализованы в одной или обеих рабочих станциях 1014 или в одной или нескольких других компьютерных системах (не показаны), либо платформах других типов (например, Web-серверы, устройства беспроводной связи и т.д.), которые имеют связь с системой 1000 управления технологическим процессом. Эти системы для решения коммерческих задач могут включать в себя системы технического обслуживания активов предприятия, системы управления для нештатных ситуаций и т.д., которые функционируют вместе с системой 1000 управления технологическим процессом для эффективного управления ее работой. Важно понять, что различные устройства, системы и т.д., составляющие систему 1000 управления технологическим процессом, могут быть связаны между собой через сети связи одного или нескольких типов, в том числе Интернет. Целесообразно, чтобы компьютеризированная система 1055 технического обслуживания (CMMS) была реализована в одной из рабочих станций 1014. Однако система CMMS 1055 может быть реализована на любой другой рабочей станции, сервере или компьютерной системе, имеющей линии связи с системой 1000 управления технологическим процессом, если это потребуется.

В системе 1000 управления технологическим процессом, показанной на фиг.22, одно или несколько ведущих устройств 1014 функционирует как рабочая станция оператора, в которой хранятся программные средства обработки аварийных сигналов. Вообще-то говоря, программные средства 1050 обработки аварийных сигналов отображают информацию о системе 1000 управления технологическим процессом, относящуюся к пониманию или способности оператора или пользователя системы оценивать текущее рабочее состояние технологического процесса в связи с аварийными сигналами, присутствующими в системе. Например, программные средства 1050 обработки аварийных сигналов могут отображать баннер аварийной сигнализации с аварийной индикацией и представлять основное отображение для управления, иллюстрирующее сегмент системы 1000 управления технологическим процессом, в том числе устройства и другое оборудование, связанное с этим сегментом системы 1000 управления технологическим процессом, соответствующее одному или нескольким аварийным сигналам, отображенным в баннере аварийной сигнализации. Основное отображение для управления может обеспечить информацию о текущем состоянии системы 1000 управления технологическим процессом, таком как уровень жидкости в резервуаре, характеристику расхода вентиля и других трубопроводов, настройки оборудования, показания датчиков, состояние устройства и т.д. Пример такого отображения показан на фиг.24. Оператор может использовать программные средства 1050 обработки аварийных сигналов для просмотра различных частей системы 1000 управления технологическим процессом или оборудования в системе 1000 управления технологическим процессом. Конечно, программные средства 1050 обработки аварийных сигналов осуществляют связь с контроллерами 1012 и, если это необходимо, с полевыми устройствами 1025-1039, любым из наборов устройств 1020 и 1022 ввода/вывода или любыми другими устройствами, чтобы получить подходящие значения, настройки и результаты измерений, связанные с или выполненные в системе 1000 управления технологическим процессом, для создания экрана интерфейса на операторском дисплее рабочей станции 1014.

Программные средства 1050 обработки аварийных сигналов выполнены с возможностью приема аварийных сообщений, созданных программными средствами создания аварийных сигналов в некоторых или всех контроллерах 1012, устройствах 1020 и 1022 ввода/вывода и/или полевых устройствах 1025-1039. Программные средства 1050 обработки аварийных сигналов показаны в целом, но только в качестве примера, в виде программных элементов 1051, 1052 и 1053 на фиг.22. В сущности говоря, программные средства 1050 обработки аварийных сигналов принимают аварийные сообщения различных категорий, в том числе, например, технологические аварийные сигналы (которые, как правило, создаются программными модулями управления технологическим процессом, такими как модули, образованными из связанных между собой функциональных блоков, формирующих стандартные программы управления технологическим процессом, используемые в ходе технологического процесса), аппаратные аварийные сигналы, такие как аварийные сигналы, создаваемые контроллерами 1012, устройствами 1020 и 1022 ввода/вывода или другими рабочими станциями 1014, относящиеся к состоянию или режиму работы этих устройств, и аварийные сигналы устройств, которые создаются некоторыми или всеми полевыми устройствами 1025-1039 для индикации действительных или потенциальных проблем, связанных с этими устройствами. Аварийные сигналы этих или других категорий могут создаваться любым требуемым путем. Хорошо известно, например, что имеются функциональные блоки или программные модули, которые используют для реализации функций управления технологическим процессом, создания технологических аварийных сигналов, и эти технологические аварийные сигналы посылаются в виде аварийных сообщений на интерфейсы операторов для отображения. Также некоторые интеллектуальные устройства, контроллеры, устройства ввода/вывода, базы данных, серверы, рабочие станции и т.д. могут использовать любые необходимые фирменные или нефирменные программные средства для обнаружения проблем, ошибок, предупреждений, касающихся технического обслуживания и т.д., и могут посылать аварийные сигналы или предупреждения, указывающие на эти ситуации, на интерфейс оператора на рабочей станции 1014. В частности, во многих устройствах, таких как контроллеры, устройства ввода/вывода и интеллектуальные полевые устройства, предусмотрены программные средства и/или датчики, которые обнаруживают аппаратные проблемы, такие как засорение вентиля, поломки деталей, проблемы с техническим обслуживанием и т.д., и могут создавать сигналы или сообщения, указывающие на эти ситуации.

Если потребуется, программные средства 1050 обработки аварийных сигналов могут принимать и отфильтровывать аварийные сигналы на основе нескольких факторов. В частности, программные средства 1050 обработки аварийных сигналов могут отфильтровывать аварийные сигналы на основе рабочих станций или компьютерных систем, в которых эти программные средства 1050 выполняются, на основе идентичности лица, зарегистрировавшегося на рабочей станции, и на основе настроек, конфигурируемых оператором, таких как категория, тип, приоритет, статус, время создания и т.д. аварийного сигнала. Например, программные средства 1050 обработки аварийных сигналов могут отфильтровывать аварийные сигналы для избирательного отображения аварийных сигналов, поступающих от областей или сегментов установки, для приема которых сконфигурирована рабочая станция, выполняющая программные средства 1050 обработки аварийных сигналов. Другими словами, аварийные сигналы для некоторых областей или сегментов установки могут не отображаться на конкретных рабочих станциях. Вместо этого каждая рабочая станция может представлять ограниченное отображение аварийных сигналов для одной или нескольких конкретных областей установки. Аналогичным образом, аварийные сигналы могут отфильтровываться на основе идентичности оператора, так что отдельные операторы могут быть не допущены к просмотру аварийных сигналов некоторых категорий, типов, уровней приоритетов и т.д., либо могут быть не допущены к просмотру аварийных сигналов от сегмента или субсегмента (например, области) установки. Программные средства 1050 обработки аварийных сигналов могут также отфильтровывать аварийные сигналы для отображения на основе уровня защиты данных оператора. В общем случае эти настройки фильтрации рабочих станций и операторов называются здесь элементами управления «области видимости» рабочей станции и оператора.

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

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

В частности, устройства 1032-1039 Fieldbus могут предоставить аварийный параметр FAILED_ALM, который в общем случае указывает на проблему в устройстве, которое перестало правильно работать либо которое может вообще не работать, в результате чего предотвращается выполнение его стандартных измерительных и/или управляющих функций. Например, используя параметр FAILED_ALM, можно сообщить об отказе памяти в устройстве, отказе привода в устройстве либо любом другом отказе устройства, который может потребовать немедленного внимания (то есть, техническое обслуживание, ремонт и т.д.). Устройства 1032-1039 Fieldbus могут также предоставить аварийный параметр MAINT_ALM, который обычно указывает на обнаруженное в устройстве состояние, которое связано с необходимостью определенного вида технического обслуживания устройства, но которое не настолько серьезно, чтобы претендовать на сообщение о нем через параметр FAILED_ALM. Состояния устройства, сообщаемые с использованием параметра MAINT_ALM, предпочтительно, но не обязательно являются состояниями, которые возникают в устройстве из-за старения, износа, усталости и т.д. определенного типа, что может, в конце концов, привести к отказу устройства, но не обязательно сказывается на способности устройства выполнять функции измерения, управления или любые другие необходимые функции. Например, через параметр MAINT_ALM может поступать сообщение об аварии или предупреждение, при наступлении события, такого как заедание вентилей, засорение импульсных трубопроводов, и т.п. Вдобавок, устройства 1032-1039 Fieldbus могут предоставить аварийный параметр ADVISE_ALM, который в общем случае указывает на обнаруженное в устройстве состояние, которое претендует только на предупреждение или аварийный сигнал рекомендательного характера. В общем случае, аварийные сигналы или предупреждения, сообщаемые с использованием параметра ADVISE_ALM, не влияют каким-либо образом на работу устройства или технологический процесс, управляемый и/или контролируемый с использованием этого устройства. Например, с использованием параметра ADVISE_ALM могут передаваться сообщения о проблемах с заземлением, обнаруженных магметром (расходомер проводящих жидкостей), и о резком подъеме температуры или давления, обнаруженном датчиком.

Таким образом, в отличие от параметров BLOCK_ALM и BLOCK_ERR, используемых в традиционных устройствах Fieldbus, описанные здесь независимо сообщаемые параметры FAILED_ALM, MAINT_ALM и ADVISE_ALM позволяют устройству Fieldbus одновременно передавать множество аварийных сигналов или предупреждений, имеющих различные уровни серьезности. Другими словами, одно устройство Fieldbus, используя описанные здесь независимо сообщаемые аварийные сигналы, может сообщить о проблеме с заземлением, которая не требует немедленного внимания, используя при этом параметр ADVISE_ALM, и одновременно это устройство Fieldbus может сообщить о более серьезном состоянии, таком как, например, отказ датчика, который требует немедленного внимания, используя в этом случае параметр FAILED_ALM, независимо от того, был ли подтвержден или стерт системным оператором параметр ADVISE_ALM.

Предпочтительно, но не обязательно, чтобы каждый из описанных здесь параметров FAILED_ALM, MAINT_ALM и ADVISE_ALM формировались с использованием тридцатидвухразрядного слова на основе любого требуемого формата или типа данных, такого как, например, DS-72 или DS-71, известные как стандарты IEEE, которые здесь подробно не описываются. Каждый бит в каждом тридцатидвухразрядном слове может представлять уникальный статус в устройстве, сообщаемый с использованием аварийного параметра, соответствующего этому тридцатидвухразрядному слову. Таким образом, каждое устройство Fieldbus может сообщить тридцать два статуса устройства на каждом из трех различных уровней серьезности (то есть, FAILED_ALM, MAINT_ALM и ADVISE_ALM) всего для девяносто шести уникальных аварийных или предупредительных статусов. Если потребуется, один бит в каждом независимо сообщаемом аварийном сигнале FAILED_ALM, MAINT_ALM и ADVISE_ALM можно использовать для «иных» статусов, которые специально не определены, что позволит устройствам более гибко обеспечивать обнаружение множества различных статусов устройства, которые нельзя было предвидеть во время проектирования устройства и/или которые возможно потребуются для конкретного пользователя.

Хотя в общем случае менее серьезные аварийные сигналы или предупреждения могут передаваться с использованием параметров ADVISE_ALM или MAINT_ALM, не влияющих на способность устройства Fieldbus одновременно сообщать о более серьезном аварийном сигнале с использованием параметра FAILED_ALM, множество активных состояний статусов (то есть, множество обнаруженных статусов устройства) в конкретном параметре аварийной сигнализации может не привести к появлению множества аварийных событий, о которых сообщается рабочей станции 1014 оператора. Например, если одно из устройств Fieldbus обнаруживает состояние (статус) повышенного давления и состояние (статус) повышенной температуры, то биты, соответствующие этим статусам, будут посланы в параметре ADVISE_ALM для этого устройства. Однако первый обнаруженный статус вызовет формирование аварийного события и посылку сообщения рабочей станции 1014 оператора, в то время как любой последующий обнаруженный статус вызовет формирование другого аварийного статуса и посылку сообщения о нем на рабочую станцию только после того, как аварийное событие, связанное с предыдущим или первым обнаруженным статусом, будет стерто или подтверждено системным оператором или пользователем. В результате, если устройство Fieldbus сначала обнаруживает состояние повышенного давления, то обнаруженное вслед за этим состояние повышенной температуры не приведет к созданию аварийного события, пока системный пользователь или оператор не сотрет или не подтвердит аварийный сигнал или предупреждение о повышенном давлении.

Параметры FAILED_ALM, MAINT_ALM и ADVISE_ALM могут передаваться системному пользователю или оператору независимо через одну из рабочих станций 1014 с использованием вышеописанного формата Fieldbus для аварийных сообщений (то есть, формат сообщения, включающий поле идентификации блока, поле субкода и т.д.). Кроме того, каждый из тридцати двух возможных статусов, связанных с каждым из параметров FAILED_ALM, MAINT_ALM и ADVISE_ALM, предпочтительно, но не обязательно, можно представить, используя уникальный субкод при посылке этих параметров на рабочую станцию системы с использованием формата Fieldbus передачи аварийных сообщений. Каждое устройство Fieldbus включает в себя определения субкодов, связанных с каждым из возможных статусов для каждого из параметров FAILED_ALM, MAINT_ALM и ADVISE_ALM. Также каждое устройство Fieldbus может определить уникальное текстовое сообщение, которое описывает статус, связанный с каждым из субкодов. Хотя каждый субкод предпочтительно соответствует уникальному статусу устройства, а значит, уникальному текстовому сообщению, в некоторых случаях возможно потребуется использовать единое текстовое сообщение для более чем одного статуса устройства.

Описанные здесь независимо сообщаемые параметры аварийных сигналов устройства могут фильтроваться каждым устройством, чтобы разрешить или не разрешить передачу сообщения с аварийным сигналом или предупреждением в ответ на один или несколько возможных статусов устройства (то есть, девяносто шесть возможных статусов). Каждое из устройств 1032-1039 Fieldbus, способных передавать аварийные сигналы с использованием описанных здесь независимо сообщаемых параметров FAILED_ALM, MAINT_ALM и ADVISE_ALM, может дополнительно включать в себя параметр активного аварийного сигнала и параметр маски для каждого из независимо сообщаемых аварийных параметров. В частности, каждое из устройств Fieldbus 1032-1039 может включать в себя параметры FAILD_ACTIVE и FAILD_MASK, которые соответствуют сообщаемому параметру FAILED_ALM, параметры MAINT_ACTIVE и MAINT_MASK, которые соответствуют сообщаемому параметру MAINT_ALM, и параметры ADVISE_ACTIVE и ADVISE_MASK, которые соответствуют сообщаемому параметру ADVISE_ALM. Параметр маски и активный параметр предпочтительно, но не обязательно, реализуется с использованием тридцатидвухразрядного формата или типа данных без знака. Конечно, вместо этого можно использовать любой другой подходящий тип или формат данных.

Каждый из тридцати двух битов в параметре маски и активном параметре однозначно соответствует статусу в соответствующем сообщаемом аварийном параметре (то есть, FAILED_ALM, MAINT_ALM и ADVISE_ALM). В общем случае биты параметров маски каждого устройства могут устанавливаться или сбрасываться в исходное состояние во время конфигурации, например, для блокирования или разблокирования способности устройства передавать аварийные сигналы в ответ на обнаружение статусов, связанных с параметрами FAILED_ALM, MAINT_ALM и ADVISE_ALM или аварийными сигналами для этого устройства. Таким путем системный пользователь или оператор может избирательно блокировать или разблокировать те статусы, для которых каждое устройство будет создавать предупредительное или аварийное сообщение Fieldbus. Разумеется, системный пользователь или оператор может блокировать или разблокировать как больше, так и меньше статусов устройства, когда это потребуется.

При работе, когда устройство Fieldbus обнаруживает какой-то статус, в соответствующем активном параметре может быть установлен бит, соответствующий этому обнаруженному статусу. Например, если устройство Fieldbus обнаруживает отказавший датчик, бит, соответствующий этому статусу в параметре FAILED_ACTIVE для блока преобразователей в этом устройстве, может быть установлен или сброшен в ноль для индикации отказа датчика. Любые дополнительные статусы устройства, которые обнаруживаются (и которые не были подтверждены, отменены или стерты) или которые обнаружены в любое время, также могут привести к установке или сбросу битов в активном параметре для индикации существования этих дополнительных статусов. Однако, как более подробно описано ниже, статусы, которые обнаруживаются после сообщенного статуса (то есть, для которого системному оператору было послано аварийное сообщение Fieldbus), который еще не подтвержден, не могут быть переданы, пока этот сообщенный статус не будет подтвержден, отменен или иным способом стерт системным пользователем или оператором. Затем устройство Fieldbus может использовать параметр FAILED_MASK для блока преобразователей с целью фильтрации статусов устройства, связанных с этим блоком, для которых пользователь или системный оператор не хочет принимать аварийные сигналы или предупреждения. Системный пользователь или оператор во время конфигурации системы может определить, какие биты в параметре FAILED_MASK установлены или сброшены, чтобы обеспечить требуемую фильтрацию. Например, с параметром FAILED_MASK и параметром FAILED_ACTIVE может быть выполнена логическая операция «И» для формирования параметра FAILED_ALM, для получения битов, которые были установлены или сброшены, для индикации наличия статусов устройства, которые активны в данный момент (то есть, обнаружены) и которые не были маскированы параметром маски.

В общем случае каждый из независимо сообщаемых аварийных параметров FAILED_ALM, MAINT_ALM и ADVISE_ALM может известить устройство Fieldbus или заставить его послать аварийные и предупредительные сообщения Fieldbus системному пользователю или оператору (для любых обнаруженных статусов, которые являются активными и которые не маскированы), в том порядке, в котором эти статусы обнаружены. Другими словами, обнаруженные статусы в одном конкретном параметре из числа независимо сообщаемых аварийных параметров для конкретного устройства могут сообщаться системному пользователю или оператору в том порядке, в котором эти статусы были обнаружены (то есть, по принципу «прибыл последним - обслужен первым»). Конечно, сообщения об обнаруженных статусах могут посылаться системному пользователю или оператору с использованием какого-либо другого механизма присваивания приоритетов или упорядочивания, если это потребуется. Например, сообщения о немаскированных обнаруженных статусах могут посылаться в обратном хронологическом порядке (то есть, по принципу «прибыл последним - обслужен первым») на основе обнаруженного типа статуса и т.д. Вдобавок, устройство Fieldbus может предоставить пустое аварийное сообщение, когда все аварийные сообщения, связанные с конкретным аварийным параметром, стерты. Кроме того, если параметр маски для конкретного аварийного сигнала изменился, когда статус, связанный с этим аварийным параметром, является активным, устройство может стереть аварийный сигнал и пересмотреть его категорию на основе изменений, сделанных в параметре маски.

Каждое из устройств 1032-1039 Fieldbus может также включать в себя параметры приоритетов FAILED_PRI, MAINT_PRI и ADVISE_PRI для каждого из соответствующих параметров FAILED_ALM, MAINT_ALM и ADVISE_ALM. Эти параметры приоритетов могут быть реализованы с использованием восьмиразрядных значений без знака, которые обеспечивают 256 возможных уровней приоритета и которым может, например, быть присвоено значение по умолчанию или значение, равное двум. При установке уровня приоритета аварийного сигнала в нуль не разрешается сообщение об этом аварийном сигнале, а при установке уровня приоритета в любое значение между 1 и 255 пользователю или системному оператору предоставляется возможность выбора способа, посредством которого программные средства 1050 обработки аварийных сигналов будут управлять аварийными сигналами или предупреждениями на общесистемной основе. В частности, для определения того, какие аварийные сигналы или предупреждения от устройств имеют преимущества перед аварийными сигналами или предупреждениями от других устройств, можно использовать множество возможных уровней приоритета. Таким путем системный пользователь или оператор может заранее определить, каким образом система будет осуществлять управление и обработку потенциально огромного количества активных аварийных сигналов.

Каждое из устройств 1032-1039 Fieldbus может также включать в себя параметр RECOMMENDED_ACTION, который может быть отображен в текстовую информацию в информации для описания устройства, которая может храниться на рабочей станции 1014. Текстовая информация, на которую ссылается параметр RECOMMENDED_ACTION, может отображаться системному оператору или пользователю, чтобы оказать помощь при коррекции, ремонте и т.д. устройства, которое сформировало аварийный сигнал. В случае, когда сообщенный аварийный сигнал имеет множество активных статусов, рекомендуемое действие, отображаемое системному пользователю или оператору, может представлять собой самый критический или самый высокий статус приоритета.

Как было описано выше, предупреждения и аварийные сигналы различных типов, созданные устройствами 1032-1039 Fieldbus, могут отображаться на уровне устройства во множество независимых сообщаемых аварийных параметров (например, FAILED_ALM, MAINT_ALM и ADVISE_ALM). Таким путем предупреждения и аварийные сигналы от множества устройств Fieldbus могут контролироваться, обрабатываться и отображаться системному оператору или пользователю логически согласованным образом через рабочую станцию 1014. Вдобавок, в данном устройстве Fieldbus описанные здесь независимо сообщаемые аварийные параметры предотвращают маскирование передачи или отображения системному оператору или пользователю предупреждений или аварийных сигналов более серьезных типов со стороны предупреждений менее серьезных типов.

Каждое из устройств 1028-1031 HART обеспечивает восемь стандартных статусов состояний и, если потребуется, один или несколько специальных статусов состояний устройства. Однако, эти стандартные и специальные статусы состояний устройства, связанные с устройствами HART, обычно не согласованы со статусами состояний, о которых сообщают устройства Fieldbus. В частности, устройства 1028-1031 HART не сообщают о статусах состояний таким образом, который соответствует описанным здесь независимо сообщаемым аварийным параметрам FAILED_ALM, MAINT_ALM и ADVISE_ALM.

Для облегчения интегрированного контроля, обработки и отображения предупреждений или аварийных сигналов, связанных со статусами состояний, о которых сообщают устройства 1028-1031 HART, и предупреждений или аварийных сигналов, о которых сообщают устройства 1032-1039 Fieldbus через описанные здесь независимо сообщаемые параметры аварийной сигнализации, программные средства 1050 обработки аварийных сигналов отображают или разбивают гибкую информацию о состоянии HART на категории предупреждений или аварийных сигналов, которые соответствуют независимо сообщаемым аварийным параметрам FAILED_ALM, MAINT_ALM и ADVISE_ALM. Только в качестве примера, восемь стандартных статусов состояний устройств HART могут быть отображены так, как показано в таблице. Как показано в таблице, программные средства 1050 обработки аварийных сигналов могут отображать или разбивать восемь стандартных статусов состояний устройств HART на категории FAILED (отказ), MAINTENANCE (техническое обслуживание) и ADVISORY (рекомендация), что позволяет передавать или отображать эти стандартные статусы состояний устройств HART системному оператору или пользователю вместе с информацией о предупреждениях или аварийных сигналах устройств Fieldbus более согласованным и логически упорядоченным образом, чем это было возможно в известных системах.

Статус состояния HART Отображаемая категория сообщения Неправильное функционирование устройства FAILED Имеется еще состояние ADVISORY Изменение конфигурации ADVISORY PV насыщен MAINTENANCE PV зафиксирован MAINTENANCE PV вне установленного диапазона MAINTENANCE Не PV вне установленного диапазона MAINTENANCE Холодный пуск ADVISORY

Как хорошо известно, в отличие от устройств Fieldbus, для получения текущих статусов состояния устройства необходимо организовать опрос устройств HART. Соответственно, программные средства 1050 обработки аварийных сигналов, контроллеры 1012 и/или устройства 1020А ввода/вывода могут быть сконфигурированы для периодического опроса устройств 1028-1031 HART с целью получения информации об их состоянии. Поскольку каждое ответное сообщение, посылаемое устройством HART, включает в себя текущие состояния восьми стандартных статусов состояний, программные средства 1050 обработки аварийных сигналов могут эффективно получать эту информацию о состоянии, извлекая информацию о состоянии из ответов на команды, которые обычно посылаются контроллерами 1012 через устройство 1020А ввода/вывода в устройства 1028-1031 HART. Другими словами, программным средствам 1050 обработки аварийных сигналов практически не придется передавать дополнительные служебные сообщения, получая информацию о состоянии из ответов на команды, которые в ином случае периодически посылались бы в устройства HART 1028-1031 контроллерами 1012 для выполнения требуемых действий по управлению или контролю технологического процесса. Например, в случае, когда контроллеры 1012 являются контроллерами типа DeltaV, в устройства 1028-1031 периодически посылаются команды #0 и #3 HART. Таким образом, программные средства 1050 обработки аварийных сообщений могут выделять информацию о стандартных статусах состояний HART, связанную с устройствами 1028-1031, из сообщений, посланных в ответ на эти команды. Конечно, если потребуется, контроллеры 1012 и программные средства 1050 обработки аварийных сообщений могут использовать любую другую команду, чтобы заставить устройства 1028-1031 HART посылать ответные сообщения, содержащие информацию о стандартных состояниях HART.

Как хорошо известно, статусы нестандартных состояний HART (то есть, специфическое состояние устройства) могут быть получены путем посылки команды #48 HART на устройства 1028-1031 HART. Также хорошо известно, что протокол связи HART определяет, что информация о специфических состояниях устройства может быть доступна тогда, когда статус «Неправильное функционирование устройства» или статус «Имеются еще состояния» являются истинными (то есть, биты установлены в логическую 1). Таким образом, когда программные средства 1050 обработки аварийных сигналов обнаруживают истинное значение статуса либо для статуса «Неправильное функционирование устройства», либо для статуса «Имеются еще состояния» для одного из устройств 1028-1031 HART, программные средства 1050 обработки аварийных сигналов посылают на это устройство команду #48 HART. В ответ на команду #48 опрашиваемое устройство предоставляет более подробную информацию, относящуюся к характеру специфического статуса или состояния устройства. Затем программные средства 1050 обработки аварийных сигналов распределяют статусы специфических состояний устройства, которые предоставлены в ответ на команду #48, в следующем порядке: (1) если бит «Неправильное функционирование устройства» был установлен в единицу, то программные средства 1050 обработки аварийных сигналов отображают статус специфического состояния устройства в категорию предупреждений или аварийных сигналов «FAILED», и (2) если установлен в единицу бит «Имеются еще состояния?», то программные средства 1050 обработки аварийных сигналов отображают этот статус специфического состояния устройства в категорию предупреждений или аварийных сигналов «ADVISORY».

Обратимся теперь к фиг.23, где конфигурация из одной рабочей станции 1014, которая реализует систему отображения и интерфейса аварийной сигнализации, показана более подробно. Как показано на фиг.23, рабочая станция 1014 хранит и выполняет программные средства связи, такие как уровень или стек 1062 связи, который осуществляет связь с контроллерами 1012 через соединение 1040 Ethernet (или через какую-либо другую сеть связи, такую как, например, Интернет) для приема сигналов, посылаемых контроллерами 1012, устройствами ввода/вывода в банках 1020 и 1022, полевыми устройствами 1025-1039 и/или другими рабочими станциями. Уровень 1062 связи также правильно форматирует сообщения, посылаемые в контроллеры, устройства ввода/вывода, полевые устройства 1025-1039 и другие рабочие станции, такие как сообщения или сигналы подтверждения аварийной сигнализации и т.д. Программные средства связи, используемые для реализации уровня 1062 связи, могут являться известными или необходимыми программными средствами связи, которые используются в настоящее время, например, при связи через Ethernet. Разумеется, уровень 1062 связи связан с другими программными средствами, которые выполняют другие функции, такие как приложения конфигурации, диагностические или другие технологические приложения, приложения для управления базами данных и т.д., выполняемые на рабочей станции 1014.

Система отображения и интерфейса аварийной сигнализации включает в себя блок 1064 обработки аварийных сигналов, который принимает аварийные сигналы и другую информацию о событиях от уровня 1062 связи в виде сообщений, декодирует эти сообщения, содержащие информацию об аварийных сигналах или других событиях, и может запомнить эту информацию об аварийных сигналах и других событиях в базе данных 1066. Интерфейс блока 1064 обработки аварийных сигналов может представлять собой приемник аварийных сигналов. Программные средства 1050 обработки аварийных сигналов также включают в себя фильтр 1068 аварийных сигналов, который используется блоком 1064 обработки аварийных сигналов, чтобы определить, какие аварийные сигналы должны отображаться на интерфейсе 1069 пользователя (таком как электронно-лучевая трубка (CRT), жидкокристаллический дисплей (LCD), светодиоды (LED), плазменный дисплей, принтер и т.д.), связанном с рабочей станцией 1014. Фильтр 1068 может иметь свои настройки, хранящиеся в базе данных 1066, и эти настройки фильтра могут быть предварительно сконфигурированы и/или изменены пользователем на основе его предпочтений. Следует понимать, что фильтр 1068 и его настройки отличаются от параметров маски на уровне устройства FAILED_MASK, MAINT_MASK и ADVISE_MASK, которые можно использовать с устройствами Fieldbus, как здесь описано. То есть, системный пользователь или оператор может отфильтровывать специфические аварийные сигналы, создаваемые специфическими статусами в определенных устройствах, используя параметры маскирования устройства. В альтернативном варианте или в качестве дополнения, как было здесь описано, системный пользователь или оператор может отфильтровывать типы или категории аварийных сигналов, связанных с конкретными установками, областями, блоками, контурами и т.д. в системе управления технологическим процессом, используя фильтр 1068. Например, в случае, когда программные средства 1050 обработки аварийных сигналов обрабатывают информацию об аварийных сигналах или предупреждениях, посланную одним или несколькими устройствами 1028-1031 HART, фильтр 1068 аварийных сигналов может быть использован для избирательного отображения аварийной или предупредительной информации любым желаемым образом. Конечно, устройства 1028-1031 HART не имеют внешних механизмов фильтрации аварийных сигналов или предупреждений, таких как, например, параметры маски на уровне устройства, описанные в связи с устройствами 1032-1039 Fieldbus.

В общем случае настройки фильтра 1068 аварийных сигналов могут управлять категорией и приоритетом аварийных сигналов и, если потребуется, могут установить порядок их отображения, используя несколько различных критериев. Элементы управления областью видимости оператора и рабочей станции определяют то, что может увидеть конкретный оператор (например, какие аварийные сигналы могут быть отображены на конкретной рабочей станции) на основе идентичности оператора и рабочей станции, на которой зарегистрировался оператор. В этом случае каждой рабочей станции может быть выдана лицензия на операции, при этом без лицензии на операции отображения аварийной информации и всего списка/итогового заключения по аварийным сигналам могут оказаться пустыми. Другими словами, ни один из активных или заблокированных аварийных сигналов любой категории (то есть, технологический процесс, аппаратное средство или устройство) не будет показан блоком 1064 обработки аварийных сигналов. Кроме того, в отображениях аварийных сигналов на этой рабочей станции потенциально могут появиться любые аварийные сигналы из области установки в текущей области видимости оператора (оператору обычно дается по меньшей мере один защитный ключ в области установки). Также в отображении аварийных сигналов потенциально могут появиться только аварийные сигналы из области и блока установки, который не был отключен с использованием отображения(ий), фильтрующего область или блок установки (как обсуждается ниже). Таким путем фильтр 1068 аварийных сигналов предотвращает отображение аварийных сигналов вне области видимости рабочей станции и оператора и аварийных сигналов из блоков установки, которые были отключены оператором.

После проверки аварийных сигналов для согласования с элементами управления области видимости рабочей станцией и оператора, фильтр 1068 выполняет фильтрацию и определяет порядок отображения аварийных сигналов на основе настроек оператора, которые могут включать в себя, например, категорию аварийного сигнала, приоритет аварийного сигнала, тип аварийного сигнала, подтвержденное состояние аварийного сигнала, заблокированное состояние аварийного сигнала, время аварийного сигнала, активное состояние аварийного сигнала и т.д. Принятые аварийные сигналы, посланные в программные средства 1050 обработки аварийных сигналов с использованием аварийных сообщений (например, аварийных сообщений Fieldbus), могут включать в себя параметр для каждого из этих значений, а фильтр 1068 может отфильтровать аварийные сигналы для отображения путем сравнения соответствующих параметров аварийных сигналов с настройками фильтра. Например, оператор может указать, какие категории аварийных сигналов и уровни приоритета аварийного сигнала должны быть отображены на экране. Если потребуется, оператор может отрегулировать заранее определенный уровень приоритета для аварийного сигнала путем смещения уровня приоритета относительно предварительно сконфигурированного уровня приоритета для данного аварийного сигнала, установленного изготовителем. В системе DeltaV^TM для каждого аварийного сигнала уровень приоритета обычно выбирается между тремя и пятнадцатью, и оператор может сместить этот уровень приоритета на любое количество уровней, чтобы повысить низкий приоритет или понизить высокий приоритет при их оценке фильтром 1068. Хотя оператор может установить порядок отображения аварийных сигналов, которые проходят через фильтр 1068, этот порядок может также быть определен заранее сконфигурированными настройками, чтобы обеспечить согласованное отображение аварийных сигналов различных типов.

В любом случае оператор может, исходя из конкретных требований, подобрать способ, которым отображаются аварийные сигналы на основе категорий или типов аварийных сигналов, которые больше всего интересуют пользователя и которые все относятся к одной категории или типу аварийных сигналов, таких как технологические аварийные сигналы, аварийные сигналы от устройств, аппаратные аварийные сигналы или любые комбинации из двух или более категорий аварийных сигналов. Кроме того, пользователь может сконфигурировать отображение аварийных сигналов, так чтобы могли отображаться или не отображаться аварийные сигналы или предупреждения различного уровня серьезности. Например, пользователь может пожелать, чтобы отображались только аварийные сигналы или предупреждения, содержащиеся в параметрах FAILED_ALM и MAINT_ALM, и может не захотеть просматривать аварийные сигналы и сообщения, содержащиеся в параметрах ADVISE_ALM. В более общем случае системный оператор или пользователь может сконфигурировать отображение аварийных сигналов для просмотра предупреждений или аварийных сигналов, связанных с отказом устройства, техническим обслуживанием, в котором нуждается устройство, и/или рекомендованным действием, касающимся устройства. Пользователь может также управлять представлением аварийных сигналов и информацией, предоставляемой этими аварийными сигналами. Таким путем программные средства 1050 обработки аварийных сигналов позволяют одному лицу выполнять функции оператора, техника или обслуживающего персонала и инженера путем оценки и адресации на одном и том же экране аварийных сигналов, которые обычно адресовались бы другим лицам в других местах установки. В альтернативном варианте в одной и той же системе в разные моменты времени обслуживающий персонал может использовать одну и ту же систему для просмотра только аварийных сигналов, связанных с техническим обслуживанием, в то время как инженер может просматривать аварийные сигналы других типов, влияющих на работу устройств. Таким путем программные средства 1050 обработки аварийных сигналов могут использоваться лицами разных категорий одновременно на разных рабочих станциях для оценки различных аспектов аварийных сигналов, связанных с системой 1000 управления технологическим процессом. Кроме того, при использовании программных средств 1050 обработки аварийных сигналов отдельному человеку относительно легко передать аварийные функции, которые они просматривают или подтверждают, другому лицу, которое может иметь те же самые программные средства. В альтернативном варианте или как дополнение, отдельное лицо может установить фильтр для приема аварийных сигналов, которые обычно просматриваются другим лицом. Таким путем отдельное лицо может уйти на обед и передать функцию просмотра аварийных сигналов другим лицам на других рабочих станциях, установив в исходное состояние несколько настроек фильтра. Вернувшись с обеда, это лицо может вновь взять на себя эти функции. Также, когда объем аварийной информации становится слишком большим для одного человека, чтобы с ним справиться, этот человек может передать или снять с себя функцию контроля за некоторыми категориями аварийных сигналов, таких как технологические аварийные сигналы, аварийные сигналы устройств или аппаратные аварийные сигналы, так что эти аварийные сигналы могут обрабатываться другими лицами на других терминалах.

После того, как блок 1064 обработки аварийных сигналов использует фильтр 1068 для решения вопроса о том, какие аварийные сигналы (то есть, немаскированные статусы) следует отобрать пользователю через дисплей 1069, и каков будет порядок отображения этих аварийных сигналов, блок 1064 обработки аварийных сигналов предоставляет эту информацию интерфейсу 1070 пользователя, который использует какую-либо стандартную или требуемую операционную систему для отображения аварийной информации на дисплее 1069 аварийных сигналов любым желаемым образом. Разумеется, интерфейс 1070 дисплея пользователя получает и другую необходимую информацию, такую как информация о компоновке или конфигурации системы 1000 управления технологическим процессом, а также значения параметров или сигналов в этой системе и т.д. из базы данных 1066 или из других сигналов связи, принимаемых от системы 1000 управления технологическим процессом через уровень 1062 связи. Также интерфейс 1070 дисплея пользователя принимает команды от пользователя, запрашивающего, например, дополнительную информацию, касающуюся конкретных аварийных сигналов, изменений в аварийных сигналах или настройках фильтров, новых отображений аварийных сигналов и т.д., и предоставляет эту информацию в блок 1064 обработки аварийных сигналов, который затем предпринимает запрошенное действие, осуществляет поиск аварийной информации в базе данных 1066 и т.д., чтобы предоставить пользователю новое отображение аварийных сигналов через дисплей 1069.

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

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

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

В одном варианте пользователю на дисплее может быть предоставлена интегрированная аварийная информация в виде баннера аварийной сигнализации, например, на краю экрана дисплея. Обратимся теперь к фиг.24, где баннер 1073 аварийной сигнализации расположен в нижней части экрана 71. Баннер 1073 аварийной сигнализации включает в себя первую строку, где отображаются различные аварийные сигналы, созданные системой 1000 управления технологическим процессом, которые прошли через фильтр 1068 на дисплей 1069. По меньшей мере один из аварийных сигналов, показанных в баннере 1073 аварийной сигнализации, может быть связан с частью системы 1000 управления технологическим процессом, изображенной в основной части экрана 71. Конкретные аварийные сигналы, отображенные в баннере 1073 аварийной сигнализации, и порядок этих аварийных сигналов определяются в соответствии с конфигурацией маски и параметрами приоритетов и настройками фильтра 1068. В общем случае, аварийные сигналы с наивысшим приоритетом, которые не были подтверждены, заблокированы или маскированы, отображаются первыми, после чего отображаются аварийные сигналы со следующим наивысшим приоритетом и т.д. В показанном в качестве примера экране на фиг.24 аварийный сигнал 1074 с наивысшим приоритетом является технологическим аварийным сигналом, связанным, как показано, со стандартной программой управления PID 101. Аварийный сигнал 1074 отображается красным цветом, чтобы подчеркнуть его критический приоритет. На второй строке баннера 1073 аварийной сигнализации в поле 1076 аварийной информации отображается аварийная информация, связанная с выбранным в данный момент аварийным сигналом в баннере 1073 аварийной сигнализации. В примере на фиг.24 при выборе аварийного сигнала 1074 поле 1076 аварийной информации показывает, что аварийный сигнал 1074 был создан в пятницу в 12 часов 52 минуты 19 секунд, что он связан с «Уровнем управления резервуаром 16», что он имеет обозначение или имя PID101/HI_Hf_ALM, что он имеет самый высокий приоритет и является критическим аварийным сигналом. Если аварийный сигнал 1074 мигает, это значит, что он не подтвержден, в то время как постоянный (не мигающий) аварийный сигнал в баннере 1073 аварийной сигнализации указывает на то, что аварийный сигнал 1074 был подтвержден оператором или пользователем. Разумеется, в поле 1076 аварийной информации может отображаться аварийная информация других типов.

Также в баннере 1073 другая аварийная индикация, такая как аварийная индикация 1078, может быть желтой, красной либо любого другого цвета, чтобы показать другие уровни серьезности или приоритета, связанного с аварийным сигналом. При выборе другого аварийного сигнала, такого как аварийный сигнал 1078, 1080, 1081 или 1082, аварийная информация, относящаяся к этому аварийному сигналу, может отображаться в поле 1076 аварийной информации. При оценке аварийного сигнала в баннере 1073 аварийной сигнализации пользователь может подтвердить эти аварийные сигналы и предупредить обслуживающий или инженерный персонал о необходимости предпринять соответствующие действия для корректировки статуса, который привело к аварийному сигналу, или в альтернативном варианте, может предпринять другие шаги, такие как установку некоторых уставок в исходное состояние для смягчения аварийного статуса.

Как было показано выше, путем выбора одного из аварийных сигналов в баннере 1073 аварийной сигнализации, такого как аварийный сигнал 1074, на экране 1071 появляется основное отображение для этого аварийного сигнала. В частности, как показано на фиг.24, основная часть экрана 1071 включает в себя главное контрольное отображение или изображение оборудования, связанного с конкретным аварийным сигналом (выбранным аварийным сигналом) в системе 1000 управления технологическим процессом. В примере по фиг.24, это оборудование включает в себя три резервуара со смонтированными на них различными датчиками, каждый из которых имеет соединения с различными вентилями и трубопроводами. Это изображение представляет оборудование в части системы 1000 управления технологическим процессом и предоставляет информацию о работе некоторого оборудования, такую как значения или параметры, связанные с резервуарами, датчиками и т.д. Конечно, часть этой информации может быть предоставлена из информации о конфигурации в базе данных 1066 и сигналов от датчиков в системе управления технологическим процессом через контроллеры 1012 и соединение 1040 Ethernet. В этом случае указанная информация посылается через уровень 1062 связи и поступает на интерфейс 1070 для отображения пользователю через известные или требуемые программные средства.

На фиг.25-27 показаны примеры графических отображений, которые могут быть предоставлены системному пользователю или оператору через программные средства 1050 отображения и интерфейса аварийных сигналов. На фиг.25 показан пример всплывающего окна 1100, которое может отображаться программными средствами 1050 обработки аварийных сигналов в соответствии с выбором системным пользователем или оператором одного из аварийных сигналов из баннера 1073 аварийной сигнализации, показанного на фиг.24. В частности, если пользователь выбирает (например, дважды щелкнув мышью) аварийный сигнал 80, связанный с расходным вентилем FV 101 потока, то может появиться отображение всплывающего окна 1100. Как показано на фиг.25, всплывающее окно 1100 включает в себя полосы 1102 аварийных сигналов или предупреждений, одна или несколько из которых могут быть выделены, чтобы показать активный статус в одном или нескольких независимо сообщаемых аварийных параметрах (то есть, FAILED_ALM, MAINT_ALM и ADVISE_ALM) для одного или нескольких устройств 1032-1039 Fieldbus, который в этом примере представляет собой расходный вентиль BV 101. Вдобавок, одна или несколько полос с предупреждениями могут показывать активный статус, связанный с предупреждением или аварийным сигналом об отказе, сигналом о техническом обслуживании или рекомендательным сигналом от одного или нескольких устройств 1028-1031 HART. Разумеется, полоса с аварийным сигналом «Отказ» может быть выделена в результате активного статуса в параметре FAILED_ALM, полоса «В ближайшее время понадобится техническое обслуживание» может быть выделена в результате активного статуса в параметре MAINT_ALM, а полоса «Рекомендация» может быть выделена в результате активного статуса в параметре ADVISE_ALM. Вдобавок, как показано на фиг.25, полосы 1102 аварийных сигналов или предупреждений могут включать в себя полосу «Отказ связи», указывающую на отказ связи, касающийся любого из полевых устройств 1025-1039.

Системный пользователь или оператор может выбрать кнопку 1104 подтверждения для подтверждения выделенного аварийного сигнала или предупреждения в окне 1100 или, в альтернативном варианте, может выбрать один из блоков 1106 отмены для отмены одного или нескольких активных аварийных сигналов или предупреждений. Кроме того, если это необходимо, пользователь или системный оператор может выбрать кнопку 1108 «Подробности» для вызова других всплывающих окон, как более подробно обсуждается ниже, что обеспечит дополнительную информацию, касающуюся тех аварийных сигналов, которые в данный момент являются активными в окне 1100.

На фиг.25 также изображено еще одно всплывающее окно 1110, содержащее более подробную информацию о состоянии, связанную с расходным вентилем FV 101. Окно 1110 состояния может быть вызвано из окна 1100 путем выбора пиктограммы 1112, кнопки 1108 подробностей, выделения полосы из числа полос 1106 для аварийных сигналов или предупреждений или любым другим желаемым образом. В любом случае окно 1110 состояний может включать в себя полосы 1114, 1116 и 1118, каждая из которых соответствует одному из независимо сообщаемых аварийных сигналов или предупреждений. В данном примере выделена полоса «Отказ», поскольку в данный момент расходный вентиль FV 101 имеет активный статус в параметре FAILED_ALM вентиля FV 101. Окно 1110 состояния также включает в себя список возможных статусов 1120, связанных с передачей сообщения об отказе в расходном вентиле FV 101. Важно понять, что, хотя в этом примере показано только пять статусов, при необходимости может быть обеспечено больше или меньше, чем пять статусов. Каждый из возможных статусов 1120, показанных в окне 1110, уникально соответствуют немаскированным активным статусам, которые могут передаваться в параметре отказа, то есть, FAILED_ALM для этого устройства. Кроме того, окно 1110 предоставляет полосу 1122 с рекомендуемыми действиями, где отображается текстовая информация, связанная с параметром RECOMMENDED_ACTION устройства, причем эта информация может храниться в описании устройства. Вдобавок, окно 1110 включает в себя кнопку 1124 помощи, которая при ее выборе системным пользователем или оператором может вызвать другое всплывающее окно (такое как окно 1144 помощи, показанное на фиг.27 и обсуждаемое ниже), содержащее текстовую информацию, облегчающую пользователю или системному оператору поиск неисправностей, их устранение и т.д. для устройства, которое создало аварийный сигнал или предупреждение, отображаемое в данный момент.

На фиг.26 показан еще один пример всплывающего окна 1130, которое обеспечивает информацию о состоянии, связанную с первичным измерительным преобразователем PT 101 давления. Общий формат окна 1130, показанного на фиг.26, идентичен окну, показанному на фиг.25, за исключением того, что окно 1130 включает в себя возможные статусы 1132, являющиеся статусами, которые могут заставить первичной преобразователь РТ 101 давления сформировать предупреждение или аварийный сигнал о техническом обслуживании. Следует отметить, что в этом примере кнопка 1116 технического обслуживания выделена или является активной, что указывает на активный текущий немаскированный статус, связанный с параметром MAINT_ALM или параметром, отражающим необходимость технического обслуживания для первичного преобразователя PT 101 давления.

На фиг.27 показан еще один пример всплывающего окна 1140, которое предоставляет информацию о состоянии, связанную с первичным преобразователем FT 101 расхода, и который включает в себя группу возможных статусов 1142, которые аналогичны или идентичны статусам, которые могут быть сообщены с помощью параметров MAINT_ALM или параметров, указывающих на необходимость технического обслуживания для первичного преобразователя FT 101 расхода. На фиг.27 также показано всплывающее окно 1144 помощи, которое может быть активизировано путем выбора кнопки 1124 помощи. Как показано на фиг.27, окно 1144 помощи включает в себя подробную текстовую информацию, которая может быть предоставлена из описания первичного измерительного преобразователя FT 101 расхода и послана на рабочую станцию 1014 для отображения через программные средства 1050 отображения аварийных сигналов.

Хотя программные средства 1050 отображения и интерфейса аварийных сигналов были описаны применительно к их использованию с устройствами Fieldbus, HART и стандартными устройствами на 4-20 мА, они могут быть реализованы с использованием любого другого внешнего протокола связи для управления технологическим процессом и могут быть использованы с программными средствами контроллеров любых других типов. Хотя описанные здесь программные средства 1050 отображения и интерфейса аварийных сигналов целесообразно реализовать в виде программ, их можно реализовать аппаратными средствами, аппаратно-программными средствами и т.д., а также можно реализовать с помощью любого другого процессора, связанного с системой 1000 управления технологическим процессом. Таким образом, описанная здесь стандартная программа 1050 может быть реализована в стандартном многоцелевом процессоре или с использованием специально разработанных аппаратных или аппаратно-программных средств, если это необходимо. При реализации программным путем эта стандартная программа может храниться в любом запоминающем устройстве, считываемом компьютером, таком как магнитный диск, лазерный диск или другая запоминающая среда, в ОЗУ или ПЗУ компьютера или процессора и т.д. Аналогичным образом эти программные средства могут быть предоставлены пользователю или системе управления технологическим процессом с использованием любого известного или необходимого способа доставки, в том числе, например, на диске, считываемом компьютером, или посредством другого транспортируемого механизма или по каналу связи, такому как телефонная линия, Интернет и т.д. (которые рассматриваются как идентичные или взаимозаменяемые при предоставлении указанных программных средств через транспортируемую запоминающую среду).

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

Вдобавок к возможности интегрированного отображения аварийной или предупредительной информации от устройств, вышеописанная система и способ организации и установления приоритетов аварийных сигналов позволяет также обеспечить более эффективную интеграцию предупреждений или аварийных сигналов устройств с системами для коммерческих задач, которые обычно используются в установке для управления технологическим процессом или в торгово-промышленном предприятии. На фиг.28 показан пример функциональной блок-схемы системы 1200, в которой используется система 1202 управления событиями для интеграции предупреждений или аварийных сигналов устройств с одной или несколькими системами 1204 для решения коммерческих задач. Система 1206 управления активами может обеспечить или передавать предупреждения или аварийные сигналы от устройств, технологического процесса или любую другую необходимую предупредительную или аварийную информацию, относящуюся к работе системы управления технологическим процессом или установки, в систему 1202 управления событиями. Вообще-то говоря, система 1206 управления активами координирует совместную работу и обмен информацией между различными диагностическими инструментами, инструментами оптимизации, инструментами для управления технологическим процессом и любыми другими программными и/или аппаратными инструментами, которые можно использовать для обработки информации, относящейся к работе установки управления технологическим процессом. Система 1206 управления активами может быть реализована на одной или обеих рабочих станциях 1014 и может включать в себя программные средства 1050 обработки аварийных сигналов, обсуждавшиеся в связи с фиг.23. В любом случае система 1206 управления активами может принимать предупредительную или аварийную информацию от множества устройств управления технологическим процессом, контуров управления и т.д. и устанавливать приоритеты, организовывать или распределять предупредительную или аварийную информацию по категориям FAILED, MAINTENANCE и ADVISORY, используя способы, аналогичные или идентичные вышеописанным.

Система 1206 управления активами может передавать распределенную по категориям предупредительную или аварийную информацию в систему 1202 управления событиями. Вдобавок, система 1206 управления активами может посылать описательную информацию (например, текстовую информацию) в систему 1202 управления событиями для каждого из предупреждений или аварийных сигналов, которые передаются в систему 1202 управления событиями. Эта описательная информация может приниматься непосредственно от полевого устройства и храниться в базе данных 1208 или, в альтернативном варианте, может создаваться пользователем или оператором для каждого из контролируемых устройств и запоминаться в базе данных 1208 для последующего извлечения и передачи в систему 1202 управления событиями.

Система 1202 управления событиями обычно функционирует как интерфейс экспертной системы между системой 1206 управления активами и системами 1204 для решения коммерческих задач. В частности, система 1202 управления событиями может включать в себя одну или несколько стандартных программ 1210 конфигурации, которые при их выполнении можно использовать для конфигурации приоритетов и правил для предупреждений или аварийных сигналов, которые используются системой 1202 управления событиями для управления таким образом, при котором аварийная или предупредительная информация посылается или иным образом влияет на работу систем 1204 для коммерческих задач. Во время конфигурации пользователю или оператору может быть предоставлен графический интерфейс, который облегчает выбор контролируемых устройств (то есть, из которого можно будет получить и обработать предупредительную или аварийную информацию для устройств) системой 1202 управления событиями. Стандартные программы 1210 конфигурации могут, например, поддерживать список или таблицу всех тегов устройств, которые уникально идентифицируют каждое устройство в системе управления технологическим процессом и могут обновлять этот список или таблицу на основе того, какие конкретные устройства выбрал или не выбрал пользователь. Для предоставления пользователю или оператору наглядного графического интерфейса для выбора и отбрасывания контролируемых или отслеживаемых устройств можно использовать хорошо известные графические средства на основе окон, операции «указать и щелкнуть мышью» и т.д.

Стандартные программы 1210 конфигурации могут также предоставить пользователю или оператору возможность выбора или определения конкретных параметров (то есть, конкретных предупреждений или аварийных сигналов для устройств), контролируемых для каждого выбранного устройства. Параметры, предупреждения или аварийные сигналы, которые могут контролироваться, могут быть предоставлены самими устройствами с использованием, например, описаний устройств. Конечно, параметры, доступные контролю для каждого выбранного устройства, вместо этого могут быть получены из базы данных, такой как, например, база данных 1208 в системе 1206 управления активами. В любом случае каждому выбранному параметру также присваивается приоритет, который может представлять собой, например, численное значение, лежащее в диапазоне от 1 до 10, где единица может означать самый низкий приоритет, а десятка - самое высокое значение приоритета. Разумеется, для представления различных уровней приоритета можно использовать любой другой числовой диапазон или любые другие символы, если это потребуется. Например, параметру может быть присвоен приоритет, численное значение которого лежит в диапазоне от 0 до 100, где 0 - это самый высокий приоритете, а 100 - самый низкий приоритет.

Приоритет, присвоенный каждому параметру, выбранному для контроля, предпочтительно, но не обязательно отражает в полной мере серьезность предупреждения или аварийного сигнала, связанного с этим параметром. Таким образом, на присвоение значений приоритета влияет тип предупреждения, созданного устройством (то есть, какой параметр в особенности вызывает тревогу) и относительная важность функционирования устройства для всей системы управления, в которой используется контролируемое устройство. Для автоматического присвоения приоритетов могут быть использованы обсуждавшиеся здесь категории FAILED, MAINTENANSE и ADVISORY. Например, если в системе 1202 управления событиями используются численные значения от 1 до 10, представляющие возрастающие уровни приоритета параметра, то система 1202 управления событиями может присвоить численное значение, равное десяти, предупреждениям или аварийным сигналам, которые отнесены к категории FAILED, может присвоить численное значение, равное пяти, предупреждениям или аварийным сигналам, относящимся к категории MAINTENANSE, и может присвоить численное значение, равное единице, предупреждениям или аварийным сигналам, относящимся к категории ADVISORY. Разумеется, системному пользователю или оператору можно разрешить изменить эти автоматически присвоенные приоритеты, и тогда он сможет присвоить одному или нескольким выбранным параметрам другой приоритет. Например, инженер по техническому обслуживанию может посчитать, что конкретное устройство является особенно важным для работы системы управления технологическим процессом или установки, и может присвоить высокий приоритет (например, десять) всем предупреждениям или аварийным сигналам, связанным с этим устройством, даже в том случае, если часть либо все предупреждения или аварийные сигналы, связанные с выбранными параметрами для этого устройства, были отнесены по своему характеру к категории MAINTENANSE или ADVISORY. С другой стороны, в случае, когда устройство в системе управления технологическим процессом или установке просто используется для контроля некритического параметра технологического процесса, пользователь или оператор может установить относительно низкий приоритет (например, единицу) для предупреждений или аварийных сигналов, принятых в связи с этим устройством, даже в том случае, если часть либо все предупреждения или аварийные сигналы, связанные с выбранными параметрами для этого устройства, относятся к категории FAILED. Таким образом, разные устройства в системе управления технологическим процессом могут иметь разные приоритеты для одного и того же предупреждения или аварийного сигнала, поскольку функционирование некоторых из устройств может быть гораздо важнее, чем других. Как и в вышеописанном процессе выбора устройств, процесс выбора параметров и определения приоритетов может быть реализован с использованием графического интерфейса пользователя на основе окон. Вдобавок, если это необходимо, автоматически или по запросу пользователя или оператора могут быть обеспечены всплывающие окна помощи, помогающие при определении подходящего уровня приоритета для каждого из выбранных параметров.

Кроме того, как показано на фиг.29, система 1202 управления событиями может включать в себя нормативный механизм 1212, который определяет, следует ли посылать в одну или несколько систем 1204 для коммерческих задач предупреждения или аварийные сигналы, полученные системой 1202 управления событиями. Нормативный механизм 1212 может быть реализован с использованием относительно простых правил, таких как, например, справочная таблица, которая действует как фильтр, показывая, какие предупреждения или аварийные сигналы следует посылать или не посылать в те или иные системы 1204 для коммерческих задач. С другой стороны, в нормативном механизме 1212 могут быть реализованы более сложные правила, такие как комплексная условная логика, которая рассматривает один или несколько статусов установки, состояний системы управления технологическим процессом и т.д. Только в качестве примера, условная логика может быть аналогична или идентична таким логическим условиям, как, например, «если условие А истинно, то тогда выполнить действие В».

Как показано на фиг.29, система 1202 управления событиями может также включать в себя один или несколько конечных автоматов 1214 и базу данных 1216. Базовые принципы функционирования конечных автоматов хорошо известны специалистам в данной области техники и поэтому подробно здесь не описываются. Однако конечные автоматы 1214 специально адаптированы для предоставления нормативному механизму 1212 информации о состоянии. В частности, конечные автоматы 1214 могут хранить в базе данных таблицу состояний, к которой может обращаться нормативный механизм 1212 для извлечения информации о состоянии, чтобы определить, например, являются ли одно или несколько условий (таких как вышеуказанное условие «А») истинным или ложным, прежде чем определить, следует ли предпринимать какое-либо действие.

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

При работе система 1206 управления активами посылает предупредительную или аварийную информацию, связанную с конкретными параметрами конкретных устройств, которые были выбраны во время выполнения стандартных программ 1210 конфигурации. Нормативный механизм 1212 обрабатывает принятую предупредительную или аварийную информацию и определяет, какая из систем 1204 для коммерческих задач, если вообще такие системы имеются, будет принимать уведомления. Эти уведомления могут включать в себя предупреждение, приоритет, связанный с этим предупреждением, и описание предупреждения, которое может быть обеспечено или получено из описания устройства. Такие описания могут включать в себя, например, текстовую информацию, относящуюся к ремонту и/или замене устройства, для решения обнаруженной проблемы. Вдобавок, эти уведомления предпочтительно предназначены для вызова некоторого действия в результате приема уведомлений системами 1204 для коммерческих задач. В некоторых случаях система для коммерческих задач может быть рассчитана для запроса уведомлений, и в этих случаях система 1202 управления событиями будет высылать уведомления только в том случае, если сделаны указанные запросы. Однако в других случаях система для коммерческих задач может просто принимать уведомления от системы 1202 управления событиями без необходимости опроса системы 1202 управления событиями.

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

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

Системы 1204 для коммерческих задач также могут быть адаптированы для посылки подтверждающей информации в систему 1202 управления событиями. В сущности говоря, эти подтверждения включают в себя информацию о действиях, которые были предприняты в связи с использованием пользователем или оператором систем 1204 для коммерческих задач или в связи с взаимодействием пользователя или оператора с системой 1204. Эти подтверждения могут использоваться системой 1202 управления событиями для стирания событий и/или обновления состояния конечных автоматов 1214 в системе 1202 управления событиями. Система 1202 управления событиями может также посылать подтверждающую информацию в систему 1206 управления активами для хранения в базе данных 1208. Например, в случае использования CMMS система CMMS может посылать подтверждения в базу данных 1208 через систему 1202 управления событиями в ответ на оформления нарядов на работу, в ответ на запрос на предупредительное техническое обслуживание, в ответ на назначение персонала для конкретной проблемы или наряда на работу, когда работа, связанная с нарядом на работу или запросом на предупредительное техническое обслуживание, завершена, когда наряд на работу или запрос на предупредительно техническое обслуживание закрыт и т.д. Таким путем подтверждающая информация, хранящаяся в базе данных 1208, может быть использована для обеспечения полной регистрации и документации работ, выполненных на устройствах, которые контролируются системой 1206 управления активами. Разумеется, подтверждения, посланные системами для коммерческих задач других типов (то есть, которые не являются системами CMMS), согласованы с особенностями системы для коммерческих задач.

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

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

На фиг.30 представлена блок-схема информационных потоков в системе 1300, которая может быть использована в технологической установке, такой как технологическая установка 10 по фиг.1. Различные технологические объекты в технологической установке либо оборудование для контроля, диагностики и т.д., которое контролирует технологические объекты, могут создавать информацию о рабочем состоянии, связанную с различными технологическими объектами. Обычно информация о рабочем состоянии, связанная с множеством этих технологических объектов, не согласована с независимо сообщаемыми аварийными параметрами FAILED_ALM, MAINT_ALM и ADVISE_ALM, описанными выше. Для облегчения интегрированного контроля и/или обработки и/или отображения этой информации о рабочем состоянии система 1304 отображения отображает информацию о рабочем состоянии в вышеописанные категории FAILED_ALM, MAINT_ALM и ADVISE_ALM. Система 1304 отображения предоставляет таким образом, например, возможность сообщения информации о рабочем состоянии или ее отображения системному оператору, обслуживающему персоналу, коммерческому персоналу и т.д. более согласованным и логически упорядоченным образом по сравнению с известными системами. Система 1300 по фиг.30 может быть реализована в такой системе, как технологическая установка 10 по фиг.1, и обсуждается ниже со ссылками на фиг.1.

Система 1304 отображения может принимать информацию о рабочем состоянии, связанную с различными технологическими объектами, в том числе, полевыми устройствами 1308, программными средствами 1312 управления технологическим процессом, аппаратными средствами 1316 (например, технологические контроллеры, устройства ввода/вывода, рабочие станции оператора, сетевое оборудование и т.д.), системами 1320 контроля и/или диагностики, программными или математическими моделями 1324, системами 1332 оптимизации, системами 1336 технического обслуживания и т.д. В технологической установке 10 по фиг.1 система 1304 отображения может быть реализована, например, с помощью компьютера 30. В конкретном примере система 1304 отображения может быть реализована как часть программных средств, подобных программным средствам 1050 обработки аварийных сигналов, описанной со ссылками на фиг.22 и 23. В дополнительных примерах система 1304 отображения может быть реализована как часть системы 1202 управления событиями и/или системы 1206 управления активами, описанных со ссылками на фигуры 28 и 29.

Систему 1304 отображения можно реализовать с помощью одного или нескольких других компьютеров, рабочих станций и т.д., таких как компьютеры 12А, 14А, 18, 22, 26, 35, 36 и т.д. Например, часть системы 1304 отображения, относящаяся к отображению информации о рабочем состоянии, связанной с вращающимся оборудованием, можно реализовать с помощью компьютера 22, а другую часть системы 1304 отображения, относящуюся к отображению информации о рабочем состоянии, связанной с оборудованием для производства/распределения электроэнергии, можно реализовать с помощью компьютера 26. Таким образом, система 1304 отображения может быть реализована на одном компьютере, либо система 1304 отображения может представлять собой распределенную систему, реализованную на основе множества компьютеров.

Полевые устройства 1308 могут включать в себя устройства Fieldbus, устройства HART, устройства, осуществляющие связь согласно открытым протоколам, таким как PROFIBUS®, WORLDFIP®, DEVICE-NET®, CAN, Ethernet и т.д., устройства, которые осуществляют связь согласно фирменным протоколам и т.д. Информация о рабочем состоянии, связанная с полевым устройством 1308, может включать в себя предупреждение или аварийный сигнал, статус состояния или другую информацию, относящуюся к рабочему состоянию полевого устройства 1308. Обратимся к фиг.1, где полевые устройства 1308 могут включать в себя полевые устройства 15 и 16. Информация о рабочем состоянии, связанная с полевыми устройствами 1308, может приниматься от полевых устройств 15 и 16, компьютеров 12А, 14А, 18, контроллеров 12В, 14В и т.д.

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

Информация о рабочем состоянии, связанная с аппаратным устройством 1316, может включать в себя аварийные сигналы или предупреждения либо другую информацию, относящуюся к рабочему состоянию аппаратного устройства 1316. Обратимся к фиг.1, где аппаратные устройства 1316 могут включать в себя контроллеры 12В, 14В, платы 312С ввода/вывода, компьютеры 12А, 14А, 18, 22, 26, 30 и т.д. Аппаратные устройства могут также включать в себя сетевые устройства, такие как переключатели, маршрутизаторы, мосты, концентраторы и т.д. Сетевые устройства могут быть подсоединены к сети, такой как сеть Ethernet. Кроме того, сеть может быть сконфигурирована для осуществления связи согласно простому протоколу сетевого управления (SNMP). Кроме того, информация о рабочем состоянии, связанная с аппаратным устройством 1316, может включать в себя аварийные сигналы, предупреждения, сообщения и т.д., созданные программными средствами, выполняемыми на этом аппаратном устройстве. В одном примере информация о рабочем состоянии, связанная с аппаратным устройством 1316, может представлять собой информацию, созданную сетевым объектом. Сетевой объект может посылать информацию о рабочем состоянии в соответствии с протоколом SNMP.

Системы 1320 контроля и/или диагностики могут включать в себя системы, которые выполняют контроль и/или диагностический анализ как вышеописанные системы. Например, указанные системы могут выполнять контроль и/или диагностический анализ в технологической системе (например, система диагностики основных причин отказов), вращающемся оборудовании, оборудовании для производства и/или распределения электроэнергии и т.д. Информация о рабочем состоянии, связанная с системой 1320 контроля и/или диагностики, может включать в себя аварийные сигналы или предупреждения либо любую другую информацию, относящуюся к рабочему состоянию технологической системы или контролируемого и/или анализируемого оборудования с помощью системы 1320 контроля и/или диагностики. Обратимся к фиг.1, где контролируемое/анализируемое оборудование может включать в себя, например, вращающееся оборудование 20, оборудование 25 для производства/распределения электроэнергии и т.д., причем рабочая информация может приниматься, например, от компьютеров 22 и 26.

Программные или математические модели 1324 и экспертные системы 1328 могут включать в себя модели и экспертные системы типа тех, что были описаны выше. Системы 1332 оптимизации и системы 1336 технического обслуживания могут включать в себя системы оптимизации и технического обслуживания типа тех, которые были описаны выше.

Система 1304 отображения может принимать информацию о рабочем состоянии, связанную с технологическим объектом, и создавать соответствующее аварийное сообщение (например, FAILED_ALM, MAINT_ALM и ADVISE_ALM, описанные выше). Соответствующее аварийное сообщение может быть создано на основе информации о рабочем состоянии, а также дополнительных факторов (например, местоположении технологического объекта или сегмента технологической установки, в котором находится технологический объект; частота, с которой полевое устройство, программный модуль управления технологическим процессом и т.д. генерирует предупреждения, аварийные сигналы, статусы состояний и т.д.; тип полевого устройства; предпочтения пользователя и т.д.). Информация о рабочем состоянии, связанная с технологическим объектом, может включать в себя, например, значение приоритета, значение серьезности и т.д., указывающее на относительную серьезность проблемы, статус и т.д. технологического объекта. В этом случае система 1304 отображения может создать соответствующий аварийный параметр на основе значения приоритета или серьезности.

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

Аварийные сообщения FAILED_ALM, MAINT_ALM и ADVISE_ALM и NO_COMMUNICATION могут создаваться способом и в формате, аналогичными способам и аварийным сообщениям, описанным выше. Например, аварийные сообщения могут быть отформатированы для окончательного отображения на интерфейсе пользователя. В другом примере аварийные сообщения могут быть отформатированы в соответствии с таким форматом, как стандарты DS-71 или DS-72 IEEE для связи с другим устройством. Вдобавок, аварийное сообщение может включать в себя информацию, указывающую на уровень приоритета, рекомендуемое действие, ссылку на текст или документ, где предлагается подробная помощь, и т.д. Текст или документ, на который сделана ссылка, может включать в себя процедуру для обработки проблемы, документ, диаграмму, ссылку на другой документ, ссылку на диаграмму и т.д.

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

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

Описанная здесь система 1304 отображения может быть реализована с использованием любой требуемой комбинации аппаратных и программных средств. Указанные аппаратные средства могут включать в себя программируемые контроллеры, микропроцессоры, специализированные интегральные схемы или любые другие цифровые схемы и/или аналоговые схемы. Программные реализации могут использовать любую комбинацию языков программирования высокого и более низкого уровней, причем указанные программные средства могут храниться в любом запоминающем устройстве, считываемом компьютером, в том числе, на твердотельном, магнитном и оптическом носителе. Вдобавок, система 1304 отображения может осуществлять связь с другими системами через любую требуемую сеть связи, в том числе, например, шину, сеть LAN, сеть WAN, Интернет и т.д.

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

Принимается информация о рабочем состоянии, связанном с технологическим объектом в технологической установке. Информация о рабочем состоянии отображается в один из множества статусов состояния. Затем создается предупредительное сообщение, связанное с технологическим объектом, где предупредительное сообщение указывает на один статус состояния из множества статусов состояния. Технический результат - обеспечение оптимизации управления технологическим процессом. 3 н. и 38 з.п. ф-лы, 32 ил., 1 табл.

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

2. Способ по п.1, дополнительно содержащий:
прием информации о втором рабочем состоянии, связанном со вторым технологическим объектом в технологической установке, причем информация о втором рабочем состоянии показывает рабочее состояние второго технологического объекта и информация о втором рабочем состоянии сконфигурирована в соответствии со вторым форматом;
отображение информации о втором рабочем состоянии в статус состояния, связанный с рабочим состоянием второго технологического объекта, причем статус состояния, связанный с рабочим состоянием второго технологического объекта, является одним из множества статусов состояния; и
создание второго предупредительного сообщения, связанного со вторым технологическим объектом, причем второе предупредительное сообщение указывает статус состояния, связанный с рабочим состоянием второго технологического объекта.

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

4. Способ по п.1, в котором информацию о первом рабочем состоянии принимают в соответствии с протоколом связи, выбранным из группы, состоящей из следующих протоколов: Fieldbus, HART, PROFIBUS®, WORLDFIP®, DEVICE-NET®, CAN И Ethernet.

5. Способ по п.1, дополнительно содержащий отображение индикации первого предупредительного сообщения на интерфейс пользователя.

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

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

8. Способ по п.1, в котором первый технологический объект содержит полевое устройство.

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

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

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

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

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

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

15. Способ по п.14, в котором прием информации о первом рабочем состоянии содержит прием сообщения, связанного с сетевым объектом.

16. Способ по п.14, в котором прием информации о первом рабочем состоянии содержит прием сообщения в соответствии с протоколом Simple Network Management (простой протокол сетевого управления).

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

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

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

20. Способ по п.1, в котором первый технологический объект содержит оборудование для производства электроэнергии.

21. Способ по п.1, в котором первый технологический объект содержит оборудование для распределения электроэнергии.

22. Способ по п.1, в котором прием информации о первом рабочем состоянии содержит прием информации о рабочем состоянии от системы контроля.

23. Способ по п.1, в котором прием информации о первом рабочем состоянии содержит прием информации о рабочем состоянии от диагностической системы.

24. Способ по п.1, в котором прием информации о первом рабочем состоянии содержит прием информации о рабочем состоянии от модели.

25. Способ по п.1, в котором прием информации о первом рабочем состоянии содержит прием информации о рабочем состоянии от экспертной системы.

26. Способ по п.1, в котором прием информации о первом рабочем состоянии содержит прием информации о рабочем состоянии от системы оптимизации.

27. Способ по п.1, в котором прием информации о первом рабочем состоянии содержит прием информации о рабочем состоянии от системы технического обслуживания.

28. Способ по п.1, в котором множество статусов состояния содержит рекомендательный (ADVISORY) статус, статус технического обслуживания (MAINTANANCE) и статус отказа (FAILED).

29. Способ по п.1, в котором множество статусов состояния дополнительно содержит статус отсутствия связи (NO COMMUNICATION).

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

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

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

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

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

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

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

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

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

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

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

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