identificado todos los dispositivos de campo

4
Después de haber identificado todos los dispositivos de campo, a continuación, tendrá que determinar la funcionalidad de cada uno. Identificación de los dispositivos de campo En la identificación de los dispositivos de campo, usted debe comenzar por interpretar el plano de tuberías e instrumentos (P&ID). Típicamente, este diagrama muestra todos los dispositivos de campo y muestra el flujo entre ellos. Si se tiene un P&ID bueno, el proceso de planificación de la aplicación tomará menos tiempo y será más fácil. Debe comprobar que el plano P&ID es correcto y esté al día en cuanto a revisiones antes de comenzar el proceso de planificación. Se prosigue a examinar cada componente en el plano P&ID e identificar cada dispositivo básico que se utiliza. Por ejemplo, una electroválvula puede ser un dispositivo básico. Un motor, sin embargo, puede estar compuesto de múltiples dispositivos básicos. Una vez creada la lista completa, agrupar los productos según el tipo, tales como válvulas, bombas, etc. Consólidar los dispositivos duplicados en tipos comunes de modo que solo una lista de dispositivos básicos únicos restos, y luego documentarlas en la hoja de planificación del proyecto. Cada dispositivo básico se representa dentro del framework ArchestrA IDE como un "objeto". Una instancia de un objeto debe ser derivado de una plantilla definida. El número de tipos de dispositivos en la lista final ayudará a determinar la cantidad de plantillas de objeto tendrá que crear para su aplicación. Puede agrupar varios objetos básicos para crear objetos más complejos, lo cual es un concepto conocido como "contención". Identificación de las necesidades funcionales Para cada dispositivo único, tendrá que definir los requisitos funcionales, que incluyen: 37 Las entradas y salidas. ¿Cuántas entradas se requieren para el dispositivo? ¿Cuántas salidas se requieren? Scripting. ¿Qué scripts estarán vinculados con el dispositivo? Por ejemplo, ¿el dispositivo requieren cálculo indirecto alguno? Historización. ¿Hay valores de proceso asociadas a este dispositivo que desea historizar? ¿Con qué frecuencia desea guardar los valores? ¿Quieres agregar límites de cambio de historización? Las alarmas y eventos. ¿Qué valores requieren alarmas? ¿Qué valores quiere estar conectado como eventos? (ArchestrA IDE Alarms and Events proporcionan una funcionalidad similar a la que se presente dentro de InTouch.). Seguridad. ¿Qué usuarios se quiere dar acceso al dispositivo?

Upload: james-huber

Post on 03-Feb-2016

218 views

Category:

Documents


0 download

DESCRIPTION

dispositivos

TRANSCRIPT

Page 1: Identificado Todos Los Dispositivos de Campo

Después de haber identificado todos los dispositivos de campo, a continuación, tendrá que determinar la funcionalidad de cada uno. Identificación de los dispositivos de campo En la identificación de los dispositivos de campo, usted debe comenzar por interpretar el plano de tuberías e instrumentos (P&ID). Típicamente, este diagrama muestra todos los dispositivos de campo y muestra el flujo entre ellos. Si se tiene un P&ID bueno, el proceso de planificación de la aplicación tomará menos tiempo y será más fácil. Debe comprobar que el plano P&ID es correcto y esté al día en cuanto a revisiones antes de comenzar el proceso de planificación. Se prosigue a examinar cada componente en el plano P&ID e identificar cada dispositivo básico que se utiliza. Por ejemplo, una electroválvula puede ser un dispositivo básico. Un motor, sin embargo, puede estar compuesto de múltiples dispositivos básicos. Una vez creada la lista completa, agrupar los productos según el tipo, tales como válvulas, bombas, etc. Consólidar los dispositivos duplicados en tipos comunes de modo que solo una lista de dispositivos básicos únicos restos, y luego documentarlas en la hoja de planificación del proyecto. Cada dispositivo básico se representa dentro del framework ArchestrA IDE como un "objeto". Una instancia de un objeto debe ser derivado de una plantilla definida. El número de tipos de dispositivos en la lista final ayudará a determinar la cantidad de plantillas de objeto tendrá que crear para su aplicación. Puede agrupar varios objetos básicos para crear objetos más complejos, lo cual es un concepto conocido como "contención". Identificación de las necesidades funcionales Para cada dispositivo único, tendrá que definir los requisitos funcionales, que incluyen: 37 Las entradas y salidas. ¿Cuántas entradas se requieren para el dispositivo? ¿Cuántas salidas se requieren? Scripting. ¿Qué scripts estarán vinculados con el dispositivo? Por ejemplo, ¿el dispositivo requieren cálculo indirecto alguno? Historización. ¿Hay valores de proceso asociadas a este dispositivo que desea historizar? ¿Con qué frecuencia desea guardar los valores? ¿Quieres agregar límites de cambio de historización? Las alarmas y eventos. ¿Qué valores requieren alarmas? ¿Qué valores quiere estar conectado como eventos? (ArchestrA IDE Alarms and Events proporcionan una funcionalidad similar a la que se presente dentro de InTouch.). Seguridad. ¿Qué usuarios se quiere dar acceso al dispositivo? ¿Qué tipo de acceso es lo que quieres que hagamos? Por ejemplo, puede conceder a un grupo de operadores de acceso de sólo lectura para un dispositivo, pero permitir el acceso de lectura y escritura para un supervisor. Puede configurar diferentes de seguridad para cada atributo de un dispositivo. b. Definición de convenciones de nomenclatura El segundo paso en el flujo de trabajo es definir las convenciones de nomenclatura para las plantillas, instancias y atributos de objeto. Estas convenciones de nombres deben cumplir con: Convenios que se utilizan dentro de la empresa. ArchestrA IDE restricciones de nomenclatura. Por ejemplo, es posible que tenga un nombre de etiqueta de ejemplo: YY123XV456 con los siguientes atributos: OLS, CLS, Out, Auto, Man. La siguiente ilustración muestra cómo la convención de nombres en una interfaz hombre-máquina tradicional (HMI) es diferente de la denominación en ArchestrA IDE: 38 Figura 9: Convención de la nomenclatura. Para ArchestrA IDE, las referencias se crean con esta convención de nomenclatura: . = YY123XV456.OLS c. Definición del modelado de áreas El tercer paso del flujo de trabajo del proyecto es definir el modelo de las áreas. Un área es una agrupación lógica dentro de la aplicación que representa una parte del diseño de la planta. En una fábrica típica, definiría las siguientes áreas: Área de recepción, área de proceso, área de empaque y zona de descarga. Se tendrá que definir y documentar todas las áreas de la planta que formarán parte de la aplicación. Cada objeto tendrá que ser asignado a un área en particular. Cuando se instala Application Server, un solo marcador de posición se crea por

Page 2: Identificado Todos Los Dispositivos de Campo

defecto, llamado "Unassigned host". A menos que se especifique lo contrario, todas las instancias de los objetos serán asignados a esta ubicación de marcador de posición. Los siguientes son algunos consejos para la creación de áreas: Si crea todas sus áreas primero, puede asignar fácilmente una instancia de objeto a la zona correcta si define esa área en particular como el área por defecto, de lo contrario, tendrá que desplazarse fuera de la zona asignada más tarde. Fuente: Manual Wonderware System Platform. 2013. 39 Es útil para crear un área de control del sistema a los que puede asignar los items de WinPlatform y objetos AppEngine. Los objetos WinPlatform y AppEngine se utilizan para apoyar las comunicaciones de la aplicación, y no necesariamente tienen que pertenecer a un área relacionada con la planta o cualquier área para el caso. Las alarmas se agrupan de acuerdo a las zonas. Las áreas se pueden anidar. Es recomendable hacer el modelado de acuerdo a lo expresado en la nota técnica de Wonderware sobre BTL (Base Template Library). Cuando se construye una jerarquía de Área, tenga en cuenta que el área base en la que se asigna a una Platform determina cómo se desplegarán los objetos subyacentes. Si un área de la planta (ubicación física) va a contener dos equipos que ejecutan plataformas de Automation Object Server, entonces se tendrán que crear dos áreas lógicas para la planta física. Uno de los enfoques para la creación de instancias de un objeto es crear una instancia de un área a la vez. Si se utiliza este enfoque, entonces marca el área por defecto, por lo que cada instancia se le asigna automáticamente el área seleccionada. Antes de empezar a crear instancias en otra área, cambie el valor predeterminado a la nueva zona. Una consideración final para la construcción de las áreas es que las diversas áreas equivalen a grupos de alarmas. Este es el nivel de las áreas en la que se pueden filtrar las alarmas fácilmente. A continuación se detalla el bosquejo de la filosofía de modelado de planta aplicado al proyecto para hacer la analogía entre el modelo físico y el modelo en el software de control: 40 Figura 10: Modelamiento de Planta. d. Planificación de plantillas Una plantilla es un elemento que contiene los parámetros de configuración más comunes para los objetos que se utilizan varias veces dentro de un proyecto. De las plantillas se crean instancias para representar objetos específicos dentro de la aplicación. Por ejemplo, es posible crear varias instancias de una válvula dentro de la aplicación a partir de una plantilla de válvula que tiene todas las propiedades requeridas. Esto le permite definir una vez y volver a utilizar varias veces. Si cambia la plantilla, los cambios se pueden propagar a las instancias. Puede utilizar arrastrar y soltar dentro del IDE ArchestrA para crear instancias de las plantillas. Fuente: Manual Wonderware System Platform. 2013. 41 Figura 11: Herencia de atributos en plantillas. Los objetos de automatización más usados son los siguientes: Tabla 2: Objetos de automatización. Object Descripción $AnalogDevice Dispositivos analógicos. Ejm: Sensores de temperatura, nivel, pH, etc. $DiscreteDevice Dispositivos discretos. Ejm: Válvulas, motores. $UserDefined Dispositivos customizables por el usuario. Los dos pasos siguientes, que definen el modelo de seguridad, y la definición del modelo de implementación, se realizan una vez que el modelo inicial de la planta está en su lugar. Fuente: Manual Wonderware System Platform. 2013. Fuente: Manual Wonderware System Platform. 2013. 42 e. Definir el Modelo de Seguridad Cada atributo de un AutomationObject se le da una clasificación de seguridad. Esto proporciona la capacidad de definir quién puede escribir en los atributos de un objeto. f. Definir Modelo de implementación La vista del modelo de despliegue muestra qué casos los objetos que residen en las computadoras. En el entorno ArchestrA, la ubicación física de las instancias de objeto no está obligado a aproximados que modela el medio ambiente del mundo real. La vista de despliegue

Page 3: Identificado Todos Los Dispositivos de Campo

no tiene por qué reflejar el entorno de la planta física. 1.2.3. Wonderware InTouch HMI El software InTouch ofrece funciones de visualización gráfica que llevan sus capacidades de gestión de operaciones, control y optimización a un nivel completamente nuevo. Dentro de los software SCADA en el mercado, Intouch ofrece innovación, integridad de arquitectura, conectividad e integración de dispositivos, ruta de migración de versiones de software sin interrupciones y facilidad de uso. Esto se traduce en sistemas basados en estándares que permiten incrementar al máximo la productividad, optimizar la efectividad del usuario, mejorar la calidad y reducir los costos operacionales, de desarrollo y de mantenimiento. (Invensys Inc., 2008) Beneficios Facilidad de uso que le permite a desarrolladores y operarios ser más productivos de manera simple y rápida. Gran integración de dispositivos y conectividad a prácticamente todos los dispositivos y sistemas. Sus capacidades de representación gráfica y la interacción con sus operaciones permiten entregar la información correcta a las personas correctas en el momento correcto.