Результат интеллектуальной деятельности: СПОСОБЫ И УСТРОЙСТВО ДЛЯ СНИЖЕНИЯ ТРЕБОВАНИЙ К ПАМЯТИ ДЛЯ ПРИЛОЖЕНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В СИСТЕМАХ КОНТРОЛЯ ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА

ОБЛАСТЬ ТЕХНИКИ

[0001] Данная заявка в целом относится к архитектуре программного обеспечения и, в частности, к способам и устройству для снижения требований к памяти для приложений программного обеспечения в системах контроля технологического процесса.

УРОВЕНЬ ТЕХНИКИ

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

[0003] Информация от полевых устройств и/или контроллера, как правило, доступна посредством шины данных или коммуникационной сети к одному или нескольким полевым устройствам, таких как: операторская рабочая станция, персональные компьютеры, базы хранения данных, генераторы отчетов, централизованные базы данных и т.п. Такие устройства, как правило, руководят «высокоуровневыми» компьютерными приложениями системы контроля технологически процессом, которые позволяют операторам и/или инженерам выполнять любую из разновидностей функции по отношению к процессам в системе контроля технологического процесса и взаимодействию с различными контроллерами, специализированными устройствами и другими компонентами в рамках системы контроля технологического процесса. В дополнение к приложениям программного контроля и проверки работы системы контроля технологического процесса, операторы и/или инженеры могут также использовать приложения программного обеспечения по управлению активами и/или другие приложения программного обеспечения для установки, конфигурации, поддержки и/или тестирования надежности компонентов и устройств в рамках системы контроля технологического процесса, проверяющие, действительно ли выполняется связанный процесс. К этим различным «высокоуровневым» приложениям программного обеспечения при этом относятся как к приложениям программного обеспечения управления технологическим процессом.

[0004] В дополнение к «высокоуровневым» приложениям программного обеспечения управления технологическим процессом, контроллеры полевых устройств и/или других компонентов системы контроля технологическим процессом сопоставляют приложения программного обеспечения, которые взаимодействуют с приложениями программного обеспечения управления технологическим процессом. Тем не менее, контроллеры, полевые устройства и/или другие компоненты в системе контроля технологического процесса могут выпускаться разными производителями. Соответственно, каждый производитель может предоставлять разные аппаратные устройства, каждое с соответствующим программным обеспечением, которое отличается от аппаратуры и программного обеспечения других производителей. Кроме того, разработчики приложений программного обеспечения управления технологическим процессом могут связываться с другой организацией. Как результат, много производителей и разработчиков программного обеспечения в индустрии системы контроля технологического процесса создают аппаратуру и программное обеспечение, которые соответствует стандартизированным интерфейсным структурам приложения, с целью сделать возможным взаимодействие между различными компьютерными приложениями и аппаратурой процесса в рамках системы контроля технологического процесса.

[0005] Типичная интерфейсная структура приложения, используемая в индустрии системы контроля технологического процесса, базируется на связывании и внедрении объектов (OLE), модели компонентных объектов (СОМ) и модели распределенных компонентных объектов (DCOM) - технологиях, разработанных Microsoft^®, так же, как и последующие поколения технологий, включая СОМ+ и .NET. На общем уровне, эти интерфейсные структуры приложения обеспечивают общую структуру к интерфейсным компонентам/объектам приложений программного обеспечения на базе Windows.

[0006] Спецефическое выполнение этих интерфейсных структур на базе компонентов в рамках индустрии управления процессом известна как технология программного инструментария настройки полевых устройств (FDT). FDT технология определяет стандарты для коммуникации и конфигурации интерфейса между всеми полевыми устройствами и их узлом (узлами) в рамках установки системы контроля технологического процесса. FDT включает два главных компонента: (1) FDT Frame application и (2) программное средство управления конкретным типом устройств (DTM). FDT Frame application - это хост-приложение, такое «высокоуровневое» приложение программного обеспечения управления техническим процессом, которое может сообщаться и/или взаимодействовать с любым из программных средств управления конкретным типом устройств (DTM) в рамках системы контроля технологического процесса, основанной на стандартизированной интерфейсной структуре FDT технологии.

[0007] DTM - это пакет программного обеспечения, который связан с определенным полевым устройством или другим оборудованием системы контроля технологического процесса, включая все данные по устройству, функции и правила управления, а также элементы пользовательского интерфейса для оператора и/или инженера с целью конфигурирования, управления и/или поддержки устройства через FDT Frame application. Кроме того, некоторые программные средства управления конкретным типом устройств (DTM), известны как CommDTMs, разработаны специально для коммуникационного оборудования (например, шлюзы, мультиплексоры и т.п.), которые делают возможным конверсию данных с одного протокола на другой (например, Ethernet, HART, PROFIBUS и т.п.). Соответственно, FDT технология делает возможным аналоговую или цифровую интеграцию устройств от любого производителя, которая соответствует FDT структуре по одному или нескольким протоколам полевых шин через одиночный пользовательский интерфейс (т.е., FDT Frame application). Другая реализация интерфейсных структур на базе компонентов, описанная выше, известна как интерфейс полевого устройства или как интеграция полевого устройства (FDI), которая основывается на FDT технологии. В частности, FDI технология берет FDT технологию и включает стандарты, известные в индустрии технологического процесса относительно технологии описания устройства (DD) для того, что бы в дальнейшем сделать возможным взаимодействие и коммуникацию полевых устройств в рамках установки системы контроля технологического процесса.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

[0009] ФИГ. 2 иллюстрирует примерный способ реализации примерной операторской станции на ФИГ. 1.

[0010] ФИГ. 3 иллюстрирует известный дисплей основного пользовательского интерфейса, связанный с примерным основным приложением на ФИГ. 2, и первый и второй вторичный пользовательский интерфейсы, связанные с первыми и вторыми экземплярами вторичного приложения на ФИГ. 2.

[0011] ФИГ. 4А иллюстрирует другой известный дисплей основного пользовательского интерфейса вместе с известной архитектурой программного обеспечения, изображая первый вторичный пользовательский интерфейс на ФИГ. 3 в рамках основного пользовательского интерфейса.

[0012] ФИГ. 4В иллюстрирует известный дисплей из ФИГ. 4А со вторым вторичным пользовательским интерфейсом на ФИГ. 3, изображенного в рамках основного пользовательского интерфейса на ФИГ. 4.

[0013] ФИГ. 5 иллюстрирует примерную реализацию архитектуры программного обеспечения для генерирования дисплея 400 на ФИГ. 4А и 4В.

[0014] ФИГ. 6А иллюстрирует примерную однопользовательскую/однопроцессную пространственную архитектуру технологического процесса для реализации архитектуры программного обеспечения на ФИГ. 5.

[0015] ФИГ. 6В иллюстрирует примерную многопользовательскую/многопроцессную пространственную архитектуру технологического процесса для реализации архитектуры программного обеспечения на ФИГ. 5 с примером использования внепроцессной серверной архитектуры.

[0016] ФИГ. 6С иллюстрирует альтернативную примерную внепроцессную серверную архитектуру, которая может реализовываться в пространственной архитектуре технологического процесса на ФИГ. 6В.

[0017] ФИГ. 7 - это блок-схема примерного процесса, который может осуществляться с целью реализации примерной архитектуры программного обеспечения на ФИГ. 5, примерной пространственной архитектуры технологического процесса на ФИГ. 6А-6С, и/или, в целом, примерной операторской станции на ФИГ. 1 и/или ФИГ. 2.

[0018] ФИГ. 8 - это схематическая иллюстрация примерного компьютера 800, который может использоваться и/или программироваться для осуществления примерного процесса на ФИГ. 7.

КРАТКОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0021] Многие системы управления технологическим процессом содержат многочисленные различные устройства и другое оборудование, которое может выпускаться множеством разных производителей. Более того, каждый производитель, как правило, развивает свои собственные проприетарные приложения программного обеспечения, связанные с каждым устройством. Тем не менее, индустрия разработала стандартизированные непроприоретарные интерфейсные структуры приложения (например, FDT технологии), которые могут включаться в одно из приложений программного обеспечения по устройству (например, DTMs) для того, чтобы сделать возможным «высокоуровневое» приложение программного обеспечения управления технологическим процессом (например, FDT Frame application), которое также соответствует стандартизированной структуре для того, чтобы узнавать и взаимодействовать с программным обеспечением устройства, связанного с каждым из различных устройств. До тех пор, пока последующее описание детализирует примеры, главным образом, на базе FDT технологии, обучение этого изобретения может быть адаптированным к любому другому подходящему компоненту на базе интерфейсной структуры, такой как, к примеру, упомянутая выше FDI технология.

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

[0023] ФИГ. 1 схематически иллюстрирует примерную систему контроля технологического процесса 100, в рамках которой могут осуществляться идеи этого изобретения. Примерная система контроля технологического процесса 100 на ФИГ. 1 включает один или более контроллеров технологического процесса (один из которых обозначен референтным номером 102), одну или более операторских станций (одна из которых обозначена референтным номером 104), и одну или более рабочую станцию (одна из которых обозначена референтным номером 106). Примерный контроллер технологического процесса 102, примерная операторская станция 104 и примерная рабочая станция 106 коммуникационно связаны через шину и/или локальную сеть (LAN) 108, к которой, как правило, относятся как к приложению контроля сети (ACN).

[0024] Примерная операторская станция 104 на ФИГ. 1 позволяет оператору и/или инженеру просматривать и/или работать с одним или более операторскими экранами и/или приложениями, которые дают возможность оператору и/или инженеру оценить переменные, состояния, условия, аварийные сигналы системы контроля технологического процесса; изменить установки системы контроля технологического процесса (например, контрольные точки, оперативное состояние, сигналы тревоги, отключение сигналов и т.п.); конфигурировать и/или калибровать устройства в рамках системы контроля технологического процесса системы 100; выполнять диагностику устройства в рамках системы контроля технологического процесса системы 100; и/или иным образом взаимодействовать с устройствами в рамках системы контроля технологического процесса системы 100. Ниже описан примера способа реализации примерной операционной станции 104, проиллюстрированной на ФИГ. 1 в сочетании с ФИГ. 2.

[0025] Примерная операторская станция 104 включает и/или реализует основное приложение (например, примерное основное приложение на ФИГ. 2) для того, чтобы служить как приложение программного обеспечения управления технологическим процессом. Основное приложение связано с основным пользовательским интерфейсом (например, примерный основной пользовательский интерфейс на ФИГ. 4) для отображения информации и/или обеспечения визуальных индикаций состояния системы контроля технологического процесса и ее составляющими частями. До тех пор, пока операторы и/или инженеры могут достигать высокоуровневого обзора системы контроля технологического процесса посредством основного пользовательского интерфейса основного приложения, они могут также ожидать более подробную информацию и/или контроль определенных устройств в рамках системы контроля технологического процесса. Соответственно, примерная операторская станция 104 также включает и/или реализует одно или более вторичное приложение (например, примерное(-ые) вторичное(-ые) приложение(-я) на ФИГ. 2), связанных со специальными устройствами, которые содержат основной программный код и функциональные компоненты для выполнения устройство-ориентированных задач, включая поддержку, калибровку, надежность тестирования, конфигурацию, диагностику, коммуникацию, сбор данных и хранение, электронный адрес, печатание и т.п. Более того, примерные вторичные приложения также включают основные компоненты пользовательского интерфейса для создания контента для вторичного пользовательского интерфейса согласно с вышеупомянутыми задачами, связанными со специальными устройствами. В некоторых примерах операторы и/или инженеры могут вызывать вторичные приложения посредством основного приложения, которые служат как «высокоуровневые» хост-приложения для взаимодействия или коммуникации со вторичными приложениями многих устройств в рамках системы контроля технологического процесса. Более того, в некоторых примерах интерфейсная структура между основным и вторичными приложениями позволяет некоторые или все выводы на дисплей, которые генерируются вторичными приложениями для передачи в рамках основного пользовательского приложения. Таким образом, пока основные функциональные компоненты и компоненты пользовательского интерфейса устройство-ориентированного программного обеспечения выполняются соответствующим вторичным приложением, конечный контент вторичного пользовательского интерфейса (или его частей) может включаться в основной пользовательский интерфейс, чтобы позволить проверку и/или взаимодействие оператором и/или инженером через основной пользовательский интерфейс.

[0026] Примерная рабочая станция 106 на ФИГ. 1 может конфигурироваться как станция приложения для выполнения одного или более IT-приложений, пользовательских интерактивных приложений и/или коммуникационных приложений. Например, рабочая станция 106 может конфигурироваться для выполнения преимущественно приложений, связанных с контролем технологических процессов, в то время как другая станция приложения (не показана) может конфигурироваться для выполнения преимущественно коммуникационных приложений, которые позволяют системе контроля технологического процесса 100 связываться с другими устройствами или процессами, используя любое коммуникационное средство (например, беспроводные, проводные и т.п.) и протоколы (например, HTTP, SOAP и т.п.). Примерная операторская станция 104 и примерная рабочая станция 106, проиллюстрированные на ФИГ. 1, могут реализовываться посредством использования одной или более рабочих станций и/или любых других совместимых компьютерных систем и/или систем обработки. Например, операторская станция 104 и/или рабочая станция 106 могут реализовываться, используя одноядерные персональные компьютеры, одно- или многоядерные рабочие станции и т.п.

[0027] Примерная LAN 108 на ФИГ. 1 может реализовываться, используя любое возможное средство коммуникации и протокола. Например, LAN 108 может базироваться на проводной и/или беспроводной коммуникационной схеме Ethernet. Однако, как будет без промедления оценено людьми с обычными практическими навыками, может использоваться любое другое совместимое средство(-ва) коммуникации и/или протокол(-ы). Более того, хотя на ФИГ. 1 проиллюстрирована единичная LAN 108, более чем одна LAN и/или другие альтернативные части коммуникационного оборудования могут использоваться для обеспечения избыточных каналов связи между приллюстрированными на ФИГ. 1 системами.

[0028] Примерный контроллер 102 на ФИГ. 1 связан со множеством интеллектных полевых устройств 110, 112 и 114 через шину данных 116 и входной/выходной (I/O) шлюз 118. К умным полевым устройствам 110, 112 и 114 относятся совместимые вентили полевой шины, соленоиды, датчики и т.п., при этом умные полевые устройства 110, 112 и 114 сообщаются через шину данных 116, используя хорошо известный протокол Foundational Fieldbus. Конечно, вместо них могут использоваться и другие типы интеллектных полевых устройств и протоколов связи. Например, интеллектные полевые устройства 110, 112 и 114 могут вместо этого быть совместимыми устройствами Profibus и/или HART, которые связываются через шину данных 116, используя связь Profibus и HART. Дополнительные I/O устройства (подобные и/или идентичные I/O шлюзу 118) могут связываться с контроллером 102 для возможности создания дополнительных групп интеллектных полевых устройств, которые могут быть устройствами Foundation Fieldbus, устройствами HART и т.п., чтобы связываться с контроллером 102.

[0029] Примерные интеллектные полевые устройства 110,112 и 114, одно или более неинтеллектные полевые устройства 120 и 122 могут коммуникационно соединяться с примерным контроллером 102. Примерные неинтеллектные полевые устройства 120 и 122 на ФИГ. 1 могут быть, к примеру, стандартными устройствами 4-20 милиампер (mA) или 0-24 вольт постоянного тока (VDC), которые соединяются с контроллером 102 через соответствующие проводные соединения.

[0030] Контроллер 102 на ФИГ. 1 может быть, например, контроллером DeltaV™, который продается Fisher-Rosemount Systems, Inc., Emerson Process Management company. Тем не менее, вместо него можно использовать любой другой контроллер. Кроме того, несмотря на то, что только один контроллер 102 проиллюстрирован на ФИГ. 1, дополнительные контроллеры и/или платформы контроля технологического процесса любого желаемого типа или комбинации типов могут соединяться к LAN 108. В любом случае, примерный контроллер 102 выполняет одну или более подпрограмм контроля технологического процесса, связанных с системой контроля технологического процесса 100, которая произведена системным инженером и/или другим системным оператором, используя операторскую станцию 104 и которая была загружена и/или подтверждена в контроллере 102.

[0031] Несмотря на то, что ФИГ. 1 иллюстрирует примерную систему контроля технологического процесса 100, в рамках которой способы и аппаратура для отображения интерфейса приложения программного обеспечения управления технологическим процессом, более подробно описанных ниже, может выгодно использоваться, способы и аппаратура для контроля информации, предоставленные операторам и/или инженерам, описанные здесь, могут, при желании, выгодно использоваться на другом оборудовании технологического процесса и/или системах контроля технологического процесса большей или меньшей сложности (например, имея более чем один контроллер, более одного местоположения и т.п.), чем проиллюстрированный пример на ФИГ. 1.

[0032] ФИГ. 2 иллюстрирует примерный способ реализации примерной операционной станции 104, проиллюстрированной на ФИГ. 1. В то время, как следующее описание относится к операторской станции 104, примерный способ реализации примерной операционной станции 104 может также использоваться для реализации примерной рабочей станции 106 на ФИГ. 1. Примерная операционная станция 104 на ФИГ. 2 включает хотя бы как минимум один программируемый процессор 200. Примерный процессор 200 на ФИГ. 2 выполняет закодированные инструкции, представленные в главной памяти 202 процессора 200 (например, память RAM и/или память ROM). Процессор 200 может быть любым типом устройства обработки, такой как ядро процессора, процессор и/или микроконтроллер. Процессор 200, кроме того, может приводить в исполнение операционную систему 204, основное приложение 206, пользовательский интерфейс 208 и одно или более вторичное приложение 210. Тогда как известные архитектуры программного обеспечения могут выполнять вторичное приложение(-я) 210 как одно единственное приложение(-я), вторичное приложение(-я) 210 в раскрытых примерах могут выполняться посредством части клиентского приложения 212 и части серверного приложения 214. Примерная операционная система 204 - это операционная система от Microsoft^®. Примерная главная память 202 на ФИГ. 2 может реализовываться и/или в процессоре 200 и/или может быть одной или более памятью и/или устройствами памяти оперативно связанных с процессором 200.

[0033] Чтобы позволить оператору и/или инженеру взаимодействовать с примерным процессором 200, примерная операционная станция 104 на ФИГ. 2 включает любой тип дисплея 216. Примерные дисплеи 216 включают, но не ограничиваются этим перечнем, компьютерный монитор, компьютерный экран, телевизор, мобильное устройство (например, смартфон, Blackbarry™ и/или iPhone™), и т.п., способные отображать пользовательский интерфейс или приложение, реализованные процессором 200 и/или, в целом, примерной операторской станцией 104. Примерная операционная система 204 на ФИГ. 2 демонстрирует и/или облегчает демонстрацию примерного основного пользовательского интерфейса 208 примерного основного приложения 206 посредством и/или на примерном дисплее 216. Подобным образом примерная операционная система 204 демонстрирует и/или облегчает демонстрацию вторичного пользовательского интерфейса(-ов), связанного с примерным вторичным приложением(-ми) 210. Примерный основной пользовательский интерфейс 210 проиллюстрирован ниже на ФИГ. 3-5.

[0034] Примерное основное приложение 206 может быть «высокоуровневым» приложением программного обеспечения управления технологическим процессом или любым другим приложением программного обеспечения человеко-машинного интерфейса (HMI), которое позволяет оператору и/или инженеру проводить высокоуровневый обзор системы контроля технологического процесса (например, система контроля технологического процесса 100 на ФИГ. 1) и/или контролировать, конфигурировать, диагностировать и по другому взаимодействовать и/или приобретать данные согласно с процессами и компонентами в системе контроля технологического процесса 100. Более конкретно, основное приложение 206 может вызывать и/или связываться с различными устройствами и другими компонентами в системе контроля технологического процесса 100, включая любое программное обеспечение, связанного с каждым компонентом системы контроля технологического процесса, такими как вторичные приложения 210. Часто желаемая информация может быть получена, или желаемые задачи выполнены, за счет выполнения вторичного приложения(-ий) 210, которое, как описано выше, имеет ядро программного кода, функциональные компоненты и/или компоненты пользовательского интерфейса, связанные со специальными устройствами.

[0035] Во многих известных системах контроля технологического процесса каждое вторичное приложение 210, соответствующее определенному устройству, является унитарным приложением. По сути, когда оператор и/или инженер хотят связаться и/или взаимодействовать с определенным устройством, они вызывают и демонстрируют соответствующее вторичное приложение 210 в рамках памяти 202. Более того, в типичном оборудовании по переработке операторы и/или инженеры могут по желанию диагностировать, калибрировать, конфигурировать и т.п. более чем одно устройство за раз. Однако, нередко интересующие устройства являются такими же или подобными устройствами, локализированными в разных местах в оборудовании по переработке. Например, оборудование по переработке может иметь сотни идентичных или подобных клапанов данных, размещенных по всему пространству технологического процесса. Соответственно, каждое из этих устройств может быть связано с общим вторичным приложением 210. Однако, во многих известных системах контроля технологического процесса каждый раз оператор и/или инженер вызывает вторичное приложение 210, через основное приложение 206 демонстрируется новый экземпляр вторичного приложения 210, даже если вторичное приложение 210 уже вызывает другое устройство. Как следствие, дублирование вторичного приложения 210 много раз может приводить к ненужной нагрузке на ресурсы компьютерной памяти, тем самым уменьшая производительность и увеличивая расходы.

[0036] Чтобы уменьшить большой объем занимаемой памяти, заполненной вследствие многочисленных экземпляров одного и того же вторичного приложения 210, примерное вторичное приложение 210, описанное здесь, включает часть клиентского приложения 212 и часть серверного приложения 214, которое служит клиентскому приложению 212. Серверное приложение 214 может, в частности, содержать и выполнять большую, или любую часть вторичного приложения 210, включая любой или все функциональные компоненты ядра и/или компоненты пользовательского интерфейса ядра вторичного приложения 210. Клиентское приложение 212 служит интерфейсной частью для вторичного приложения 210, чтобы обеспечить интерфейсную связь с основным приложением 206, как описано выше. Соответственно, с точки зрения основного приложения 206 клиентское и серверное приложения 212 и 214 вместе функционируют как унитарное приложение. Т.е., так как серверное приложение 214 служит клиентскому приложению 212, выполняя компоненты программного обеспечения ядра вторичного приложения 210, клиентских(-им) интерфейсов(-ам) с основным приложением 206 с целью обеспечить аналоговую или цифровую связь между основным приложением 206 и серверным приложением 214. В результате, вторичное приложение 210 проиллюстрированного примера может включаться в состав системы контроля любого технологического процесса без необходимости изменения основного приложения 206 или что-то, лишь бы не то, что должно было быть сделано первоначально, чтобы выполнять много известных вторичных приложений, унитарных по своей природе. Интерфейс между основным приложением 206 и вторичным приложением 210 (через клиентское приложение 212) и между клиентским приложением 212 и серверным приложением 214 (в рамках вторичного приложения 210) более подробно будет описан ниже при рассмотрении ФИГ. 4-5.

[0037] Вместе с тем, что примерный способ реализации примерной операторской станции 104 из ФИГ. 1 проиллюстрирован на ФИГ. 2, структуры данных, элементы, процессы и устройства, проиллюстрированные на ФИГ. 2, могут комбинироваться, делиться, реконструироваться, пропускаться, игнорироваться и/или реализовываться любым другим способом. Кроме того, примерная операционная система 204, примерное основное приложение 206, примерный основной пользовательский интерфейс 208, примерное вторичное пользовательское приложение(-я) 210, примерное клиентское приложение 212, примерное серверное приложение 214 и/или, в целом, примерная операторская станция 104 на ФИГ. 2 могут быть реализованы за счет аппаратного средства, программного обеспечения, прошивки и/или любой комбинации аппаратного средства, программного обеспечения и/или прошивки. Более того, примерная операторная станция 104 может включать дополнительные элементы, процессы или устройства вместо или в дополнение к тем, что проиллюстрированы на ФИГ. 2, и/или может включать более чем один из любых или всех из проиллюстрированных структур данных, элементов, процессов или устройств.

[0038] ФИГ. 3 иллюстрирует известный дисплей 300 основного пользовательского интерфейса 302, связанный с примерным основным приложением 206 на ФИГ. 2 и первый и второй вторичные пользовательские интерфейсы 304a-b, связанные с первым и вторым экземплярами вторичного приложения 210. В некоторых примерах основной пользовательский интерфейс 302 может включать технологическую схему с детальной прорисовкой всех единиц оборудования (P&ID), технологическую схему (PFD), дерево устройств системы контроля технологического процесса или любую другую схему технологического процесса 306, демонстрирующую (например, используя или текст, или графику) несколько или все из устройств в рамках системы контроля технологического процесса (например, система контроля технологического процесса 100). Как описано выше, операторы и/или инженеры, заинтересованные в подробной информации касательно определенных устройств, показанных на схеме технологического процесса 306, могут кликнуть на устройство, чтобы сослаться на вторичное приложение 212 (ФИГ. 2), связанное с устройствами. Если выбираются многочисленные устройства, которые делят между собой общее вторичное приложение 212, каждый раз, когда выбирается дополнительное устройство, инициализируется дополнительный экземпляр вторичного приложения 212.

[0039] Например, операторы и/или инженеры могут пожелать диагностировать, калибровать, конфигурировать и/или выполнять другие задачи на первом вентиле 308 и втором вентиле 310, показанных на схеме технологического процесса 306 (оба связаны с таким же одинаковым вторичным приложением 210), составляя график (диаграмму) и/или другие изобразительные характеристики данных, представляющих интерес, связанных с каждых из вентилей 308 и 310. Чтобы сделать это, оператор и/или инженер может кликнуть на первый вентиль 308 в схеме технологического процесса 306 в основном пользовательском интерфейсе 302, тем самым вызывая первый экземпляр вторичного приложения 210, соответствующему первому вентилю 308. Раз сославшись, первый экземпляр вторичного приложения 210 генерирует соответствующий вторичный пользовательский интерфейс 304а с желаемым контентом на основе диагностики, калибровки, конфигурации и/или других задач, выполняемых вторичным приложением 210. Оператор и/или инженер может потом повторить процесс для второго вентиля 310 таким образом, что второй экземпляр вторичного приложения 210 генерирует второй вторичный пользовательский интерфейс 304b, включая выходные данные, соответствующие второму вентилю 310. Соответственно, хотя отображаемый контент первого и второго вторичных пользовательских интерфейсов 304a-b разный, именно такие же задачи выполнялись в каждом случае, используя аналогичные экземпляры того же самого компьютерного кода (например, два экземпляра вторичного приложения 210). Более того, помимо дублирования общих функциональных компонентов вторичного приложения 210 компоненты пользовательского интерфейса вторичного приложения 210 также дублируются с целью генерировать отдельные первый и второй вторичные пользовательские интерфейсы 304a-b. Избыточность, созданная многоразовой ссылкой на одно и то же вторичное пользовательское приложение 212 с целью выполнить одну и ту же функцию без необходимости увеличивает потребность в ресурсах компьютерной памяти, тем самым потенциально уменьшая эффективность и/или увеличивая затраты работы системы технологического процесса 100 на ФИГ. 1.

[0040] Обращаясь к ФИГ. 4А и 4В, здесь иллюстрируется другой известный дисплей 400 основного пользовательского интерфейса 402 вместе с известной архитектурой программного обеспечения 404 для передачи первого и второго вторичных пользовательских интерфейсов 406a-b в рамках основного пользовательского интерфейса 402 соответствующего первому и второму вентилям 308, 310 технологической схемы процесса 306. Как указывалось при описании ФИГ. 3, каждый вторичный пользовательский интерфейс 406a-b поддерживается отдельным экземпляром вторичного приложения 210. Во многих типичных реализациях FDT, FDT Frame application (например, основное приложение 206 обеспечивает окно или рамку 408, в пределах которого одиночное программное средство управления конкретным типом устройств (DTM) (например, одно из вторичных приложений 210) должно передавать контент (например, вторичный пользовательский интерфейс 406а). Соответственно, ФИГ. 4А иллюстрирует известный дисплей 400 с первым вторичным пользовательским интерфейсом 406а, который передается в пределах рамки 408 основного пользовательского интерфейса 402, в то время как ФИГ. 4В иллюстрирует известный дисплей 400 на ФИГ. 4А со вторым вторичным пользовательским интерфейсом 406b, который передается в пределах рамки 408 основного пользовательского интерфейса 402.

[0041] Хотя массово и не выпускается, FDT Frame application может быть адаптированным, чтобы обеспечивать отдельное пространство экрана для контента от нескольких DTM одновременно. Например, основной пользовательский интерфейс 402 может использоваться для передачи обоих вторичных пользовательских интерфейсов 406а-b одновременно. Как таковые, не смотря на то, что только один из вторичных пользовательских интерфейсов 406а-b демонстрируется за раз, оба экземпляра вторичного интерфейса приложения 210 все же полностью подтверждаются и взаимодействуют с основным приложением 206 одновременно. В частности, основное приложение 206 (ФИГ. 2) и каждый экземпляр вторичного приложения 210 взаимодействуют через интерфейсную структуру приложения, описанную выше, для передачи информации между приложениями, включая вторичные пользовательские интерфейсы 406а-b, генерируемые соответствующими экземплярами вторичного приложения 210 для передачи в пределах рамки 408 основного пользовательского интерфейса 402. Каждый экземпляр вторичного приложения 210, показанного на ФИГ. 4А и 4В, независимо взаимодействует с основным приложением 206. Соответственно, каждый экземпляр вторичного приложения 210 на ФИГ. 4 выполняет одинаковые функциональные компоненты ядра 410 и такие же компоненты пользовательского интерфейса 412 для выполнения запрашиваемых задач и генерации первого и второго вторичных пользовательских интерфейсов 406а-b, соответствующих каждому из выбранных вентилей 308 и 310.

[0042] Чтобы сделать возможной отрисовку первого и второго вторичных пользовательских интерфейсов 406а-b в пределах основного пользовательского интерфейса 402, каждый экземпляр вторичного приложения 210 в известной архитектуре программного обеспечения 404 может иметь интерфейсные компоненты приложения 414, содержащие стандартизированный код, исполняемый в пределах интерфейсной структуры приложения (например, технология FDT) для установления взаимосвязи между каждым экземпляром вторичного приложения 210 и основным приложением 206. Тем самым, каждый экземпляр вторичного приложения 210 может получать запросы от основного приложения 206 и обеспечивать соответствующий выход (например, вторичные пользовательские интерфейсы 406а-b) для включения в основной пользовательский интерфейс 402. По аналогии, основное приложение 206 может содержать стандартизированный код, устанавливаемый интерфейсной структурой приложения для передачи запросов вторичному приложению 210 и обеспечения рамки 408 в пределах основного пользовательского интерфейса 402, где может передаваться выход вторичного приложения 210. Более конкретно, часть интерфейсной связи, которая устанавливается между основным и вторичным приложениями 206 и 210, включает указатель, такой как маркер или другой умный указатель, который обеспечивается основным приложением 206, указывающее на месторасположение рамки 408 таким образом, что вторичное приложение 210 может непосредственно передавать контент, чтобы тот представлялся в основном пользовательском интерфейсе 402 через указатель. В дополнение к графическому контенту, который может демонстрироваться в пределах рамки 408, вторичные пользовательские интерфейсы 406а-b могут содержать кнопки 416 и/или другие интерактивные элементы, чтобы дать операторам и/или инженерам возможность взаимодействовать с контентом, передаваемого в пределах рамки 408 основного пользовательского интерфейса 402.

[0043] ФИГ. 5 иллюстрирует примерную архитектуру программного обеспечения 500, которая может использоваться для генерации дисплея 400 на ФИГ. 4А и 4В. В то время, как дисплей 400 на ФИГ. 5 такой же, как дисплей 400 на ФИГ. 4А, где первый вторичный пользовательский интерфейс 406а передается в пределах рамки 408 основного пользовательского интерфейса 402, лежащая в основе архитектура программного обеспечения 500 разная.

[0044] В отличии от известной архитектуры программного обеспечения 404 на ФИГ. 4А и 4В, где каждый экземпляр вторичного приложения 210 полностью подтверждается унитарным приложением, первый и второй экземпляры вторичного приложения 210 в пределах примерной архитектуры программного обеспечения 500 разделены на первый и второй экземпляры части клиентского приложения 212 (соответствующих первому и второму вентилям 308 и 310) и единичный экземпляр части серверного приложения 214, который служит обоим экземплярам клиентского приложения 212. Как проиллюстрировано, каждый экземпляр клиентского приложения 212 содержит интерфейсные компоненты приложения 414 для взаимодействия с основным приложением 206 (ФИГ. 2) так же, как и унитарные вторичные приложения 210 на ФИГ. 4А и 4В. В проиллюстрированном примере серверное приложение 214 может содержать функциональные компоненты 410 и связанный программный код вторичного приложения 210 для выполнения любой задачи (например, калибровку, конфигурацию, диагностику и т.п.), связанную с первым и вторым вентилями 308 и 310. Более того, серверное приложение 214 может содержать компоненты пользовательского интерфейса 412 вторичного приложения 210 для генерации контента для первого и второго вторичных пользовательских интерфейсов 406а-b на основе, помимо всего прочего, результатов любых вычислений или других задач, выполняемых функциональными компонентами 410. В то время, как серверное приложение 214 показано как такое, что содержит все компоненты пользовательского интерфейса 412 и функциональные компоненты 410 вторичного приложения 210, в других примерах компоненты вторичного приложения 210 могут делиться между серверным приложением 214 и клиентским приложением 212 в любой подходящий способ.

[0045] Как утверждалось выше, существует два экземпляра клиентского приложения 212 и только один экземпляр серверного приложения 214. Таким образом, в отличии от известной архитектуры программного обеспечения 404, показанной на ФИГ. 4, где функциональные компоненты 410 подтверждаются несколько раз в каждый отдельный экземпляр вторичного приложения 210, функциональные компоненты 410 в примерной архитектуре программного обеспечения 500 на ФИГ. 5 подтверждаются только раз, чтобы служить обоим экземплярам клиентского приложения 212 и выполнять конфигурацию, калибровку, диагностику и/или другие задачи, соответствующие первому и второму вентилям 308 и 310. Аналогично, в то время, как известная архитектура программного обеспечения 404, показанная на ФИГ. 4, подтверждает компоненты пользовательского интерфейса 412 несколько раз в каждом экземпляре вторичного приложения 210, в проиллюстрированном примере на ФИГ. 5 серверное приложение 214 подтверждает только один экземпляр компонентов пользовательского интерфейса 412, чтобы служить обоим экземплярам клиентского приложения 212.

[0046] Помещая функциональные компоненты ядра и/или компоненты пользовательского интерфейса ядра в одиночный экземпляр серверного приложения 214, объем памяти клиентского приложения 212 может значительно уменьшиться. Например, когда оператор и/или инженер хотят выполнить диагностику, конфигурации, калибровки и т.п. для определенных устройств, они могут вызвать примерное вторичное приложение 210, связанное с интересующими устройствами через основное приложение 206, как и раньше. Однако, в раскрытом примере, где интересующие устройства имеют общее вторичное приложение 210, только часть клиентского приложения 212 вторичного приложения 210 подтверждается для каждого устройства, в то время, как одиночное серверное приложение 214 подтверждается для службы обоим экземплярам клиентского приложения 212. Таким образом, хотя все еще существует два экземпляра клиентского приложения 212 (каждый содержащий одинаковые интерфейсные компоненты приложения 414), функциональные компоненты и компоненты пользовательского интерфейса 410 и 412, содержащиеся в серверном приложении 214, подтверждаются только раз, таким образом избегая дублирования этих компонентов. Более того, функциональные компоненты и компоненты пользовательского интерфейса 410 и 412, как правило, охватывают большую часть вторичного приложения 210. В результате, общий объем памяти примерной архитектуры программного обеспечения 500 приблизительно половина размера количества памяти, используемой известной архитектурой программного обеспечения 404, описанной в ФИГ, 4, потому что серверное приложение 214 подтверждается только раз и два экземпляра клиентского приложения 212 относительно слабые (т.е., имеют относительно маленький объем памяти).

[0047] Кроме того, сохраненное пространство памяти даже более очевидно, когда дополнительные экземпляры клиентского приложения 212 подтверждаются вне первого и второго экземпляров, потому что они также могут разделять между собой одно и тот же серверное приложение 214. Таким образом, три примерные экземпляра клиентского приложения 212 могут разделять единственное серверное приложение 214, подразумевая, что общий объем памяти - это приблизительно треть объема памяти трех полных экземпляров вторичного приложения 210, реализуемого согласно с известной архитектурой программного обеспечения 404, описного на ФИГ. 4. Соответственно, описанная здесь примерная архитектура программного обеспечения 500 может выгодно уменьшать объем памяти нескольких экземпляров вторичных приложений 210, тем самым освобождая память для других приложений, увеличивая эффективность системы и/или снижая затраты на снижение общих потребностей по памяти для того, чтобы работали желаемые приложения.

[0048] Как описано выше, каждый экземпляр клиентского приложения 212 взаимодействует с основным приложением 206, устанавливая интерфейс между основным и клиентским приложениями 206 и 212 на основе любой подходящей интерфейсной структуры приложения. Ввиду того, что интерфейсные компоненты приложения 414 первого и второго экземпляров клиентского приложения 212 на ФИГ. 5 такие же интерфейсные компоненты приложения 414 первого и второго экземпляров вторичного приложения 210 на ФИГ. 4, интерфейс между основным и клиентским приложением 206 и 212 такой же, как и интерфейс между основным и вторичным приложениями 206 и 210, рассмотренных выше при описании ФИГ. 4. Соответственно, с точки зрения основного приложения 206 нет функциональной разницы между известной архитектурой 404, описанной на ФИГ. 4А и 4В и примерной архитектурой программного обеспечения 500, показанной на ФИГ. 5. В результате разработчики программного обеспечения основного приложения 206 могут реализовать примерную архитектуру программного обеспечения 500 без изменения своих продуктов программного обеспечения до тех пор, пока основное приложение 206 соответствует стандартам интерфейсной структурой приложения для установления связи между основным приложением 206 и клиентским приложением 212. Более того основное приложение 206 может все еще взаимодействовать с унитарным вторичными приложениями 210 (как описано на ФИГ. 4), соответствуя устройствам, которые реализуют описанную здесь примерную архитектуру программного обеспечения 500.

[0049] В дополнении к взаимодействию первого и второго экземпляра клиентского приложения 212 с основным приложением 206, первый и второй экземпляр клиентского приложения 212 также взаимодействует с серверным приложением 214. В некоторых примерах клиентское и серверное приложения 212 и 214 связываются и/или взаимодействуют таким же образом, как связываются и/или взаимодействуют основное и клиентское приложения 206 и 212, как описано выше. Т.е. серверное приложение 214 может также содержать стандартизированный код, подобный интерфейсным компонентам приложения 414 экземпляров клиентского приложения 212, который соответствует интерфейсной структуре приложения; приложения позволяют каждому приложению узнавать, подтверждать и/или взаимодействовать с компонентами другого. В результате основное приложение 206 и серверное приложение 214 могут косвенно связываться и взаимодействовать через один из экземпляров клиентского приложения 212, потому что клиентское приложение 212 взаимодействует как с основным приложением 206 так и с серверным приложением 214. В некоторых примерах клиентское приложение 212 может обеспечивать немного больше, чем сквозную функциональность между основным приложением 206 и серверным приложением 214. Например, когда основное приложение 206 предоставляет указатель к одному из экземпляров клиентского приложения 212, экземпляр клиентского приложения 212 может разделять указатель с серверным приложением 214. Таки образом, поскольку серверное приложение 214 вычисляет данные или иным способом определяет контент для передачи в пределах основного пользовательского интерфейса 208, контент передается от серверного приложения 214 через указатель общий с клиентским приложением 212 непосредственно на рамку 408 основного пользовательского интерфейса 402. Аналогично, когда запрашиваются данные, графика и/или другие задачи через основной пользовательский интерфейс 206 относительно специфического устройства, соответствующее клиентское приложение 212 может разделять запросы с серверным приложением 214, которое содержит функциональные компоненты и/или компоненты пользовательского интерфейса для обеспечения или выполнения запрашиваемых данных, графиков и/или других задач.

[0050] В то время, как предшествующее обсуждение примерной архитектуры программного обеспечения 500 может реализовываться согласно стандартам FDT, интерфейс между основным и клиентским приложениями 206 и 212 так же, как и интерфейс между клиентским и серверным приложениями 212 и 214 может основываться на любой другой подходящей интерфейсной структуре, который стандартизирует взаимодействие компонентов приложений программного обеспечения. В частности, взаимодействие приложений программного обеспечения которое возможно за счет интерфейсной структуры, может включать определение наличия и/или доступности объектов/компонентов другого приложения программного обеспечения, определяя возможности объектов компонентов другого приложения программного обеспечения, подтверждая объекты/компоненты другого приложения программного обеспечения, устанавливая связи с другими объектами/компонентами другого приложения программного обеспечения (интеркоммуникация) и/или установления связей с другими объектами/компонентами того же приложения программного обеспечения (интракоммуникации) и т.п.

[0051] ФИГ. 6А-6С иллюстрируют примерные пространственные архитектуры технологического процесса 600 и 602 для выполнения архитектуры программного обеспечения 500 с ФИГ. 5. В частности, ФИГ. 6А иллюстрирует примерную однопользовательскую/однопроцессную архитектуру 600, ФИГ. 6В реализует примерную многопользовательскую/многопроцессную архитектуру 602 с примерной внепроцессной серверной архитектурой 604, и ФИГ. 6С иллюстрирует альтернативную примерную внепроцессную серверную архитектуру 606, которая может реализовываться в пределах пространственной архитектуры технологического процесса 602 на ФИГ. 6В.

[0052] Возвращаемся к ФИГ. 6А, на которой иллюстрируется одиночное основное пространство технологического процесса 608 для выполнения образца основного приложения 206 с ФИГ. 2. В проиллюстрированном примере основное приложение 206 вызывает несколько экземпляров клиентского приложения 212 в соответствии с примерной архитектурой программного обеспечения 500 на ФИГ. 5. Более того, основное пространство технологического процесса 600 на ФИГ. 6А также содержит серверное приложение 214, чтобы работать с несколькими экземплярами клиентских приложений 212. Несмотря на то, что на иллюстрированном примере изображены три экземпляра клиентского приложения 212, можно вызывать любое подходящее количество экземпляров клиентского приложения 212 посредством основного приложения 206.

[0053] ФИГ. 6В иллюстрирует примерную многопользовательскую/многопроцессную архитектуру 602 с двумя отдельными основными пространствами технологического процесса 608, каждое выполняющее экземпляр основного приложения 206. Как показано (изображено), многопользовательская/многопроцессная архитектура 602 также содержит примерную внепроцессную серверную архитектуру 604, где серверное приложение 214 выполняется в серверном пространстве технологического процесса 610, которое отделено от основных пространств технологического процесса 608. Несмотря на то, что изображены только два экземпляра основного приложения 206, любое подходящее количество основных приложений 206 может реализовываться посредством описанной здесь многоклиентной/многопроцессной архитектуры 602. Аналогично, несмотря на то, что изображена только одна внепроцессная серверная архитектура 604, может реализовываться любое количество серверных пространств технологического процесса 610, содержащих отдельные серверные приложения 214.

[0054] Основное различие между ФИГ. 6А и 6В в том, что серверное приложение 214 на ФИГ. 6В может быть независимым выполняемым (ΕΧΕ) файлом для внепроцессного выполнения в серверном пространстве технологического процесса 612, в то время как серверное приложение 214 технологического процесса на ФИГ. 6А может быть файлом динамичной библиотекой объектных модулей (DLL) для активной работы с основным приложением 206. Другими словами пространственные архитектуры технологических процессов 600 и 602 и разные приложения функционируют одинаково. Например, независимо от пространственной архитектуры технологического процесса (или согласно с ФИГ. 6А или ФИГ. 6В), каждое из одного или более экземпляров основного приложения 206, каждое из одного или более клиентских приложений 212 и каждое из одного или более экземпляров серверного приложения 214 сообщаются и/или взаимодействуют так же, как описано выше при описании ФИГ. 4 и 5.

[0055] Разные пространственные архитектуры технологических процессов 600 и 602 обеспечивают различные преимущества которые могут использоваться в зависимости от определенного приложения или обстоятельства в котором реализуются пространственные архитектуры технологических процессов 600 и 602. Например, примерное однопользовательская/однопроцессная архитектура 600 на ФИГ. 6А успешно (выгодно) выполняется в пределах единичного пространства технологического процесса для улучшения производительности коммуникации между основным и клиентским приложениями 206 и 212, потому что они в том же пространстве технологического процесса (т.е., основное пространство технологического процесса 608). Однако, если серверное приложение 214 примерной архитектуры 600 на ФИГ. 6А не срабатывает, основное приложение 206 также будет не срабатывать потому что они в том же пространстве технологического процесса (т.е., основное пространство технологического процесса 608). В отличии от этого, пример многопользовательской/многопроцессной архитектуры 602 на ФИГ. 6В решает эту проблему размещая серверное приложение 214 в своем собственном пространстве технологических процессов. Соответственно, если серверное приложение 214 не срабатывает при реализации в многопользовательской/многопроцессной архитектуре 602, это не нарушает выполнение основных приложений 206, потому что они работают в отдельных пространствах технологического процесса (т.е., основные пространства технологического процесса 608). Более того, преимущество многоклиентной/многопроцессной архитектуры 602 состоит в том, что серверное приложение 214 может работать с несколькими пользователями (например, отдельные операторские станции 104, описанные на ФИГ. 1 и/или 2).

[0056] ФИГ. 6С иллюстрирует альтернативную примерную внепроцессную серверную архитектуру 606, которая может реализовываться в пределах многоклиентной/многопроцессной архитектуры 602 на ФИГ. 6В. Как показано, серверное приложение 214 может быть файлом DLL размещенного в пределах выполняемой обертки (например, обертка серверного приложения 612). Таким образом серверное приложение 214 как файл DLL активно работает с оберткой сервисного приложения 612, в то время как обертка сервисного приложения 612 (файл ΕΧΕ) работает внепроцессно по отношению к основным пространствам технологического процесса 608, изображенных на ФИГ. 6С в отдельном серверном пространстве технологического процесса 610. Таким образом, обе однопользовательские/однопроцессные архитектуры 600 на ФИГ. 6А и многоклиентная/многопроцессная архитектура 602 на ФИГ. 6В могут реализовываться с серверным приложением 214, в одном файловом формате (т.е., DLL), размещая серверное приложение 214 в пределах обертки сервисного приложения 612 для многоклиентной/многопроцессной архитектуры 602.

[0057] ФИГ. 7 - это образец блок-схемы примерного процесса который может выполняться для реализации примерной архитектуры программного обеспечения 500 на ФИГ. 5, примерных пространственных архитектур технологического процесса 600 и 602 на ФИГ. 6А-6С и/или, в более общем, примерной операторской станции на ФИГ 1 и/или 2. В частности, примерный процесс на ФИГ. 7 может быть образцом машиночитаемых инструкций которые включают программу для выполнения процессором, таким как процессор 812, изображенном на примерном компьютере 800, обсуждаемый ниже при описании ФИГ. 8. Программа может реализовываться в программном обеспечении сохраненное на материальном компьютерночитаемом средстве, таком как CD-ROM, дискета, жесткий диск, универсальный цифровой диск (DVD), BluRay диск, или память, связанная с процессором 812. Альтернативно, несколько или все с примерного процесса на ФИГ. 7 может реализовываться, используя любую комбинацию(-ии) специализированной(-ых) интегральной(-ых) микросхемы (микросхем) (ASIK(s)), программируемой(-ых) логической(-их) интегральной(-ых) схемы (схем) (PLD(s)), логическую(-ие) интегральную(-ые) схему(-ы) с эксплуатационным программированием (FPLD(s)), дискретной логики аппаратуры, прошивки и т.п. Также, одна или более примерных станций на ФИГ. 7 могут реализовываться вручную или как любая комбинация(-ии) любых предшествующих способов, например, любая комбинация прошивки, программного обеспечения, дискретной логики и/или аппаратуры. Более того, хотя примерный процесс описан со ссылкой на блок-схему на ФИГ. 7, могут альтернативно использоваться много других способов реализации архитектуры программного обеспечения примерной архитектуры программного обеспечения 500 на ФИГ. 5, примерных пространственных архитектур технологического процесса 600 и 602 на ФИГ. 6А-6С и/или примерной операторской станции 104 на ФИГ. 1 и/или 2. Например, порядок выполнения блоков может изменяться, и/или некоторые из описанных блоков могут изменяться, исключаться или комбинироваться. К тому же, любой или все из примерного процесса на ФИГ. 7 могут выполняться последовательно и/или параллельно, например, отдельным обрабатывающим потоком процессора, устройства, дискретной логикой, схемой и т.п.

[0058] Как упоминалось выше, примерный процесс на ФИГ. 7 может реализовываться используя закодированные инструкции (например, компьютерночитаемые инструкции), сохраненные на материальном компьютерночитаемом средстве, такое как жесткий диск, flash-память, постоянное запоминающее устройство (ROM), компакт-диск (CD), универсальное цифровой диск (DVD), кэш, оперативное запоминающее устройство (RAM) и/или любые другие средства хранения на которых сохраняется информация на любую протяженность времени (например, на протяженные временные периоды, постоянно, краткие отрезки времени, для временного хранения и/или для кэширования информации). Здесь термин «материальное компьютерночитаемое средство» специально определяется как таковой, что включает любой тип компьютерночитаемого хранилища и исключает распространение сигналов. Дополнительно или альтернативно примерный процесс на ФИГ. 7 может реализовываться используя закодированные инструкции (например, компьютерночитаемые инструкции), сохраненного на не носящего временного характера компьютерочитаемое средство, такое как жесткий диск, flash-память, постоянное запоминающее устройство, компакт-диск, универсальное цифровой диск, кэш, оперативное запоминающее устройство и/или любые другие средства хранения на которых сохраняется информация на любую протяженность времени (например, на протяженные временные периоды, постоянно, краткие отрезки времени, для временного хранения и/или для кэширования информации). Здесь термин «не носящего временного характера компьютерочитаемое средство» специально определяется как таковой, что включает любой тип компьютерночитаемого средства и исключает распространение сигналов. Здесь фраза «по крайней мере» употребляется как переходной термин в преамбуле к претензии, она не ограничена во времени, так же, как и термин «содержащий». Поэтому претензии, использующие «по крайней мере» как переходной термин к своей преамбуле может включать элементы в дополнении к тем, что четко излагаются в претензии.

[0059] Примерный процесс на ФИГ. 7 начинается с блока 700, где вторичное приложение 210 (ФИГ. 2) получает запрос(-ы) от основного приложения 206 (ФИГ. 2) для выполнения компонента(-тов) вторичного приложения 210. Как показано на проиллюстрированном примере на ФИГ. 2 вторичное приложение 210 включает часть клиентского приложения 212 и часть серверного приложения 214. Более того, функциональные компоненты ядра 410 (ФИГ. 5) и/или компоненты пользовательского интерфейса ядра 412 (ФИГ. 5) вторичного приложения 210 могут быть в пределах серверного приложения 214, в то время как интерфейсные компоненты приложения 414 (ФИГ. 5) могут быть в пределах экземпляра клиентского приложения 212 для интеракции с основным приложением 206. Соответственно, в блоке 702 устанавливается интерфейс между основным приложением 206 и экземпляром(-ами) клиентского приложения 212. В частности экземпляр использования клиентского приложения 212 подтверждается в памяти 202 (ФИГ. 2), когда вызывается из основного приложения 206. Экземпляр клиентского приложения 212 и основное приложение 206 устанавливают связь через интерфейсные компоненты приложения 414 в пределах клиентского приложения 212 и соответствующих интерфейсных компонентов приложения в основном приложении 206. Помимо всего прочего, основное приложение 206 может обеспечивать клиентское приложение 212 указателем к рамке 408 (ФИГ. 5) в пределах основного пользовательского интерфейса 402 где может передаваться соответствующий вторичный пользовательский интерфейс (например, вторичные пользовательские интерфейсы 406а-b на ФИГ. 5) вторичного приложения 210.

[0060] Для выполнения компонента(-ов), запрашиваемого основным приложением 206, экземпляр клиентского приложения 212 может обращаться для установления связи к серверному приложению 214, потому что серверное приложение 214 содержит запрашиваемый компонент(-ты). Чтобы это произошло процесс на ФИГ. 7 определяет было ли уже серверное приложение 214 подтверждено для другого экземпляра клиентского приложения 212 (блок 704). Если серверное приложение 214 не вызывалось каким-то другим экземпляром клиентского приложения 212, подтверждается серверное приложение (блок 706). Как только подтверждается серверное приложение 214, клиентское приложение 212 устанавливает интерфейс с серверным приложением 214 (блок 708). Однако если на протяжении примерного процесса на ФИГ. 7 определяется, что серверное приложение 214 уже подтверждено (блок 704), контроль переходит на блок 708, где экземпляр клиентского приложения 212 устанавливает связь с уже подтвержденным серверным приложением 214. Интерфейс между экземпляром клиентского приложения 212 и серверного приложения 214 похож на интерфейс между клиентским приложением 212 и основным приложением 206. Т.е., клиентское приложение 212 соединяется с серверным приложением 214 через интерфейсные компоненты приложения 414 клиентского приложения 212 и соответствующих интерфейсных компонентов в пределах серверного приложения 214. Серверное приложение 214 может потом служить экземпляром клиентского приложения вместе с любыми другими экземплярами клиентского приложения 212, которые уже установили интерфейс с серверным приложением 214.

[0061] В блоке 710 экземпляр клиентского приложения 212 может разделять указатель, полученного от основного приложения, с серверным приложением. Таким образом, контент вторичного пользовательского интерфейса (например, вторичные пользовательские интерфейсы 406а-b на ФИГ. 5), соответствуя экземпляру клиентского приложения 212, может непосредственно отправляться на рамку 408 основного пользовательского интерфейса 210. Примерный процесс на ФИГ. 7 переходит на блок 712, где серверное приложение 214 генерирует вторичный пользовательский интерфейс, связанный с экземпляром клиентского приложения 212, работает серверное приложение 214. Серверное приложение 214 может обозначать данные для генерации вторичного пользовательского интерфейса за счет выполнения любого или всех функциональных компонентов 410, содержащихся в рамках (пределах) серверного приложения 214 и/или любого или всех компонентов пользовательского интерфейса 412, содержащихся в пределах серверного приложения 214. Серверное приложение 214 может также определять контент вторичного пользовательского интерфейса на основе дополнительных пользовательских вводных устройств, организованных через основной пользовательский интерфейс 206. Серверное приложение 214 посылает генерируемый вторичный пользовательский интерфейс, связанный с экземпляром клиентского приложения 212, основному приложению 206 через указатель, общий для экземпляра клиентского приложения (блок 714). Как только вторичный пользовательский интерфейс предоставляется основному приложению 206, основное приложение 206 может передавать вторичный пользовательский интерфейс в пределах рамки 408 основного пользовательского интерфейса 208.

[0062] Примерный процесс на ФИГ. 7 затем определяет, закончен ли экземпляр клиентского приложения 212 при использовании серверного приложения 212 (блок 716). Если экземпляр клиентского приложения 212 все еще использует серверное приложение 214, контроль возвращается к блокам 712 и 714, где серверное приложение 214 продолжает генерировать вторичный пользовательский интерфейс для экземпляра клиентского приложения 212. Если, однако, экземпляр клиентского приложения 212 заканчивается, используя серверное приложение 214, интерфейс между клиентским приложением 212 и серверным приложением 214 сбрасывается (блок 718). Примерный процесс на ФИГ. 7 затем обозначает, взаимодействуют ли другие экземпляры клиентского приложения 212 с серверным приложением 214 (блок 720). Если да, то контроль возвращается к блокам 712 и 714 для серверного приложения 214 чтобы продолжить работу другого экземпляра(-ов) клиентского приложения 212. Если никакие другие экземпляры клиентского приложения 212 не используют серверное приложение, контроль передается блоку 722, где примерный процесс определяет ждать ли новых запросов от основного приложения 206 для выполнения компонентом(-тами) вторичного приложения 210. Если да, то контроль возвращается к блоку 700, где может повторяться примерный процесс на ФИГ. 7. Если процесс на ФИГ. 7 определяет не ждать дополнительные запросы от первичного приложения 206 тогда процесс заканчивается.

[0063] ФИГ. 8 - это схематическая иллюстрация примерного компьютера 800, который может быть использован и/или запрограммирован выполнять примерный процесс на ФИГ. 7 и/или, более обще, реализовывать архитектуру программного обеспечения 500 на ФИГ. 5, примерные пространственные архитектуры технологического процесса 600 и 602 на ФИГ. 6А-6С и/или примерная операторская станция 104 на ФИГ. 1 и/или 2. Система 800 текущего примера включает процессор 812. Например, процессор 812 может реализовываться одним или более микропроцессорами или контроллерами от любой желаемой серии или производителя.

[0064] Процессор 812 включает локальную память 813 (например, кэш) и находится в связи с основной памятью, включая непостоянную память 814 и энергонезависимую память 816 через шину 818. Непостоянная память 814 может реализовываться синхронной динамической оперативной памятью (SDRAM), динамической оперативной памятью (DRAM), динамической оперативной памятью RAMBUS (RDRAM) и/или любым другим типом динамического запоминающего устройства с произвольной выборкой. Энергонезависимая память 816 может реализовываться флэш-памятью и/или любым другим желаемым типом запоминающего устройства. Доступ к основной памяти 814 и 816 контролируется контроллером памяти.

[0065] Компьютер 800 также включает схему интерфейса 820. Схема интерфейса 820 может реализовываться любым типом стандарта интерфейса, такой как интерфейс Ethernet, универсальной серийной шиной (USB), и/или последовательного интерфейса PCI Express. Одно или более вводные устройства 822 связаны со схемой интерфейса 820. Вводное устройство(-ва) 822 разрешает пользователю вводить данные и команды в процессор 812. Вводное устройство(-ва) может реализовываться, например, клавиатурой, мышкой, сенсорным экраном, сенсорной панелью шаровым указателем (трекбол), изо-точкой (терминалом) и/или системой распознавания голоса. Одно или более выходных устройств 824 также связано со схемой интерфейса 820. Выходные устройства 824 могут реализовываться, например, дисплейными устройствами (например, жидкокристаллический дисплей, дисплей с катоднолучевой трубкой (CRT), принтер и/или акустическая система). Схема интерфейса 820, таким образом, как правило включает драйвер графического адаптера.

[0066] Схема интерфейса 820 также включает коммуникационное устройство, такое как модем или сетевую карту для облегчения обмена данными с внешними компьютерами через сеть 826 (например, связь Ethernet, цифровая абонентская линия (DSL), телефонная линия, коаксиальный кабель, сотовая телефонная система и т.п.).

[0067] Компьютер 800 также включает один или более сменных носитель 828 для хранения программного обеспечения и данных. Примеры таких устройств 828: дискеты, жесткие диски, компакт диски и универсальные цифровые диски (DVD).

[0068] Закодированные инструкции 832 для реализации примерного процесса на ФИГ. 7 могут храниться на сменных носителях 828, на непостоянной памяти 814, в энергонезависимой памяти 816 и/или на съемных носителях данных, таких как CD или DVD.

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