MX2014010159A - Metodos y aparatos para reducir los requisitos de memoria para aplicaciones de software de sistemas de control de procesos. - Google Patents

Metodos y aparatos para reducir los requisitos de memoria para aplicaciones de software de sistemas de control de procesos.

Info

Publication number
MX2014010159A
MX2014010159A MX2014010159A MX2014010159A MX2014010159A MX 2014010159 A MX2014010159 A MX 2014010159A MX 2014010159 A MX2014010159 A MX 2014010159A MX 2014010159 A MX2014010159 A MX 2014010159A MX 2014010159 A MX2014010159 A MX 2014010159A
Authority
MX
Mexico
Prior art keywords
application
primary
user interface
server
client
Prior art date
Application number
MX2014010159A
Other languages
English (en)
Other versions
MX342209B (es
Inventor
David Curtis Ingram
Original Assignee
Fisher Controls Int
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fisher Controls Int filed Critical Fisher Controls Int
Publication of MX2014010159A publication Critical patent/MX2014010159A/es
Publication of MX342209B publication Critical patent/MX342209B/es

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/18Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form
    • G05B19/409Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form characterised by using manual data input [MDI] or by using control panel, e.g. controlling functions with the panel; characterised by control panel details or by setting parameters
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces
    • G06F9/452Remote windowing, e.g. X-Window System, desktop virtualisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Manufacturing & Machinery (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)

Abstract

Se revelan métodos y aparatos para reducir los requisitos de memoria de aplicaciones de software en un sistema de control de procesos. Un aparato de ejemplo incluye un espacio de proceso primario para ejecutar una aplicación primaria para usar en un sistema de control de procesos, una interfase de usuario primaria asociada con la aplicación primaria y que se ha de representar en un visualizador, y una aplicación secundaria a ser invocada mediante la aplicación primaria. La aplicación secundaria incluye una aplicación de cliente para habilitar la interacción entre la aplicación primaria y la aplicación secundaria, y una aplicación de servidor que sirve a la aplicación de cliente para implementar al menos un componente de software para generar una interfase de usuario secundaria asociada con la aplicación secundaria. La interfase de usuario secundaria se ha de comunicar a la aplicación primaria para ser representada dentro de la interfase de usuario primaria.

Description

MÉTODOS Y APARATOS PARA REDUCIR LOS REQUISITOS DE MEMORIA PARA APLICACIONES DE SOFTWARE DE SISTEMAS DE CONTROL DE PROCESOS CAMPO DE LA INVENCIÓN
[0001] Esta revelación se refiere generalmente a la arquitectura de software de computadora, y, más particularmente, a métodos y aparatos para reducir los requisitos de memoria para aplicaciones de software de sistemas de control de procesos.
ANTECEDENTES
[0002] Los sistemas de control de procesos, tales como los utilizados en procesos químicos, de petróleo u otros procesos, típicamente incluyen uno o más controladores de procesos acoplados comunicativamente a uno o más dispositivos de campo mediante buses analógicos, digitales o analógicos/digitales combinados. Los dispositivos de campo, que pueden ser, por ejemplo, válvulas, posicionadores de válvula, interruptores y transmisores (por ejemplo, sensores de temperatura, presión y caudal), llevan a cabo funciones de control de procesos dentro del proceso tales como la apertura o cierre de válvulas y la medición de parámetros de control del proceso. Los controladores de procesos reciben señales indicativas de las mediciones del proceso realizadas por los dispositivos de campo y luego procesan esta información para generar señales de control para implementar las rutinas de control, para tomar otras decisiones de control de procesos, y para iniciar alarmas del sistema de control de procesos.
[0003] La información de los dispositivos de campo y/o del controlador generalmente se hace disponible sobre datos de alta velocidad o red de comunicaciones a uno o más dispositivos de hardware, tales como estaciones de trabajo de operadores, computadoras personales, historiadores de datos, generadores de informes, bases de datos centralizadas, etc. Tales dispositivos típicamente ejecutan una aplicación de software de sistemas de control de procesos de "nivel superior" que permite a los operadores y/o a los ingenieros realizar cualquiera de una variedad de funciones con respecto a los procesos de un sistema de control de procesos y de interactuar con los diversos controladores, dispositivos de campo, y otros componentes dentro del sistema de control de procesos. Además de las aplicaciones de software de sistemas de control de procesos para controlar la operación de un sistema de control de procesos, los operadores y/o ingenieros también pueden utilizar las aplicaciones de software de gestión de activos y/o otras aplicaciones de software para instalar, configurar, mantener y/o poner a prueba la fiabilidad de componentes y dispositivos dentro del sistema de control de procesos tanto si el proceso asociado está o no en realidad en operación. Estas diversas aplicaciones de software de "nivel superior" se denominan colectivamente en la presente como aplicaciones de software de gestión de procesos.
[0004] Además de las aplicaciones de software de gestión de procesos de "nivel superior", muchos de los controladores individuales, dispositivos de campo y/o otros componentes del sistema de control de procesos tienen aplicaciones de software asociadas que interactúan con las aplicaciones de software de gestión de procesos. Sin embargo, los controladores, dispositivos de campo y/o otros componentes en un sistema de control de procesos pueden ser producidos por cualquier número de fabricantes diferentes. En consecuencia, cada fabricante puede proporcionar diferentes dispositivos de hardware, cada uno con software correspondiente que es diferente del hardware y software de otros fabricantes. Además, los desarrolladores de las aplicaciones de software de gestión de procesos pueden estar asociados con otra entidad. Como resultado, muchos fabricantes y desarrolladores de software en la industria de sistemas de control de procesos crean hardware y software que concuerdan con marcos de interfase de aplicaciones estandarizados a fin de permitir la interacción entre las diferentes aplicaciones de software y hardware de procesos dentro de un sistema de control de procesos.
[0005] Una marco de interfase de aplicaciones típico utilizado en la industria de los sistemas de control de procesos se basa en la tecnologías de vinculación e incrustación de objetos (OLE, por sus siglas en inglés), el modelo de objetos componentes (COM, por sus siglas en inglés), y el modelo de objetos componentes distribuidos (DCOM, por sus siglas en inglés) desarrolladas por Microsoft®, como así también generaciones posteriores de la tecnología tal como COM+ y NET. A nivel general, estos marcos de interfase de aplicaciones proporcionan una estructura común para una interfase de componentes / objetos de aplicaciones de software basadas en Windows.
[0006] Una aplicación particular de estos marcos de interfase en base a componentes dentro de la industria de gestión de procesos se conoce como la tecnología de herramienta de dispositivo de campo ("field device ???G) (FDT, por sus siglas en inglés). La tecnología FDT define los estándares para la interfase de comunicaciones y de configuración entre todos los dispositivos de campo y su (s) servidor (es) dentro de una configuración de sistema de control de procesos. La tecnología FDT consiste en dos componentes principales: (1 ) una aplicación Marco FDT y (2) un Gestionador de Tipo de Dispositivo ("Device Type Manager") (DTM, por sus siglas en inglés). Una aplicación Marco FDT es una aplicación de servidor, tal como una aplicación de software de gestión de procesos de un "nivel superior", que se puede comunicar y/o interactuar con cualquiera de los DTM dentro de un sistema de control de procesos en base al marco de interfase estandarizado de la tecnología FDT.
[0007] Un DTM es un paquete de software asociado con un dispositivo de campo particular u otro equipo de control de proceso del sistema que contiene todos los datos específicos, las funciones y las reglas de gestión del dispositivo como así también los elementos de interfase de usuario para que un operador y/o ingeniero configure, opere, y/o mantenga el dispositivo mediante la aplicación marco FDT. Además, algunos DTM conocidos como CommDTMs se desarrollan específicamente para equipos de comunicación (por ejemplo, puertas de acceso {"gateways"), multiplexores, etc.) para permitir la conversión de los datos de un protocolo a otro (por ejemplo, Ethernet, HART, PROFIBUS, etc.) En consecuencia, la tecnología FDT permite la integración perfecta de los dispositivos de cualquier fabricante que cumpla con el marco FDT sobre uno o varios protocolos de bus de campo mediante una única interfase de usuario (es decir, la aplicación del Marco FDT). Otra aplicación de los marcos de interfase basados en componentes descritos anteriormente se conoce como interfase de dispositivos de campo o integración de dispositivos de campo ("field device integration") (FDI, por sus siglas en inglés) que se basa en la tecnología FDT. En particular, la tecnología FDI toma la tecnología FDT e incorpora estándares conocidos en la industria de procesos respecto a la tecnología de descripción de dispositivos (DD, por sus siglas en inglés) para permitir aun más la interfase y comunicación de dispositivos de campo dentro de una configuración de sistema de control de procesos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0008] La figura 1 es una ilustración esquemática de un sistema de control de procesos de ejemplo dentro del cual se pueden implementar las enseñanzas de la presente divulgación.
[0009] La figura 2 ilustra un modo de ejemplo de cómo implementar la estación de operador ejemplo de la figura 1.
[0010] La figura 3 ilustra una visualización conocida de una interfase de usuario primaria asociada con la aplicación primaria de ejemplo de la figura 2 y la primera y segunda interfases de usuario secundarias asociadas con la primera y segunda instancias de la aplicación secundaria de la figura 2.
[0011] La figura 4A ilustra otra visualización conocida de una interfase de usuario primaria junto con una arquitectura de software conocida representando la primer interfase de usuario secundaria de la figura 3 dentro de un marco de la interfase de usuario primaria.
[0012] La figura 4B ilustra la visualización conocida de la figura 4A con la segunda interfase de usuario secundaria de la figura 3 que se representa dentro del marco de la interfase de usuario primaria de la figura 4.
[0013] La figura 5 ilustra un ejemplo de una arquitectura de software implementada para generar la visualización 400 de las figuras 4A y 4B.
[0014] La figura 6A ilustra un ejemplo de arquitectura de espacio de un proceso de único usuario / único proceso para implementar la arquitectura de software de la figura 5.
[0015] La figura 6B ilustra un ejemplo de arquitectura de espacio de un proceso multi usuario / multi proceso para implementar la arquitectura de software de la figura 5 con un ejemplo de arquitectura de servidor fuera del proceso.
[0016] La figura 6C ilustra un ejemplo alternativo de arquitectura de servidor fuera del proceso que se puede implementar dentro de la arquitectura de espacio de proceso de la figura 6B.
[0017] La figura 7 es un diagrama de flujo representativo de un proceso de ejemplo que se puede llevar a cabo para implementar la arquitectura de software de ejemplo de la figura 5, las arquitecturas de espacio de proceso de ejemplo de las Figuras 6A -6C, y/o, más en general, la estación de operador de ejemplo de la figura 1 y/o 2.
[0018] La figura 8 es una ilustración esquemática de una computadora 800 de ejemplo que se puede utilizar y/o programar para llevar a cabo el proceso de ejemplo de la figura 7.
SÍNTESIS
[0019] Se revelan los métodos y aparatos para reducir los requisitos de memoria de aplicaciones de software en un sistema de control de procesos. En un ejemplo, un aparato incluye un espacio de proceso primario para ejecutar una aplicación primaria, una interfase de usuario primaria asociada con la aplicación primaria y que se representa en un visualizador para su uso en un sistema de control de procesos, y una aplicación secundaria para ser invocada mediante la aplicación primaria. La aplicación secundaria incluye una aplicación de cliente para habilitar la interacción entre la aplicación primaria y la aplicación secundaria, y una aplicación de servidor que sirve a la aplicación de cliente para implementar al menos un componente de software para generar una interfase de usuario secundaria asociada con la aplicación secundaria, y donde la interfase de usuario secundaria se ha de comunicar a la aplicación primaría a ser representada dentro de la interfase de usuario primaria.
[0020] En otro ejemplo, un método implica recibir una solicitud mediante una interfase de usuario primaria asociada con una aplicación primaria asociada con un sistema de control de procesos para ejecutar al menos un componente de una aplicación secundaria asociada con un dispositivo en el sistema de control de procesos, en donde la aplicación secundaria incluye una aplicación de cliente y una aplicación de servidor, y en donde el al menos un componente es implementado por la aplicación de servidor, instanciando una primera instancia de la aplicación de cliente para habilitar la interacción con la aplicación primaria, instanciando la aplicación de servidor para servir a la aplicación de cliente, generando una interfase de usuario secundaria asociada con la primera instancia de la aplicación de cliente en base a el al menos un componente implementado por la aplicación de servidor, y comunicando la interfase de usuario secundaria a la aplicación primaria para representar la interfase de usuario primaria.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
[0021] Muchos sistemas de control de procesos contienen numerosos dispositivos diferentes y otros equipos que pueden ser producidos por una variedad de diferentes fabricantes. Más aun, cada fabricante generalmente desarrolla sus propias aplicaciones de software propietario que están asociadas con cada dispositivo. Sin embargo, la industria ha desarrollado marcos de interfase de aplicaciones estandarizados no propietarios (por ejemplo, la tecnología FDT) que pueden ser incorporados dentro de cada una de las aplicaciones de software específicas del dispositivo (por ejemplo, los DTM) para permitir una aplicación de software de gestión de procesos de un "nivel superior" (por ejemplo, una aplicación Marco FDT), que también cumple con el marco estandarizado, para reconocer e interactuar con el software específico del dispositivo asociado con cada uno de los diferentes dispositivos. Si bien los siguientes detalles de ejemplos de descripción se basan principalmente sobre la tecnología FDT, las enseñanzas de esta revelación se pueden adaptar a cualquier otro marco de interfase basado en componentes adecuado, tal como, por ejemplo, la tecnología FDI mencionada anteriormente.
[0022] Típicamente, cuando los operadores y/o ingenieros desean diagnosticar, configurar, calibrar, o de otra manera interactuar con un dispositivo dentro de un sistema de control de procesos, invocan el software específico del dispositivo del dispositivo de interés mediante la aplicación de software de gestión de procesos. Una vez invocado, el software específico del dispositivo puede llevar a cabo la tarea seleccionada y luego proporcionar una salida correspondiente a la aplicación de software de gestión de procesos para la visualización basada sobre el marco estandarizado que interconecta la aplicación de software de gestión de procesos y el software específico del dispositivo. Por lo tanto, aunque el visualizador puede estar integrado en una única interfase de usuario asociada con la aplicación primaria, la lógica central de negocio que incluye los componentes funcionales del software y/ o los componentes de software de la interfase de usuario asociados con el dispositivo están contenidos y se ejecutan por el correspondiente software específico del dispositivo. En algunas circunstancias, los operadores y/o los ingenieros pueden desear realizar configuraciones, diagnósticos, calibraciones, etc. sobre más de un dispositivo a la vez. En consecuencia, cada vez que se selecciona un nuevo dispositivo para centrarse en el mismo, la aplicación de software de gestión de procesos puede invocar el correspondiente software específico del dispositivo. Más aun, cuando los operadores y/o ingenieros desean centrarse sobre una cantidad de dispositivos iguales o similares situados en diferentes lugares a lo largo de un sistema de control de procesos, la aplicación de software de gestión de procesos invocará una instancia separada del software específico del dispositivo, aunque cada uno de los dispositivos seleccionados tenga el mismo software asociado a él. Por ejemplo, un sistema de control de procesos puede tener muchas válvulas producidas por un fabricante en común y, por lo tanto, cada una de las válvulas puede estar asociada con el mismo software propietario que contiene la misma lógica de negocio para llevar a cabo las configuraciones, calibraciones, diagnósticos, u otras tareas asociadas con cada una de las válvulas. Como resultado, si los operadores y/o ingenieros desean trabajar con más de una de estas válvulas, los mismos componentes funcionales centrales y/o componentes de interfase de usuario del software específico del dispositivo compartidos por cada una de las válvulas seleccionadas pueden crear una instancia múltiples veces Esta creación de instancias redundante de componentes de software comunes pueden incrementar los requerimientos de memoria de la computadora y/o reducir el rendimiento de la gestión de procesos y de las aplicaciones de software relacionadas.
[0023] La figura 1 es una ilustración esquemática de un ejemplo de sistema de control de procesos 100 dentro del cual se pueden implementar las enseñanzas de la presente divulgación. El sistema de control de procesos de ejemplo 100 de la figura 1 incluye uno o más controladores de procesos (uno de las cuales se designa con el número de referencia 102), una o más estaciones de operador (una de las cuales se designa con el número de referencia 104), y una o más estaciones de trabajo (una de las cuales se designa con el número de referencia 106). El controlador de procesos de ejemplo 102, la estación de operador de ejemplo 104 y la estación de trabajo de ejemplo 106 están acoplados comunicativamente mediante un bus y/o una red de área local (LAN) 108, que se conoce comúnmente como una red de control de aplicaciones (ACN, por sus siglas en inglés).
[0024] La estación de operador de ejemplo 104 de la figura 1 permite a un operador y/o ingeniero revisar y/u operar una o más pantallas de visualización del operador y/o aplicaciones que permiten al operador y/o ingeniero ver las variables del sistema de control de procesos, estados, condiciones, alarmas, cambiar las configuraciones del sistema de control de procesos (por ejemplo, puntos establecidos, estados operativos, borrar alarmas, silenciar alarmas, etc.); configurar y/o calibrar dispositivos dentro del sistema de control de procesos 100; realizar diagnósticos de los dispositivos dentro del sistema de control de procesos 100, y/o de otra manera interactuar con los dispositivos dentro del sistema de control de procesos 100. Un modo de ejemplo de implementar la estación de operador de ejemplo 104 de la figura 1 se describe a continuación en relación con la figura 2.
[0025] La estación de operador de ejemplo 104 incluye y/o implementa una aplicación primaria (por ejemplo, la aplicación primaria de ejemplo de la figura 2) para servir como una aplicación de software de gestión de procesos. La aplicación primaria está asociada con una inferíase de usuario primaria (por ejemplo, la inferíase de usuario primaria de ejemplo de la figura 4) para visualizar la información y/o proporcionar indicaciones visuales del estado del sistema de control de procesos y de sus partes componentes. Si bien los operadores y/o los ingenieros pueden lograr una visión general de alto nivel de un sistema de control de procesos mediante la ¡nterfase de usuario primaria de la aplicación primaria, los mismos pueden desear también obtener información más detallada y/o el control de dispositivos particulares dentro del sistema de control de procesos. En consecuencia, la estación de operador de ejemplo 104 también incluye y/o implementa una o más aplicaciones secundarias (por ejemplo, la (s) aplicación (es) secundaria (s) de ejemplo de de la figura 2) asociadas con dispositivos específicos que contienen la lógica central de negocio y los componentes funcionales para llevar a cabo tareas específicas de dispositivo, incluyendo el mantenimiento, calibración, pruebas de fiabilidad, configuración, diagnóstico, comunicaciones, recolección y almacenamiento de datos, correo electrónico, impresión, etc. Más aun, las aplicaciones secundarias de ejemplo también incluyen los componentes centrales de la interfase de usuario para generar contenidos para una interfase de usuario secundaria correspondiente a las tareas mencionadas anteriormente asociadas con el dispositivo específico. En algunos ejemplos, los operadores y/o ingenieros pueden invocar las aplicaciones secundarias mediante la aplicación primaria, que sirve como una aplicación servidora de "nivel superior" para interactuar y/o comunicarse con las aplicaciones secundarias de los muchos dispositivos dentro del sistema de control de procesos. Más aun, en algunos ejemplos, el marco de la interfase entre las aplicaciones primarias y secundarias permite que alguna o todas las visualizaciones generadas por las aplicaciones secundarias se representen dentro de la interfase de usuario primaria. De esta manera, mientras que los componentes centrales de software funcionales y de interfase de usuario de un dispositivo específico son ejecutadas por una aplicación secundaria correspondiente, el contenido resultante de la interfase de usuario secundaria (o partes del mismo) pueden estar incrustados dentro de la interfase de usuario primaria para permitir la revisión y/o la interacción por un operador y/o ingeniero mediante la interfase de usuario primaria.
[0026] La estación de trabajo de ejemplo 106 de la figura 1 se puede configurar como una estación de aplicación para llevar a cabo una o más aplicaciones de tecnología de información, aplicaciones interactivas con usuarios y/o aplicaciones de comunicaciones. Por ejemplo, la estación de trabajo 106 se puede configurar para llevar a cabo principalmente las aplicaciones de procesos relacionadas con control, mientras que otra estación de aplicación (no se muestra) se puede configurar para llevar a cabo principalmente las aplicaciones de comunicaciones que permiten al sistema de control de procesos 100 comunicarse con otros dispositivos o sistemas usando cualquier medio de comunicación (por ejemplo, inalámbrico, cableado, etc.) y protocolos (por ejemplo, HTTP, SOAP, etc.) deseados. La estación de operador de ejemplo 104 y la estación de trabajo de ejemplo 106 de la figura 1 se pueden implementar usando una o más estaciones de trabajo y/o cualesquiera otros sistemas informáticos y/o sistemas de procesamiento adecuados. Por ejemplo, la estación de operador 104 y/o la estación de trabajo 106 podrían ser implementadas utilizando computadoras personales con procesador único, estaciones de trabajo con un procesador o con múltiples procesadores, etc.
[0027] La LAN 108 de ejemplo de de la figura 1 se puede implementar utilizando cualquier medio de comunicación y protocolo deseados. Por ejemplo, la LAN 108 de ejemplo puede estar basada sobre un esquema de comunicaciones Ethernet cableado y/o inalámbrico. Sin embargo, tal como podrá ser apreciado fácilmente por aquellas personas con experiencia normal en la técnica, cualquier otro medio (s) de comunicaciones adecuado (s) y/o protocolo (s) podría (n) ser utilizado (s). Más aun, aunque se ilustra una sola LAN 108 en la figura 1 , más de una LAN y/o otras piezas alternativas de hardware de comunicaciones pueden usarse para proporcionar rutas de comunicación redundantes entre los sistemas de ejemplo de la figura 1.
[0028] El controlador de ejemplo 102 de la figura 1 está acoplado a una pluralidad de dispositivos de campo inteligentes 1 10, 112 y 114 mediante un bus de datos 1 16 y una puerta de enlace de entrada / salida (l/O) 1 18. Los dispositivos de campo inteligentes 1 10, 112 y 114 pueden ser válvulas, actuadores, sensores, etc. compatibles con Fieldbus, en cuyo caso los dispositivos de campo inteligentes 1 10, 112 y 1 14 se comunican mediante el bus de datos 116 usando el bien conocido protocolo Foundation Fieldbus. Por supuesto, otros tipos de dispositivos de campo inteligentes y protocolos de comunicación se podrían utilizar en su lugar. Por ejemplo, los dispositivos de campo inteligentes 1 10, 112, y 114 podrían ser dispositivos compatibles con Profibus y/o HART que se comunican mediante el bus de datos 1 16 usando los bien conocidos protocolos de comunicación Profibus y HART. Dispositivos adicionales l/O (similares y/o idénticos a la puerta de enlace l/O 1 18 se pueden acoplar al controlador 102 para permitir que grupos adicionales de dispositivos de campo inteligentes, que pueden ser dispositivos Foundation Fieldbus, dispositivos HART, etc. se comuniquen con el controlador 102.
[0029] Además de los dispositivos de campo inteligentes 1 10, 1 12 y 114 de ejemplo, uno o más dispositivos de campo no inteligentes 120 y 122 pueden estar acoplados comunicativamente al controlador de ejemplo 102. Los dispositivos de campo no inteligentes 120 y 122 de ejemplo de la figura 1 pueden ser, por ejemplo, dispositivos de 4-20 miliamperios (mA) convencionales o de 0-24 voltios de corriente continua (VDC) que se comunican con el controlador 102 mediante respectivos enlaces cableados.
[0030] El controlador 102 de ejemplo de de la figura 1 puede ser, por ejemplo, un controlador DeltaV™ comercializado por Fisher-Rosemount Systems, Inc., una empresa de Emerson Process Management. Sin embargo, cualquier otro controlador podría ser utilizado en su lugar. Más aun, si bien sólo se muestra un controlador 102 en la figura 1 , controladores adicionales y/o plataformas de control de procesos de cualquier tipo deseado y/o combinación de tipos podrían estar acoplados a la LAN 108. En cualquier caso, el controlador 102 de ejemplo lleva a cabo una o más rutinas de control de proceso asociadas con el sistema de control de procesos 100 que han sido generadas por un ingeniero de sistemas y/u otro operador de sistema utilizando la estación de operador 104 y que se han descargado a y/o creado una instancia en el controlador 102.
[0031] Si bien la figura 1 ilustra un ejemplo de un sistema de control procesos 100 dentro de la cual los métodos y aparatos para visualizar una interfase de una aplicación de software de gestión de procesos que se describe en mayor detalle a continuación pueden ser empleados ventajosamente, los métodos y aparatos para controlar la información que se presenta a los operadores y/o ingenieros que se describe en la presente memoria puede, si se desea, emplearse ventajosamente en otras plantas de proceso y/o sistemas de control de procesos de mayor o menor complejidad (por ejemplo, que tiene más de un controlador, a través de más de una ubicación geográfica, etc.) que en el ejemplo ilustrado de la figura 1.
[0032] La figura 2 ilustra un modo de ejemplo de implementar la estación de operador 104 de ejemplo de la figura 1. Si bien la siguiente descripción se proporciona con respecto a la estación de operador 104, la manera ejemplo de implementar la estación de operador de ejemplo 104 también se puede usar para implementar la estación de trabajo de ejemplo 106 de la figura 1. La estación de operador de ejemplo 104 de la figura 2 incluye al menos un procesador programable 200. El procesador de ejemplo 200 de la figura 2 ejecuta las instrucciones codificadas presentes en una memoria principal 202 del procesador 200 (por ejemplo, dentro de una memoria de acceso aleatorio (RAM) y/o una memoria de sólo lectura (ROM)). El procesador 200 puede ser cualquier tipo de unidad de procesamiento, tal como un núcleo de procesador, un procesador y/o un microcontrolador. El procesador 200 puede ejecutar, entre otras cosas, un sistema operativo 204, una aplicación primaria 206, una interfase de usuario primaria 208, y una o más aplicaciones secundarias 210. Si bien arquitecturas de software conocidas pueden ejecutar la (s) aplicación (es) secundaria (s) 210 como aplicación (es) unitaria (s) única (s), la (s) aplicación (es) secundaria (s) 210 en los ejemplos descritos se pueden ejecutar mediante una porción de la aplicación de cliente 212 y una porción de aplicación de servidor 214. Un ejemplo de sistema operativo 204 es un sistema operativo de Microsoft®. La memoria principal de ejemplo 202 de la figura 2 puede ser implementada por y/o dentro del procesador 200 y/o puede ser una o más memorias y/o dispositivos de memoria acoplados operativamente al procesador 200.
[0033] Para permitir que los operadores y/o ingenieros interactúen con el procesador de ejemplo 200, la estación de operador 104 de ejemplo de la figura 2 incluye cualquier tipo de visualizador 216. Ejemplos de visualizadores 216 incluyen, pero no se limitan a, un monitor de computadora, una pantalla de computadora, un televisor, un dispositivo móvil (por ejemplo, un teléfono inteligente, un Blackberry™ y/o un iPhone™), etc., capaces de visualizar ¡nterfases de usuario y/o aplicaciones implementadas por el procesador 200 y/o, más generalmente, la estación de operador 104 de ejemplo. El sistema operativo de ejemplo 204 de la figura 2 exhibe y/o facilita la visualización de la interfase de usuario primaria de ejemplo 208 de la aplicación primaria 206 de ejemplo por y/o en visualizador de ejemplo 216. Del mismo modo, el sistema operativo 204 de ejemplo exhibe y/o facilita la visualización de la (s) interfase (s) de usuario secundaria (s) asociada (s) con la (s) aplicación (es) secundaria (s) de ejemplo (s) 210. Una interfase de usuario primaria de ejemplo 210 se describe a continuación en relación con las figuras 3 - 5.
[0034] La aplicación primaria de ejemplo 206 puede ser una aplicación de software de gestión de procesos de "nivel superior" o cualquier otra aplicación de software de interfase hombre-máquina (HMI, por sus siglas en inglés) que permita a un operador y/o ingeniero tener una visión general de alto nivel del sistema de control de procesos (por ejemplo, el sistema de control de procesos 100 de la figura 1 ) y/o controlar, configurar, diagnosticar, o de otra manera interactuar con y/o adquirir datos con respecto a los procesos y componentes del sistema de control de procesos 100. Más específicamente, la aplicación primaria 206 puede invocar y/o comunicarse con los diversos dispositivos y otros componentes dentro del sistema de control de procesos 100, incluyendo cualquier software asociado con cada componente de sistema de control de procesos, tales como las aplicaciones secundarias 210. Con frecuencia, la información deseada se puede obtener, o las tareas deseadas se pueden llevar a cabo, mediante la ejecución de la (s) aplicación (es) secundaria (s) 210 que, tal como se ha descrito anteriormente, contiene (n) la lógica de negocio central, los componentes funcionales, y/o los componentes de interfase de usuario asociados con dispositivos específicos.
[0035] En muchos sistemas de control de procesos conocidos, cada aplicación secundaria 210 correspondiente a un dispositivo particular es una aplicación unitaria. Como tal, cuando los operadores y/o ingenieros desean comunicarse y/o interactuar con un dispositivo en particular, toda una aplicación secundaria 210 correspondiente es invocada y se crea una instancia dentro de la memoria 202. Más aun, en una planta de procesamiento típica, los operadores y/o ingenieros pueden desear diagnosticar, calibrar, configurar, etc., más de un dispositivo a la vez. Sin embargo, no es poco común que los dispositivos de interés sean los mismos dispositivos o dispositivos similares situados en diferentes lugares de la planta de procesamiento. Por ejemplo, una planta de procesamiento puede tener cientos de válvulas idénticas o similares ubicadas en todo el espacio de proceso. Por consiguiente, cada uno de estos dispositivos puede estar asociado con una aplicación secundaria común 210. Sin embargo, en muchos sistemas de control de procesos conocidos, cada vez que un operador o ingeniero invoca la aplicación secundaria 210 mediante la aplicación primaria 206 se crea una nueva instancia de la instancia de la aplicación secundaria 210, incluso si la aplicación secundaria 210 ya se ha invocado para otro dispositivo. Como resultado, la duplicación de una aplicación secundaria 210 múltiples veces puede dar lugar a cargas innecesarias sobre los recursos de memoria de la computadora, lo cual reduce la eficiencia e incrementa los costos.
[0036] Para atenuar los efectos de la gran huella de memoria que resulta de múltiples instancias de la misma aplicación secundaria 210, la aplicación secundaria 210 de ejemplo que se describe en la presente comprende una porción de aplicación de cliente 212 y una porción de aplicación de servidor 214 que sirve a la aplicación de cliente 212. En particular, la aplicación de servidor 214 puede contener y ejecutar la mayoría, o cualquier parte de la misma, de la aplicación secundaria 210 incluyendo cualquiera o todos los componentes funcionales centrales y/o los componentes centrales de la inferíase de usuario de la aplicación secundaria 210. La aplicación de cliente 212, a su vez, sirve como una interfase para la aplicación secundaria 210 para permitir la relación de interfases con la aplicación primaria 206 tal como se describe anteriormente. En consecuencia, desde la perspectiva de la aplicación primaria 206, las aplicaciones de cliente y de servidor 212 y 214 colectivamente funcionan para comportarse como una aplicación unitaria. Es decir, mientras que la aplicación de servidor 214 sirve a la aplicación de cliente 212 ejecutando los componentes centrales de software de la aplicación secundaria 210, el cliente interactúa con la aplicación primaria 206 para proporcionar una conexión fluida entre la aplicación primaria 206 y la aplicación de servidor 214. Como resultado, la aplicación secundaria 210 del ejemplo ilustrado se puede incorporar dentro de cualquier sistema de control de procesos sin tener que alterar la aplicación primaria 206 ni ninguna otra cosa más que lo se habría hecho originalmente para implementar muchas aplicaciones secundarias conocidas que son de naturaleza unitaria. La interfase entre la aplicación primaria 206 y la aplicación secundaria 210 (mediante la aplicación de cliente 212) y entre la aplicación de cliente 212 y la aplicación de servidor 214 (dentro de la aplicación secundaria 210) se describirá más completamente a continuación en relación con las figuras 4 - 5.
[0037] Si bien un modo de ejemplo de implementar la estación de operador 104 de ejemplo de la figura 1 se ha ilustrado en la figura 2, las estructuras de datos, elementos, procesos y dispositivos ilustrados en la figura 2 se pueden combinar, dividir, cambiar de sitio, omitir, eliminar y/o implementar de cualquier otra manera. Más aun, el sistema operativo de ejemplo 204, la aplicación primaria de ejemplo 206, la inferíase de usuario primaria de ejemplo 208, la (s) aplicación (es) secundaria (s) de ejemplo 210, la aplicación de cliente de ejemplo 212, la aplicación de servidor de ejemplo 214, y/o, más en general, la estación de operador de ejemplo 104 de la figura 2 se pueden implementar mediante hardware, software, programación fija o de fábrica ("firmware") y/o cualquier combinación de hardware, software y/o "firmware". Más aún, la estación de operador de ejemplo 104 puede incluir elementos adicionales, procesos y/o dispositivos en lugar de, o además de, aquellos ilustrados en la figura 2, y/o puede incluir más de uno de cualquiera, o todas las estructuras de datos, elementos, procesos y/o dispositivos que se ilustran.
[0038] La figura 3 ilustra una visualización conocida 300 de una interfase de usuario primaria 302 asociada con la aplicación primaria de ejemplo 206 de la figura. 2 y la primera y segunda interfases de usuario secundarias 304 a - b asociadas con la primera y segunda instancias de la aplicación secundaria 210. En algunos ejemplos, la interfase de usuario primaria 302 puede incluir un diagrama de tuberías e instrumentación (P & ID, por sus siglas en inglés), un diagrama de flujo del proceso (PFD, por sus siglas en inglés), el árbol de dispositivos del sistema de control de procesos, u otra disposición de planta de proceso 306 que exhibe (por ejemplo, utilizando texto y/o gráficos), algunos o todos los dispositivos dentro de un sistema de control de procesos (por ejemplo, el sistema de control de procesos 100). Tal como se ha descrito anteriormente, los operadores y/o ingenieros interesados en la información detallada con respecto a dispositivos particulares de los exhibidos en la distribución de planta 306 pueden clickear sobre los dispositivos para invocar la aplicación secundaria 212 (figura 2) asociada con los dispositivos. Si se seleccionan múltiples dispositivos que comparten una aplicación secundaria 212, cada vez que se selecciona un dispositivo adicional, se instancia una instancia adicional de la aplicación secundaria 212.
[0039] Por ejemplo, los operadores y/o ingenieros pueden desear diagnosticar, calibrar, configurar y/o llevar a cabo otras tareas sobre una primera válvula 308 y una segunda válvula 310 que se muestran en la distribución ("layouf) de la planta de proceso 306 (ambas asociadas con la misma aplicación secundaria 210) mediante el trazado de un gráfico y/o otros datos que representa las características de interés asociadas con cada una de las válvulas 308 y 310. Para ello, el operador y/o ingeniero puede hacer clic sobre la primer válvula 308 en la distribución de la planta 306 en la interfase de usuario primaria 302, con lo cual invocación una primera instancia de la aplicación secundaria 210 que corresponde a la primer válvula 308. Una vez invocada, la primer instancia de la aplicación secundaria 210 genera la correspondiente interfase de usuario secundaria 304a con el contenido deseado, en base a los diagnósticos, la calibración, la configuración y/u otras tareas ejecutadas por la aplicación secundaria 210. El operador y/o ingeniero puede entonces repetir el proceso para la segunda válvula 310 de tal manera que una segunda instancia de la aplicación secundaria 210 genera la segunda interfase de usuario secundaria 304b que contiene datos de salida correspondientes a la segunda válvula 310. En consecuencia, aunque el contenido exhibido de la primera y segunda interfases de usuario secundarias 304 a - b es diferente, en cada caso se llevaron a cabo las mismas tareas utilizando instancias duplicadas del mismo código informático (es decir, dos instancias de la misma aplicación secundaria 210). Más aun, más allá de la duplicación de componentes funcionales comunes de la aplicación secundaria 210, los componentes de la interfase de usuario de la aplicación secundaria 210 también se duplican para generar las primera y segunda interfases de usuario secundarias separadas 304 a - b. La redundancia creada mediante la invocación de la misma aplicación secundaria 212 múltiples veces para realizar la misma función incrementa innecesariamente la demanda de recursos de memoria de computadora, de esta manera potencialmente reduciendo la eficiencia y/o incrementando los costos de funcionamiento del sistema de control de procesos 00 de la figura 1.
[0040] Volviendo ahora a las figuras 4A y 4B, en la presente se ilustra otra visualización 400 conocida de una interfase de usuario primaria 402 junto con una arquitectura de software 404 conocida para representar la primera y segunda interfases de usuario secundarias 406 a - b dentro de la interfase de usuario primaria 402 correspondiente a las primera y segunda válvulas 308 y 310 de la distribución de planta 306. Tal como se ha descrito en relación con la figura 3, cada interfase de usuario secundaria 406 a - b está soportada por una instancia separada de la aplicación secundaria 210. En muchas implementaciones típicas de FDT, la aplicación Marco FDT (es decir, la aplicación primaria 206) proporciona una ventana o marco 408 dentro de la cual un solo DTM (es decir, una de las aplicaciones secundarias 210) puede representar el contenido (es decir, la interfase de usuario secundaria 406a ). Por consiguiente, la figura 4A ilustra la visualización conocida 400 con la primer interfase de usuario secundaria 406a siendo representada dentro del marco 408 de la interfase de usuario primaria 402, mientras que la figura 4B ilustra la visualización conocida 400 de la figura 4A con la segunda interfase de usuario secundaria 406b siendo representada dentro del marco 408 de la interfase de usuario primaria 402.
[0041] Si bien generalmente no se hace en la industria, una aplicación de Marco FDT podría ser adaptada para proporcionar espacio separado en la pantalla para el contenido de múltiples DTM simultáneamente. Por ejemplo, la interfase de usuario primaria 402 podría habilitarse para representar ambas interfases de usuario secundarias 406 a - b al mismo tiempo. Como tal, aunque sólo una de las interfases de usuario secundarias 406 a - b se exhibe a la vez, ambas instancias de la aplicación secundaria 210 están todavía completamente instanciadas e interactuando con la aplicación primaria 206 al mismo tiempo. En particular, la aplicación primaria 206 (figura 2) y cada instancia de la aplicación secundaria 210 interactúan mediante un marco de aplicación de interfases descrito anteriormente para pasar información entre las aplicaciones, incluyendo las interfases de usuario secundarias 406 a - b generadas mediante las instancias correspondientes de la aplicación secundaria 210 que se representarán dentro del marco 408 de la interfase de usuario primaria 402. Cada instancia de la aplicación secundaria 210 que se exhibe en las Figuras 4A y 4B interactúa de forma independiente con la aplicación primaria 206. En consecuencia, cada instancia de la aplicación secundaria 210 en la figura 4 ejecuta los mismos componentes funcionales centrales 410 y los mismos componentes de interfase de usuario 412 para llevar a cabo las tareas solicitadas y generar las primera y segunda interfases de usuario secundarias 406 a - b correspondientes a cada una de las válvulas seleccionadas 308 y 310.
[0042] Para habilitar las primera y segunda interfases de usuario secundarias 406 a -b a ser representadas dentro de la interfase de usuario primaria 402, cada instancia de la aplicación secundaria 210 en el software de arquitectura conocido 404 pueden tener componentes que interactúan con una aplicación 414 que contiene códigos estandarizados que cumplen con un marco de aplicación de interfases (por ejemplo, la tecnología FDT) para establecer una interfase entre cada instancia de la aplicación secundaria 210 y la aplicación primaria 206. Al hacerlo de esta manera, cada instancia de la aplicación secundaria 210 puede recibir solicitudes de la aplicación primaría 206 y proporcionar la correspondiente salida (por ejemplo, las interfases de usuario secundarias 406 a - b) para ser incrustadas dentro de la interfase de usuario primaria 402. Del mismo modo, la aplicación primaria 206 puede contener códigos normalizados definidos por el marco de aplicación de interfases para comunicar las solicitudes a la aplicación secundaria 210 y proporcionan el marco 408 dentro de la interfase de usuario primaria 402 en donde se puede representar la salida de la aplicación secundaria 210. Más particularmente, parte de la relación de interfase que se establece entre las aplicaciones primaria y secundaria 206 y 210 incluye un puntero, tal como una manija u otro puntero inteligente, suministrado por la aplicación primaria 206 que apunta a la ubicación del marco 408 de tal manera que la aplicación secundaria 210 puede pasar directamente el contenido que se representa en la interfase de usuario primaria 402 mediante el puntero. Además del contenido de gráficos que se puede visualizar dentro del marco 408, las interfases de usuario secundarias 406 a - b pueden contener botones 416 y/o otros elementos interactivos para permitir a los operadores y/o ingenieros interactuar con el contenido representado dentro del marco 408 de la interfase de usuario primaria 402.
[0043] La figura 5 ilustra un ejemplo de arquitectura de software 500 que puede ser utilizado para generar la visualización 400 de las Figuras 4A y 4B. Si bien la visualización 400 en la figura 5 es la misma que la visualización 400 en la figura 4A en donde la primer interfase de usuario secundaria 406a se representa dentro del marco 408 de la interfase de usuario primaria 402, la arquitectura de software subyacente 500 es diferente.
[0044] A diferencia de la arquitectura de software conocida 404 de las figuras 4A y 4B, en donde cada instancia de la aplicación secundaria 210 es una aplicación unitaria completamente instanciada, las primera y segunda instancias de la aplicación secundaria 210 dentro de la arquitectura de software de ejemplo 500 se separan en primera y segunda instancias de una porción de aplicación de cliente 212 (que corresponde a las primera y segunda válvulas 308 y 310) y una única instancia de una parte de la aplicación de servidor 214 que sirve a ambas instancias de la aplicación de cliente 212. Tal como se ilustra, cada instancia de la aplicación de cliente 212 contiene los componentes de la aplicación de interfases 414 para la interfase con la aplicación primaria 206 (figura 2) de la misma manera como las aplicaciones unitarias secundarias 210 de las Figuras 4A y 4B. En el ejemplo ilustrado, la aplicación de servidor 214 puede contener los componentes funcionales 410 y la lógica de negocio relacionada de la aplicación secundaria 210 para ejecutar cualquier tarea (por ejemplo, calibración, configuración, diagnóstico, etc.) asociada con la primera y segunda válvulas 308 y 310. Más aun, la aplicación de servidor 214 puede contener los componentes de la interfase de usuario 412 de la aplicación secundaria 210 para generar el contenido para la primera y segunda interfases de usuario secundarias 406 a - b en base a, entre otras cosas, los resultados de los cálculos u otras tareas realizadas por los componentes funcionales 410. Si bien la aplicación de servidor 214 se muestra conteniendo todos los componentes de interfase de usuario 412 y los componentes funcionales 410 de la aplicación secundaria 210, en otros ejemplos los componentes de la aplicación secundaria 210 pueden estar divididos entre la aplicación de servidor 214 y la aplicación de cliente 212 de cualquier manera adecuada.
[0045] Tal como se ha expuesto anteriormente, hay dos instancias de la aplicación de cliente 212, pero sólo una instancia de la aplicación de servidor 214. Por lo tanto, a diferencia de la arquitectura de software 404 conocida que se muestra en la figura 4, en donde los componentes funcionales 410 se instancian múltiples veces en cada instancia separada de la aplicación secundaria 210, los componentes funcionales 410 en la arquitectura de software de ejemplo 500 de la figura 5 instancian una sola vez para servir a ambas instancias de la aplicación de cliente 212 y realizar la configuración, calibración, diagnóstico, y/o otras tareas que corresponden a las primera y segunda válvulas 308 y 310. De manera similar, si bien el software de arquitectura conocida 404 que se muestra en la figura 4 crea instancias de los componentes de la interfase de usuario 412 múltiples veces en cada instancia de la aplicación secundaria 210, en el ejemplo ilustrado de la figura 5, la aplicación de servidor 214 instancia una única instancia de los componentes de la interfase de usuario 412 a servir a ambas instancias de la aplicación de cliente 212.
[0046] Colocando los componentes funcionales centrales y/o los componentes centrales de la interfase de usuario dentro de la única instancia de la aplicación de servidor 214, la huella de memoria de la aplicación de cliente 212 se puede reducir significativamente. Por ejemplo, cuando el operador y/o ingenieros desean realizar diagnósticos, configuraciones, calibraciones, etc., para dispositivos particulares, pueden invocar la aplicación secundaria de ejemplo 210 asociada con los dispositivos de interés mediante la aplicación primaria 206 como antes. Sin embargo, en el ejemplo revelado, en donde los dispositivos de interés tienen una aplicación secundaria común 210, sólo la porción de la aplicación de cliente 212 de la aplicación secundaria 210 se instancia para cada dispositivo, mientras que una única aplicación de servidor 21 se instancia para servir a ambas instancias de la aplicación de cliente 212. De esta manera, aunque todavía hay dos instancias de la aplicación de cliente 212 (cada una conteniendo los mismos componentes de aplicación de interfase 414), los componentes de interfase de usuario y funcionales 410 y 412 contenidos dentro de la aplicación de servidor 214 se instancian una sola vez, evitando de esta manera la duplicación de estos componentes. Más aun, los componentes de interfase de usuario y funcionales 410 y 412 típicamente comprenden la mayor parte de la aplicación secundaria 210. Como resultado de ello, la huella global de la memoria de la arquitectura de software de ejemplo 500 es casi de la mitad del tamaño de la cantidad de memoria utilizada por la arquitectura de software conocida 404 descrita en la figura 4, dado que la aplicación de servidor 214 es instanciada una sola vez y las dos instancias de la aplicación de cliente 212 son relativamente finas (es decir, tienen una huella de memoria relativamente pequeña).
[0047] Además, el espacio de memoria almacenada es aún más aparente cuando instancias adicionales de la aplicación de cliente 212 se instancian mas allá de la primera y segunda instancias, ya que los mismos pueden también compartir la misma aplicación de servidor 214. De esta manera, tres instancias de ejemplo de la aplicación de cliente 212 puedan todas compartir una única aplicación de servidor 214, lo que significa que la huella total de memoria es de casi un tercio de la huella de memoria de tres instancias completas de la aplicación secundaria 210 implementada de acuerdo con el software de arquitectura conocido 404 descrito en la figura 4. En consecuencia, la arquitectura de software de ejemplo 500 que se describe en la presente memoria puede ventajosamente reducir la huella de memoria de múltiples instancias de las aplicaciones secundarias 210, liberando de esta manera memoria para otras aplicaciones, incrementando la eficiencia del sistema, y/o reduciendo los costos reduciendo los requisitos totales de memoria para ejecutar las aplicaciones deseadas.
[0048] Tal como se describe anteriormente, cada instancia de la aplicación de cliente 212 interactúa con la aplicación primaria 206 mediante el establecimiento de una interfase entre las aplicaciones primarias y del cliente 206 y 212 basado en cualquier marco de aplicación de interfases apropiado. En la medida en que los componentes que interactúan con una aplicación 414 de las primera y segunda instancias de la aplicación de cliente 212 de la figura 5 son los mismos que los componentes que interactúan con una aplicación 414 de las primera y segunda instancias de la aplicación secundaria 210 de la figura 4, la interfase entre las aplicaciones primarias y del cliente 206 y 212 es la misma que la interfase entre las aplicaciones primarias y secundarias 206 y 210 descrita anteriormente en relación con la figura 4. En consecuencia, desde la perspectiva de la aplicación primaria 206, no hay ninguna diferencia funcional entre la arquitectura conocida 404 descrita en las figuras 4A y 4B y la arquitectura de software de ejemplo 500 que se muestra en la figura 5. Como resultado, los desarrolladores de software de la aplicación primaria 206 pueden implementar la arquitectura de software de ejemplo 500 sin alterar sus productos de software siempre que la aplicación primaria 206 ya se halla ajustada a los estándares de los marcos de interfases aplicaciones para establecer una relación entre la aplicación primaria 206 y la aplicación de cliente 212. Más aun, la aplicación primaria 206 puede todavía interactuar con aplicaciones secundarias unitarias 210 (tal como se describe en la figura 4) correspondientes a los dispositivos que no implementan la arquitectura de software de ejemplo 500 se describe en la presente memoria.
[0049] Además de la interfase de la primera y segunda instancia de la aplicación de cliente 212 con la aplicación primaria 206, la primera y segunda instancia de la aplicación de cliente 212 también se interfasa con la aplicación de servidor 214. En algunos ejemplos, las aplicaciones de cliente y de servidor 212 y 214 se comunican y/o interactúan de la misma manera que las aplicaciones primaria y del cliente 206 y 212 se comunican y/o interactúan tal como se describe anteriormente. Esto es, la aplicación de servidor 214 también puede contener un código estandarizado similar a los componentes que interactúan con una aplicación 414 de las instancias de la aplicación de cliente 212 que se ajusta a la estructura del marco de interfase de aplicaciones que las aplicaciones están implementando para permitir que cada aplicación reconozca, instancie, y/o interactúe con los componentes de la otra. Como resultado de ello, la aplicación primaria 206 y la aplicación de servidor 214 se pueden comunicar y/o interactuar indirectamente mediante una de las instancias de la aplicación de cliente 212 pues la aplicación de cliente 212 interfasa con tanto la aplicación primaria 206 y la aplicación de servidor 214. En algunos ejemplos, la aplicación de cliente 212 puede proporcionar poco más que una funcionalidad de paso a través entre la aplicación primaria 206 y la aplicación de servidor 212. Por ejemplo, cuando la aplicación primaria 206 proporciona el puntero a una de las instancias de la aplicación de cliente 212, la instancia de la aplicación de cliente 212 puede compartir el puntero con la aplicación de servidor 214. De esta manera, como la aplicación de servidor 214 calcula datos o de otra manera determina el contenido que se ha de representar dentro de la interfase de usuario primaria 208, el contenido se transmite desde la aplicación de servidor 214 mediante el puntero compartido por la aplicación de cliente 212 directamente al marco 408 interfase de usuario primaria 402. De manera similar, cuando se solicitan datos, gráficos, y/u otras tareas mediante la interfase de usuario primaria 206 con respecto a un dispositivo específico, la correspondiente aplicación de cliente 212 puede compartir las solicitudes con la aplicación de servidor 214 que contiene los componentes funcionales y/o de usuario de la interfase para proporcionar y/o ejecutar los datos, gráficos, y/u otras tareas solicitadas.
[0050] Aunque la discusión anterior de la arquitectura de software de ejemplo 500 puede ser implementada de acuerdo con las normas de FDT, la interfase entre las aplicaciones primarias y del cliente 206 y 212, como así también la interfase entre las aplicaciones de cliente y de servidor 212 y 214 pueden estar basadas sobre cualquier otro marco de interfases adecuado que estandariza la manera cómo ¡nteractúan los componentes de las aplicaciones de software. En particular, la interacción de las aplicaciones de software habilitadas por el marco de interfases puede incluir determinar la presencia y/o la disponibilidad de los objetos / componentes de otra aplicación de software, determinar las capacidades de los objetos / componentes de la otra aplicación de software, instanciar los objetos / componentes de la otra aplicación de software, establecer comunicaciones con otros objetos / componentes de la otra aplicación de software (intercomunicaciones) y/o establecer comunicaciones con otros objetos / componentes de la misma aplicación de software (intracomunicaciones), etc.
[0051] Las figuras 6A - 6C ilustran ejemplos de arquitecturas de espacio de proceso 600 y 602 para implementar la arquitectura de software 500 de la figura 5. En particular, la figura 6A ilustra un ejemplo de arquitectura de único usuario / único proceso 600, La figura 6B ilustra un ejemplo de arquitectura multi usuario / multi proceso 602 con un ejemplo de arquitectura de servidor fuera del proceso 604, y la figura 6C ilustra un ejemplo alternativo de arquitectura de servidor fuera del proceso 606 que puede ser implementado dentro de la arquitectura de espacio de proceso 602 de la figura 6B.
[0052] Volviendo en detalle a la figura 6A, en la misma se ilustra un único espacio de proceso primario 608 para ejecutar una instancia de la aplicación primaria 206 de la figura 2. En el ejemplo ilustrado, la aplicación primaria 206 ha invocado múltiples instancias de la aplicación de cliente 212 de acuerdo con la arquitectura de software de ejemplo 500 de la figura 5. Además, el espacio de proceso primario 600 de la figura 6A también contiene la aplicación de servidor 214 para servir a las múltiples instancias de la aplicación de cliente 212. Si bien en el ejemplo ilustrado se muestran tres instancias de la aplicación de cliente 212, se puede invocar cualquier cantidad adecuada de instancias de la aplicación de cliente 212 mediante la aplicación primaria 206.
[0053] La figura 66 ilustra el ejemplo de arquitectura multi usuario / multi proceso 602 que tiene dos espacios de proceso primario 608 separados, cada uno ejecuta una instancia de la aplicación primaria 206. Tal como se muestra, la arquitectura multi usuario / multi proceso 602 contiene también la arquitectura de servidor fuera del proceso 604 de ejemplo, en donde la aplicación de servidor 214 se ejecuta en un espacio de proceso de servidor 610 que está separado de los espacios de proceso primario 608. Si bien se muestran sólo dos instancias de la aplicación primaria 206, cualquier cantidad adecuada de aplicaciones primarias 206 pueden ser implementadas por la arquitectura multi cliente / multi proceso 602 descrita en la presente memoria. De manera similar, si bien se muestra sólo un proceso de arquitectura de servidor 604, se puede implementar cualquier cantidad adecuada de espacios de proceso de servidor 610 que contienen espacios de servidor independientes 214.
[0054] La distinción principal entre las figuras 6A y 6B es que la aplicación de servidor 214 en la figura 6B puede ser un archivo ejecutable independiente (EXE) para ser ejecutado fuera de proceso en el espacio de proceso del servidor 612, mientras que la aplicación de servidor 214 en la figura 6A puede ser un archivo de biblioteca de vínculos dinámicos ("dynamic link librar/) (DLL, por sus siglas en inglés) para ser ejecutado dentro del proceso con la aplicación primaria 206. En otros aspectos, las arquitecturas de espacio de proceso 600 y 602 y las diferentes aplicaciones funcionan de la misma manera. Por ejemplo, independientemente de la arquitectura de espacio de proceso (ya sea de acuerdo con la figura 6A o la figura 6B), cada una de las una o más instancias de la aplicación primaria 206, cada una de las una o más instancias de la aplicación de cliente 212, y cada una de las una o más instancias de la aplicación de servidor 214 establecen relaciones de inferíase para comunicarse y/o interactuar de la misma manera como se ha descrito anteriormente con relación a las figuras 4 y 5.
[0055] Las diferentes arquitecturas de espacio de proceso 600 y 602 proporcionan diferentes ventajas que se pueden utilizar dependiendo de la aplicación particular y las circunstancias en donde las arquitecturas de espacio de proceso 600 y 602 se llevarán a cabo. Por ejemplo, la arquitectura multi usuario / multi proceso 600 de ejemplo de la figura 6A es ventajosamente ejecutada dentro de un espacio de proceso único para mejorar el rendimiento de la comunicación entre las aplicaciones primaria y del cliente 206 y 212 pues están en el mismo espacio de proceso (es decir, el espacio de proceso primario 608). Sin embargo, si la aplicación de servidor 214 de la arquitectura 600 de ejemplo de la figura 6A presenta un mal funcionamiento, la aplicación primaria 206 también presentará un mal funcionamiento debido a que están en el mismo espacio de proceso (es decir, el espacio de proceso primario 608). En contraste, la arquitectura multi usuario / multi proceso 602 de ejemplo de la figura 6B alivia este problema colocando la aplicación de servidor 214 en su propio espacio de proceso. En consecuencia, si la aplicación de servidor 214 presenta un mal funcionamiento cuando se implementa en la arquitectura multi usuario / multi proceso 602, no interrumpirá las aplicaciones primarias 206 debido a que se están ejecutando en espacios de proceso separados (es decir, los espacios de proceso primarios 608). Más aun, una ventaja de la arquitectura multi cliente / multi proceso 602 es que la aplicación de servidor 214 puede servir a múltiples usuarios (por ejemplo, estaciones de operador 104 separadas que se describe en las figuras 1 y/o 2).
[0056] La figura 6C ilustra un ejemplo alternativo de arquitectura de servidor fuera del proceso 606 que se puede implementar dentro de la arquitectura multi cliente / multi proceso 602 de la figura 6B. Tal como se ilustra, la aplicación de servidor 214 puede ser un archivo DLL colocado dentro de un envoltorio ejecutable (por ejemplo, el envoltorio de aplicación de servidor 612). De esta manera, la aplicación de servidor 214, como un archivo DLL, se ejecuta dentro del proceso con el envoltorio de aplicación de servidor 612, mientras que el envoltorio de aplicación de servidor 612 (un archivo EXE) se ejecuta fuera de proceso con respecto a los espacios de proceso primarios 608 que se muestran en la figura 6C en el espacio de proceso de servidor separado 610. De esta manera, tanto la arquitectura único usuario / único proceso 600 de la figura 6A y la arquitectura multi cliente / multi proceso 602 de la figura 6B se pueden implementar con una aplicación de servidor 214 que tiene el mismo formato de archivo (es decir, un DLL) colocando la aplicación de servidor 214 dentro del envoltorio de aplicación de servidor 612 para la arquitectura multi cliente / multi proceso 602.
[0057] La figura 7 es un diagrama de flujo representativo de un proceso de ejemplo que puede ser llevado a cabo para implementar la arquitectura de software de ejemplo 500 de la figura 5, las arquitecturas de espacio de proceso de ejemplo 600 y 602 de las figuras 6A - 6C, y/o, más en general, la estación de operador de ejemplo de la figura 1 y/o 2. Más particularmente, el proceso de ejemplo de la figura 7 puede ser representativo de las instrucciones legibles por máquina que comprenden un programa para su ejecución por un procesador tal como el procesador 812 que se muestra en la computadora de ejemplo 800 tratado a continuación en relación con la figura 8. El programa puede estar incrustado en forma de software almacenado sobre un medio tangible legible por computadora tal como un CD-ROM, un disquete, un disco duro, un disco versátil digital (DVD), un disco BluRay, o una memoria asociada con el procesador 812. Alternativamente, algunos o todos los procesos de ejemplo de la figura 7 pueden ser implementados utilizando cualquier combinación (es) circuito (s) integrado (s) específico (s) de aplicación (es) (ASIC, por sus siglas en inglés), dispositivo (s) lógico (s) programable (s) (PLD, por sus siglas en inglés), dispositivo (s) de campo lógico (s) programable (s) (FPLD, por sus siglas en inglés), lógica discreta, hardware, firmware, etc. Además, una o más de las operaciones de ejemplo de la figura 7 puede ser implementada manualmente o como cualquier combinación (es) de cualquiera de las técnicas anteriores, por ejemplo, cualquier combinación de "firmware", software, lógica discreta y/o hardware. Más aun, aunque el proceso de ejemplo se describe con referencia al diagrama de flujo ilustrado en la figura 7, se puede usar alternativamente muchos otros métodos de implementar la arquitectura de software de ejemplo 500 de la figura 5, las arquitecturas de de espacio de proceso de ejemplo 600 y 602 de las figuras 6A- 6C, y/o la estación de operador de ejemplo 104 de la figura 1 y/o 2. Por ejemplo, el orden de ejecución de los bloques se puede modificar y/o algunos de los bloques descritos se pueden modificar, eliminar o combinar. Además, cualquiera o todos los procesos de ejemplo de la figura 7 se pueden llevar a cabo de forma secuencial y/o en paralelo por, por ejemplo, sub procesos de procesamiento separados, procesadores, dispositivos, lógica discreta, circuitos, etc.
[0058] Tal como se mencionó anteriormente, el proceso de ejemplo de la figura 7 puede ser implementado usando instrucciones codificadas (por ejemplo, instrucciones legibles por computadora) almacenadas sobe un medio tangible legible por computadora tal como una unidad de disco duro, una memoria flash, una memoria de sólo lectura (ROM), un disco compacto (CD), un disco versátil digital (DVD), una memoria caché, una memoria de acceso aleatorio (RAM) y/o cualquier otro medio de almacenamiento en donde se almacena la información por cualquier duración (por ejemplo, durante períodos de tiempo prolongados, de forma permanente, instancias breves, de forma de un tampón temporal, y/o para el almacenamiento en caché de la información). Tal como se usa en la presente, el término medio tangible legible por computadora está expresamente definido para incluir cualquier tipo de almacenamiento legible por computadora y para excluir señales que se propagan.
Adicional o alternativamente, el proceso de ejemplo de la figura 7 puede ser implementado usando instrucciones codificadas (por ejemplo, instrucciones legibles por computadora) almacenadas sobre un medio informático legible no transitorio tal como una unidad de disco duro, una memoria flash, una memoria de sólo lectura, un disco compacto, un disco versátil digital, un caché, una memoria de acceso aleatorio y/o cualquier otro medio de almacenamiento en donde se almacena la información por cualquier duración (por ejemplo, durante períodos de tiempo prolongados, de forma permanente, instancias breves, para almacenamiento en búfer temporal, y/o para el almacenamiento en caché de la información). Tal como se utiliza en la presente, el término medio legible por computadora no transitorio está definido expresamente para incluir cualquier tipo de medio legible por computadora y para excluir señales que se propagan. Tal como se usa en la presente memoria, cuando se utiliza la frase "al menos" como el término de transición en un preámbulo de una reivindicación, es abierto de misma manera que el término "comprende" es abierto. Por lo tanto, una reivindicación que usa "al menos" como el término de transición en su preámbulo puede incluir elementos además de los expresamente recitados en la reivindicación.
[0059] El proceso de ejemplo de la figura 7 comienza en el bloque 700 en donde la aplicación secundaria 210 (figura 2) recibe la (s) solicitud (es) desde la aplicación primaria 206 (figura 2) para ejecutar componente (s) de la aplicación secundaria 210. Tal como se muestra en el ejemplo ilustrado de la figura 2, la aplicación secundaria 210 incluye una porción de aplicación de cliente 212 y una porción de aplicación de servidor 214. Además, los componentes funcionales centrales 410 (figura 5) y/o los componentes centrales de interfase de usuario 412 (figura 5) de la aplicación secundaria 210 pueden estar dentro de la aplicación de servidor 214, mientras que los componentes de interfases de aplicaciones 414 (figura 5) pueden estar dentro de la instancia de la aplicación de cliente 212 para interactuar con la aplicación primaria 206. En consecuencia, en el bloque 702 se establece una interfase entre la aplicación primaria 206 y la (s) instancia (s) de la aplicación de cliente 212. En particular, una instancia de la aplicación de cliente 212 se instancia en la memoria 202 (figura 2) cuando es invocada por la aplicación primaria 206. La instancia de la aplicación de cliente 212 y de la aplicación primaria 206 establecen una relación mediante los componentes de interfases de aplicación 414 dentro de la aplicación de cliente 212 y componentes de interfases de aplicación correspondiente en la aplicación primaria 206. Entre otras cosas, la aplicación primaria 206 puede proporcionar a la aplicación de cliente 212 con un puntero a marco 408 (figura 5) dentro de la interfase de usuario primaria 402 en donde una interfase de usuario secundaria correspondiente (por ejemplo, las interfases de usuario secundarias 406 a - b de la figura 5) de la aplicación secundaria 210 puede ser representada.
[0060] Para ejecutar el (los) componente (s) solicitado (s) por la aplicación primaria 206, la instancia de la aplicación de cliente 212 puede tratar de establecer una conexión con la aplicación de servidor 214, pues la aplicación de servidor 214 contiene el (los) componente (s) solicitado (s). Para ello, el proceso de la figura 7 determina si la aplicación de servidor 214 ya ha creado una instancia para otra instancia de la aplicación de cliente 212 (bloque 704). Si la aplicación de servidor 214 no ha sido invocada por cualquier otra instancia de la aplicación de cliente 212, la aplicación de servidor se instancia (bloque 706). Una vez que la aplicación de servidor 214 se instancia, la aplicación de cliente 212 establece una interfase con la aplicación de servidor 214 (bloque 708). Sin embargo, si durante el proceso de ejemplo de la figura 7 se determina que la aplicación de servidor 214 ya se ha instanciado (bloque 704), el control avanza directamente al bloque 708, en donde la instancia de la aplicación de cliente 212 establece una interfase con la aplicación de servidor 214 ya instanciada. La interfase entre la instancia de la aplicación de cliente 212 y la aplicación de servidor 214 es similar a la interfase entre la aplicación de cliente 212 y la aplicación primaria 206. Es decir, la aplicación de cliente 212 se conecta con la aplicación de servidor 214 mediante los componentes de interfases de aplicaciones 414 de la aplicación de cliente 212 y los correspondientes componentes de interfases dentro de la aplicación de servidor 214. La aplicación de servidor 214 puede servir entonces la instancia de la aplicación de cliente, junto con cualquiera otras instancias de la aplicación de cliente 212 que ya han establecido una interfase con la aplicación de servidor 214.
[0061] En el bloque 710, la instancia de la aplicación de cliente 212 puede compartir el puntero, recibido desde la aplicación primaria, con la aplicación de servidor. De esta manera, el contenido de la interfase de usuario secundaria (por ejemplo, las interfases de usuario secundarias 406 a - b de la figura 5) correspondiente a la instancia de la aplicación de cliente 212 puede ser enviado directamente al marco 408 de la interfase de usuario primaria 210. El proceso de ejemplo de la figura 7 avanza luego al bloque 712 en donde la aplicación de servidor 214 genera la interfase de usuario secundaria asociada a la instancia de la aplicación de cliente 212 que la aplicación de servidor 214 está sirviendo. La aplicación de servidor 214 puede determinar los datos para generar la interfase de usuario secundaria ejecutando cualquiera o todos los componentes funcionales 410 contenidos dentro de la aplicación de servidor 214 y/o cualquiera o todos los componentes de la interfase de usuario 412 contenidos dentro de la aplicación de servidor 214. La aplicación de servidor 214 puede determinar también el contenido de la interfase de usuario secundaria en base a los ingresos de usuario adicionales realizados mediante la interfase primaria de usuario 206. La aplicación de servidor 214 envía la interfase de usuario secundaria generada asociada con la instancia de la aplicación de cliente 212 a la aplicación primaria 206 mediante el puntero compartido por la instancia de la aplicación de cliente (bloque 714). Una vez que la interfase de usuario secundaria se proporciona a la aplicación primaria 206, la aplicación primaria 206 puede representar la interfase de usuario secundaria dentro del marco 408 de la interfase de usuario primaria 208.
[0062] El proceso de ejemplo de la figura 7 determina a continuación si la instancia de la aplicación de cliente 212 ha terminado de utilizar la aplicación de servidor 212 (bloque 716). Si la instancia de la aplicación de cliente 212 sigue utilizando la aplicación de servidor 214, el control vuelve a los bloques 712 y 714, en donde la aplicación de servidor 214 continúa generando la interfase de usuario secundaria para la instancia de la aplicación de cliente 212. Sin embargo, si la instancia de la aplicación de cliente 212 ha terminado de utilizar la aplicación de servidor 214, la interfase entre la aplicación de cliente 212 y la aplicación de servidor 214 se suspende (bloque 718). El proceso de ejemplo de la figura 7 determina entonces si otras instancias de la aplicación de cliente 212 todavía están en interfase con la aplicación de servidor 214 (bloque 720). Si es así, el control vuelve a los bloques 712 y 714 para que la aplicación de servidor 214 continúe sirviendo la (s) otra (s) instancia (s) de la aplicación de cliente 212. Si ninguna otra instancia de la aplicación de cliente 212 está usando la aplicación de servidor, el control avanza al bloque 722, en donde el proceso de ejemplo determina si se deben esperar nuevas solicitudes de la aplicación primaria 206 para ejecutar el (los) componente (s) de la aplicación secundaria 210. Si es así, el control vuelve al bloque 700 en donde el proceso de ejemplo de la figura 7 se pueden repetir. Si el proceso de la figura 7 determina no esperar a solicitudes adicionales de la aplicación primaria 206, entonces el proceso termina.
[0063] La figura 8 es una ilustración esquemática de un ejemplo de computadora 800 que puede ser utilizada y/o programada para llevar a cabo el proceso de ejemplo de la figura 7 y/o, más en general, para implementar la arquitectura de software 500 de la figura 5, las arquitecturas de espacio de proceso 600 y 602 de ejemplo de las Figuras 6A - 6C, y/o la estación de operador 104 de ejemplo de la figura 1 y/o 2. El sistema 800 del presente ejemplo incluye un procesador 812. Por ejemplo, el procesador 812 se puede implementar por uno o más microprocesadores o controladores de cualquier familia o fabricante deseados.
[0064] El procesador 812 incluye una memoria local 813 (por ejemplo, una memoria caché) y está en comunicación con una memoria principal que incluye una memoria volátil 814 y una memoria no volátil 816 mediante un bus 818. La memoria volátil 814 se puede implementar por una Memoria Síncrona y Dinámica de Acceso Aleatorio (SDRAM, por sus siglas en inglés), una Memoria Dinámica de Acceso Aleatorio (DRAM, por sus siglas en inglés), una Memoria Dinámica de Acceso Aleatorio RAMBUS (RDRAM, por sus siglas en inglés) y/o cualquier otro tipo de dispositivo de memoria de acceso aleatorio. La memoria no volátil 816 se puede implementar por la memoria flash y/o cualquier otro tipo de dispositivo de memoria deseado. El acceso a la memoria principal 814 y 816 se controla mediante un controlador de memoria.
[0065] La computadora 800 también incluye un circuito de interfase 820. El circuito de interfase 820 se puede implementar por cualquier tipo de estándar de interfase, tal como una interfase Ethernet, un bus serial universal (USB), y/o una interfase PCI express. Uno o más dispositivos de entrada 822 están conectados al circuito de interfase 820. El (los) dispositivo (s) de entrada 822 permite (n) a un usuario introducir datos y comandos al procesador 812. El (los) dispositivo (s) de entrada se puede (n) implementar mediante, por ejemplo, un teclado, un ratón, una pantalla táctil, una pista de contacto ("track-pad"), una bola de seguimiento ("trackbalf), "isopoint" y/o un sistema de reconocimiento de voz. Uno o más dispositivos de salida 824 también están conectados al circuito de interfase 820. Los dispositivos de salida 824 se pueden implementar, por ejemplo, mediante dispositivos de visualización (por ejemplo, un visualizador de cristal líquido, un visualizador de tubo de rayos catódicos (CRT), una impresora y/o altavoces). El circuito de interfase 820, por lo tanto, típicamente incluye una tarjeta de controlador de gráficos.
[0066] El circuito de interfase 820 también incluye un dispositivo de comunicación, tal como un módem o una tarjeta de interfase de red para facilitar el intercambio de datos con computadoras externas mediante una red 826 (por ejemplo, una conexión Ethernet, una línea de abonado digital (DSL), una línea telefónica, un cable coaxial, un sistema telefónico celular, etc.)
[0067] La computadora 800 también incluye uno o más dispositivos de almacenamiento masivo 828 para almacenar software y datos. Ejemplos de tales dispositivos de almacenamiento masivo 828 incluyen unidades de disquete, unidades disco duro, unidades de discos compactos y unidades de discos versátiles digitales (DVD).
[0068] Las instrucciones codificadas 832 para implementar el proceso de ejemplo de la figura 7 se pueden almacenar en el dispositivo de almacenamiento masivo 828, en la memoria volátil 814, en la memoria no volátil 816, y/o sobre un medio de almacenamiento extraíble, tal como un CD o un DVD.
[0069] Aunque determinados métodos, aparatos y artículos de fabricación de ejemplo se han descrito en la presente memoria, el alcance de cobertura de esta patente no se limita a los mismos. Tales ejemplos tienen por objeto ser ejemplos ilustrativos no limitativos. Por el contrario, esta patente cubre todos los métodos, aparatos y artículos de fabricación que entran dentro del alcance de las reivindicaciones adjuntas, ya sea literalmente o bajo la doctrina de equivalentes.

Claims (22)

REIVINDICACIONES Lo que se reivindica es:
1. Un aparato, que comprende: un espacio de proceso primario para ejecutar una aplicación primaria para ser usado en un sistema de control de procesos; una interfase de usuario primaria asociada con la aplicación primaria y para ser representada en un visualizador; una aplicación secundaria para ser invocada mediante la aplicación primaria, la aplicación secundaria comprende: una aplicación de cliente para habilitar la interacción entre la aplicación primaria y la aplicación secundaria, y una aplicación de servidor que sirve a la aplicación de cliente para implementar al menos un componente de software para generar una interfase de usuario secundaria asociada con la aplicación secundaria, en donde la interfase de usuario secundaria se ha de comunicar a la aplicación primaria para ser representada dentro de la interfase de usuario primaria.
2. Un aparato tal como se describe en la reivindicación 1 , en donde la aplicación primaria es proporcionar a la aplicación de cliente con un puntero a una porción de la interfase de usuario primaria, y en donde la aplicación de cliente es compartir el puntero con la aplicación secundaria para permitir que la aplicación secundaria comunique la interfase de usuario secundaria a la aplicación primaria.
3. Un aparato tal como se describe en la reivindicación 1 , en donde la aplicación primaria es una aplicación de software de gestión de procesos, y en donde la aplicación secundaria está asociada con un dispositivo específico en el sistema de control de procesos.
4. Un aparato tal como se describe en la reivindicación 3, en donde el al menos un componente de software a ser implementado por la aplicación de servidor es al menos uno de un componente funcional o un componente de interfase de usuario.
5. Un aparato tal como se describe en la reivindicación 4, en donde el componente funcional corresponde a al menos uno de mantenimiento, calibración, pruebas de fiabilidad, configuración, diagnósticos, comunicaciones, recolección y almacenamiento de datos, correo electrónico, o impresión asociado con el dispositivo en el sistema de control de procesos.
6. Un aparato tal como se describe en la reivindicación 1 , en donde la interacción entre la aplicación primaria y la aplicación secundaria mediante la aplicación de cliente permite a un usuario de la aplicación primaria interactuar con el al menos un componente de software.
7. Un aparato tal como se describe en la reivindicación 1 , en donde las primera y segunda instancias de la aplicación de cliente se han de invocar concurrentemente mediante la aplicación primaria.
8. Un aparato tal como se describe en la reivindicación 7, en donde la aplicación de servidor se ha de instanciar una vez para servir tanto a la primera y segunda instancias de la aplicación de cliente.
9. Un aparato tal como se describe en la reivindicación 1 , en donde la aplicación de servidor se debe ejecutar al menos uno de en proceso o fuera del proceso en relación a la aplicación primaria.
10. Un aparato tal como se describe en la reivindicación 1 , que comprende además: un segundo espacio de proceso primario para ejecutar una segunda instancia de la aplicación primaria; y una segunda instancia de la aplicación de cliente a ser invocada por la segunda instancia de la aplicación primaria, en donde la aplicación de servidor se ha de instanciar una vez para servir tanto a la primera y segunda instancias de la aplicación de cliente.
11. Un aparato tal como se describe en la reivindicación 1 , en donde la interacción entre la aplicación primaria, la aplicación de cliente, y la aplicación de servidor se hace posible por los componentes de interfases de aplicaciones en la aplicación primaria, la aplicación de cliente, y la aplicación de servidor.
12. Un aparato tal como se describe en la reivindicación 11 , en donde los componentes de interfases de aplicaciones se basan en estándares de herramientas de dispositivos de campo
13. Un método, que comprende: recibir una solicitud mediante una interfase de usuario primaria asociada con una aplicación primaria asociada con un sistema de control de procesos para ejecutar al menos un componente de una aplicación secundaria asociada con un dispositivo en el sistema de control de procesos, en donde la aplicación secundaria incluye una aplicación de cliente y una aplicación de servidor, y en donde el al menos un componente es implementado por la aplicación de servidor; instanciar una primer instancia de la aplicación de cliente para habilitar la interacción con la aplicación primaria; instanciar la aplicación de servidor para servir a la aplicación de cliente; generar una interfase de usuario secundaria asociada con la primera instancia de la aplicación de cliente basada sobre el al menos un componente implementado por la aplicación de servidor, y comunicar la interfase de usuario secundaria a la aplicación primaria para la representación en la interfase de usuario primaria.
14. Un método tal como se describe en la reivindicación 13, que comprende además compartir un puntero con la aplicación de servidor, el puntero es proporcionado por la aplicación primaria para la aplicación de cliente, para permitir a la aplicación de servidor comunicar la interfase de usuario secundaria a la aplicación primaria.
15. Un método tal como se describe en la reivindicación 13, que comprende además ejecutar la aplicación de servidor al menos uno de en proceso o fuera del proceso en relación a la aplicación primaria.
16. Un método tal como se describe en la reivindicación 13, en donde el al menos un componente implementado por la aplicación de servidor lleva a cabo al menos uno de generación de interfase de usuario, mantenimiento, calibración, pruebas de fiabilidad, configuración, diagnósticos, comunicaciones, recolección y almacenamiento de datos, correo electrónico, o impresión asociado con el dispositivo en el sistema de control de procesos.
17. Un método tal como se describe en la reivindicación 13, que comprende además instanciar una segunda instancia de la aplicación de cliente asociada con un segundo dispositivo en el sistema de control de procesos, en donde tanto la primera y segunda instancias de la aplicación de cliente han de ser servidas por la aplicación de servidor; generar una segunda interfase de usuario secundaria asociada con la segunda instancia de la aplicación de cliente basada sobre el al menos un componente implementado por la aplicación de servidor, y comunicar la segunda interfase de usuario secundaria a la aplicación primaria para la representación en la interfase de usuario primaria.
18. Un artículo tangible de fabricación de almacenar instrucciones legibles por máquina que, cuando se ejecutan, causan una máquina a al menos: recibir una solicitud mediante una interfase de usuario primaria asociada con una aplicación primaria asociada con un sistema de control de procesos para ejecutar al menos un componente de una aplicación secundaria asociada con un dispositivo en el sistema de control de procesos, en donde la aplicación secundaria incluye una aplicación de cliente y una aplicación de servidor, y en donde el al menos un componente es implementado por la aplicación de servidor; instanciar una primera instancia de la aplicación de cliente para habilitar la interacción con la aplicación primaria; instanciar la aplicación de servidor para servir a la aplicación de cliente; generar una interfase de usuario secundaria asociada con la primera instancia de la aplicación de cliente basada sobre el al menos un componente implementado por la aplicación de servidor, y comunicar la interfase de usuario secundaria a la aplicación primaria para la representación en la interfase de usuario primaria.
19. Un artículo tangible de fabricación tal como se describe en la reivindicación 18, en donde las instrucciones legibles por máquina, cuando se ejecutan, más aun causan que la máquina comparta un puntero con la aplicación de servidor, el puntero siendo proporcionado por la aplicación primaria para la aplicación de cliente, para habilitar que la aplicación de servidor comunique la interfase de usuario secundaria a la aplicación primaria.
20. Un artículo tangible de fabricación tal como se describe en la reivindicación 18, en donde las instrucciones legibles por máquina, cuando se ejecutan, más aun causan que la máquina ejecute la aplicación de servidor al menos uno de en proceso o fuera del proceso en relación a la aplicación primaria.
21. Un artículo tangible de fabricación descrito en la reivindicación 18, en donde el al menos un componente implementado por la aplicación de servidor lleva a cabo al menos una de generación de interfase de usuario, mantenimiento, calibración, pruebas de fiabilidad, configuración, diagnósticos, comunicaciones, recolección y almacenamiento de datos, correo electrónico, o impresión asociado con el dispositivo en el sistema de control de procesos.
22. Un artículo tangible de fabricación tal como se describe en la reivindicación 18, en donde las instrucciones legibles por máquina, cuando se ejecutan, más aun causan a la máquina: instanciar una segunda instancia de la aplicación de cliente asociada con un segundo dispositivo en el sistema de control de procesos, en donde tanto la primera y segunda instancias de la aplicación de cliente han de ser servidas por la instancia de la aplicación de servidor; generar una segunda interfase de usuario secundaria asociada con la segunda instancia de la aplicación de cliente basada sobre el al menos un componente ¡mplementado por la aplicación de servidor, y comunicar la segunda interfase de usuario secundaria a la aplicación primaria para la representación en la interfase de usuario primaria.
MX2014010159A 2012-03-02 2013-03-01 Metodos y aparatos para reducir los requisitos de memoria para aplicaciones de software de sistemas de control de procesos. MX342209B (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/410,607 US9002929B2 (en) 2012-03-02 2012-03-02 Methods and apparatus to reduce memory requirements for process control system software applications
PCT/US2013/028563 WO2013130941A1 (en) 2012-03-02 2013-03-01 Methods and apparatus to reduce memory requirements for process control system software applications

Publications (2)

Publication Number Publication Date
MX2014010159A true MX2014010159A (es) 2014-11-10
MX342209B MX342209B (es) 2016-09-21

Family

ID=47901383

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2014010159A MX342209B (es) 2012-03-02 2013-03-01 Metodos y aparatos para reducir los requisitos de memoria para aplicaciones de software de sistemas de control de procesos.

Country Status (9)

Country Link
US (2) US9002929B2 (es)
EP (1) EP2820538B1 (es)
JP (1) JP6193274B2 (es)
CN (2) CN103294023B (es)
AR (1) AR090202A1 (es)
CA (1) CA2864926C (es)
MX (1) MX342209B (es)
RU (1) RU2634220C2 (es)
WO (1) WO2013130941A1 (es)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9002929B2 (en) * 2012-03-02 2015-04-07 Fisher Controls International Llc Methods and apparatus to reduce memory requirements for process control system software applications
US9628341B2 (en) * 2013-05-31 2017-04-18 Ge Intelligent Platforms, Inc. Incorporating FDT/DTM technology into a native control system monitoring application
US20150309702A1 (en) * 2014-04-07 2015-10-29 Dresser, Inc. Method and system for generating a user interface for device diagnostics of a valve assembly and implementation thereof
US9720396B2 (en) * 2014-05-23 2017-08-01 Fisher-Rosemount Systems, Inc. Methods and apparatus to configure process control systems based on generic process system libraries
KR20150142476A (ko) * 2014-06-12 2015-12-22 삼성전자주식회사 전자장치에서 어플리케이션 실행 화면을 표시하는 방법 및 장치
EP3029535A3 (en) * 2014-12-03 2016-07-13 Rockwell Automation Technologies, Inc. P&ID and control system synchronization
US9465734B1 (en) * 2015-04-08 2016-10-11 Apple Inc. Coalition based memory management
US10719289B2 (en) * 2015-11-05 2020-07-21 Topcon Positioning Systems, Inc. Monitoring and control display system and method using multiple displays in a work environment
JP6876231B2 (ja) * 2016-09-26 2021-05-26 富士フイルムビジネスイノベーション株式会社 画像形成装置及びプログラム
JP6876232B2 (ja) * 2016-09-26 2021-05-26 富士フイルムビジネスイノベーション株式会社 画像形成装置及びプログラム
CN106740115A (zh) * 2017-01-22 2017-05-31 斑马信息科技有限公司 汽车仪表与中控交互系统及方法
WO2020163550A1 (en) * 2019-02-06 2020-08-13 Compressor Controls Corporation Systems and methods for adapting compressor controller based on field conditions
CN112083914B (zh) * 2020-08-31 2023-09-12 深圳航天科技创新研究院 实现对象模型嵌入式操作系统软总线的方法及系统

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07160453A (ja) * 1993-12-13 1995-06-23 Toshiba Corp 画面表示処理方式
AT412131B (de) 1998-11-24 2004-09-27 Automationx Software For Ind A Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu
US7146610B2 (en) * 2003-03-27 2006-12-05 Taiwan Semiconductor Manufacturing Company, Ltd. Method for upgrading software components without system shutdown
DE102004019253A1 (de) 2004-04-16 2005-11-10 Codewrights Gmbh Verfahren zum Fernbedienen eines Feldgerätes der Prozessautomatisierungstechnik
US7117046B2 (en) * 2004-08-27 2006-10-03 Alstom Technology Ltd. Cascaded control of an average value of a process parameter to a desired value
US8782539B2 (en) * 2005-10-05 2014-07-15 Invensys Systems, Inc. Generic utility supporting on-demand creation of customizable graphical user interfaces for viewing and specifying field device parameters
US8464168B2 (en) * 2005-10-05 2013-06-11 Invensys Systems, Inc. Device home page for use in a device type manager providing graphical user interfaces for viewing and specifying field device parameters
US8527888B2 (en) * 2006-04-11 2013-09-03 Invensys Systems, Inc. Method and supporting configuration user interfaces for streamlining installing replacement field devices
US7921375B2 (en) * 2005-12-16 2011-04-05 Microsoft Corporation Integrating user interfaces from one application into another
US7620901B2 (en) * 2006-03-21 2009-11-17 Microsoft Corporation Simultaneous input across multiple applications
DE102007029136A1 (de) * 2007-06-25 2009-01-02 Vega Grieshaber Kg Vorrichtung und Verfahren zum Generieren einer Bedienoberflächenkonfiguration für ein Feldgerät
DE102007035158A1 (de) 2007-07-25 2009-01-29 Endress + Hauser Flowtec Ag Verfahren zum Bedienen eines Feldgerätes der Automatisierungstechnik
US8543741B2 (en) * 2007-08-16 2013-09-24 Fisher Controls International Llc Network scanning and management in a device type manager of type device
US8731895B2 (en) * 2008-05-20 2014-05-20 Honeywell International Inc. System and method for accessing and configuring field devices in a process control system
JP5104673B2 (ja) * 2008-09-03 2012-12-19 横河電機株式会社 機器管理装置及びプログラム
JP5141971B2 (ja) * 2008-09-24 2013-02-13 横河電機株式会社 機器情報表示装置
DE102009028051B4 (de) * 2009-07-28 2023-10-26 Endress + Hauser Conducta Gesellschaft für Mess- und Regeltechnik mbH + Co. KG System zur Bedienung eines Feldgeräts über ein entferntes Terminal
JP5045724B2 (ja) * 2009-10-15 2012-10-10 横河電機株式会社 機器情報設定装置
US20120271962A1 (en) * 2010-10-14 2012-10-25 Invensys Systems Inc. Achieving Lossless Data Streaming in a Scan Based Industrial Process Control System
US9002929B2 (en) * 2012-03-02 2015-04-07 Fisher Controls International Llc Methods and apparatus to reduce memory requirements for process control system software applications

Also Published As

Publication number Publication date
JP2015510204A (ja) 2015-04-02
CN103294023A (zh) 2013-09-11
US20130232186A1 (en) 2013-09-05
US20150163293A1 (en) 2015-06-11
US9621639B2 (en) 2017-04-11
CN203217332U (zh) 2013-09-25
AR090202A1 (es) 2014-10-29
RU2634220C2 (ru) 2017-10-24
EP2820538B1 (en) 2021-08-18
CN103294023B (zh) 2017-11-07
MX342209B (es) 2016-09-21
CA2864926C (en) 2021-03-16
EP2820538A1 (en) 2015-01-07
RU2014138607A (ru) 2016-04-20
CA2864926A1 (en) 2013-09-06
WO2013130941A1 (en) 2013-09-06
US9002929B2 (en) 2015-04-07
JP6193274B2 (ja) 2017-09-06

Similar Documents

Publication Publication Date Title
US9621639B2 (en) Methods and apparatus to reduce memory requirements for process control system software applications
JP5444394B2 (ja) プロセス制御システムと共用するためのカスタム・ファンクション・ブロック
US10037443B2 (en) Industrial simulation using redirected I/O module configurations
US9285795B2 (en) Graphic display configuration framework for unified control system interface
US20190101899A1 (en) I/O Virtualization for Commissioning
US20120232869A1 (en) Industrial simulation using redirected i/o module configurations
EP3002649B1 (en) Industrial simulation using redirected i/o module configurations
JP2018515865A (ja) Opc uaベースのマシンツーマシンネットワークにおけるプラントのプロセス制御のための方法およびシステム
US20120226786A1 (en) System and method for porting of device software
US10551814B2 (en) Generic shadowing in industrial process plants
GB2556694A (en) Alarm handling and viewing support in a process plant
US20150338836A1 (en) Methods and apparatus to configure process control systems based on generic process system libraries
US10805116B2 (en) Gateway and method for connecting a data source system to an IT system
EP2845062B1 (en) Methods and systems to provide update information of a device description of a field instrument
EP2254010A2 (en) Methods and apparatus to conceal portions of a visual object diagram in a process control system
WO2022246647A1 (en) Data interaction method, apparatus and system for ai inference device and automation controller

Legal Events

Date Code Title Description
FG Grant or registration