Sistema de Plataforma 2017 Diseño y

lineamientos de implementación

Última actualización: 13/07/2018

1. Contenido
2. Introducción ................................................. .................................................. ................................. 2

3. Diseño de arquitectura Recomendaciones ............................................. ........................................... 2

4. Diseño de flujo de trabajo Galaxy ............................................. .................................................. .................. 3

5. general Galaxy .............................................. .................................................. ................................ 4

6. Modelo Vista .............................................. .................................................. ..................................... 6

7. Despliegue Ver .............................................. .................................................. ............................ 8

8. Plantillas del sistema ................................................ .................................................. ....................... 10

9. Dispositivo Integración .............................................. .................................................. ......................... 14

10. Objetos de Aplicación ................................................ .................................................. ................. dieciséis

11. Gráficos ................................................. .................................................. ................................. 21

12. Aplicación InTouch ................................................ .................................................. ................ 25

13. InTouch Aplicación OMI ............................................... .................................................. ......... 26

14. Rendimiento y métricas ............................................... .................................................. ........ 28

Página 1 de 29
2. Introducción
La Guía de plataformas de diseño e implementación del sistema está dirigido a responder muchas de las preguntas más frecuentes de los

desarrolladores de la plataforma del sistema. Se tiene la intención de ayudar a los nuevos y experimentados ingenieros desarrollan

siguiendo la correcta mentalidad que producirá una aplicación funcional, fiable y escalable.

3. Arquitectónicos recomendaciones de diseño

Puro rendimiento ideal y configuración 2017
Plataforma del sistema 2017 se puede ejecutar una única máquina / VM a 100.000 I / O, los motores de división a alrededor

10 000 I / O por motor. Esto incluye funciones historiador y 20 clientes OMI. Para obtener este tipo de cifras de rendimiento
desde una sola máquina, el siguiente debe ser cierto:

• Se trata de una nueva generación de proyecto en 2017 así que no hay un solo migrado.

• No hay secuencias de comandos o secuencias de comandos que se ejecutan en un mínimo de objetos

• Cuando se necesita secuencia de comandos SQL que el cliente utiliza nuestras bibliotecas SQL.

• Se utiliza Auto IO Asignación

• Nueva servidores OI no se utilizan los heredados.
• InTouch OMI se utiliza para la visualización, no InTouch Classic
• Los tiempos de ejecución No vaya a bajar a continuación, 500 ms 250 ms para los motores y de E / S.

La máquina debe ser 16 núcleo mínimo, con 64 GB Ram. Del mismo modo, si está buscando un sistema de 50.000 I / O con las
consideraciones anteriores, la especificación mínima debería ser de 8 núcleo, 32 GB Ram.

Es importante tener en cuenta la velocidad de reloj de la hora de seleccionar el procesador, en lugar de sólo el número de núcleos. Objetivo de 2,8 GHz

o superior.

Más aplicación en el mundo real y la expectativa - recomendaciones

Una recomendación razonable para un proyecto de 2017 Plataforma del sistema que tiene algunas secuencias de comandos y utiliza cualquiera de

InTouch HMI o una mezcla de los OMI también, entonces la sugerencia es que:

Para un máximo de alrededor de 25K Sistema de E / S - 4 núcleo, 8-12 GB Ram para un todo en una sola máquina. Adición de la máquina secundaria

para la redundancia si es necesario. Hasta 25 K / S, SQL Express es apoyado

Para un sistema de 50K I / O - 4-8 Core, 16-24 GB Ram para un todo en una sola máquina, añadiendo una máquina secundaria para la redundancia si es

necesario. Hemos probado 50K de E / S a las 4 CPU virtual y 12 GB de RAM y la máquina funcionó pero con una alta utilización de la memoria RAM, por

lo tanto, le aconsejamos superior RAM para hacer frente a las demandas de carga adicionales. Por encima de 25k de E / S, estándar SQL Server es

compatible

RDS Cliente - Tanto para 25K y 50K de E / S del sistema se recomienda tener un servidor RDS a cabo las sesiones de InTouch HMI o OMI,
segregando esencialmente los clientes de las funciones de automatización y de bases de datos. RDS evaluaba - Una regla general es para
InTouch HMI - entre 0,5-1 CPU virtual y 1 GB de RAM por sesión. Del mismo modo, para InTouch OMI, alrededor de 0,5 vCPU y 300-600MB
RAM por sesión. Puede obtener economías de escala mayor que aumentar el número de cliente. Nosotros no recomendamos ir por encima
de 40 clientes en uno RDS.

gruesa Cliente - 2 de núcleo, 4 GB de RAM. SSD cuando sea posible para la velocidad, mayor será el procesador Ghz el más rápido, en lugar de

más núcleos.

Página 2 de 29
Si continuamente en desarrollo en un sistema de producción - GRNode - Si el sistema es probable que tenga un desarrollo continuo en un
sistema encendido, es posible que desee separar esta función en una máquina virtual independiente. Las alternativas son utilizar la máquina AOS
redundante, ya que el motor principal del AM, y tienen el respaldo del AM en el GRNode, de modo que si los desarrollos continuos tienen lugar, es
menos probable que el impacto uso operativo. Otra opción, es tener un sistema de desarrollo de puesta en escena, por lo que el desarrollo y la
prueba es el rendimiento en una máquina de desarrollo / sistema, a continuación, una vez aprobados, importado en el sistema de producción Uno All
In, de manera que no es necesario segregar este GR / función dev.

4. Galaxy Diseño de flujo de trabajo

1. Configurar la seguridad

La primera etapa en la creación de una galaxia es definir el modelo de seguridad. Esto puede ser modificada posteriormente sin embargo la creación de los

roles para los usuarios de “desarrollo” y la adición de la seguridad permitirá a las propiedades del objeto para crear un registro de auditoría que muestra

quién está trabajando en qué partes de la galaxia. Todas las galaxias debe tener algún tipo de seguridad activado.

2. Estilos calidad de configuración, estado, alarma y eventos de almacenamiento y Galaxy

Estos tienen efecto inmediato, define los estándares para las pantallas para ser reutilizados en muchos gráficos.

3. Configurar Elemento y Formato Estilos

Las normas que se van a utilizar a lo largo del ciclo de vida del proyecto y para proyectos futuros debe ser configurado de manera que todos los

gráficos se pueden crear con los estilos de elementos y de formato disponibles para su uso. Esto permitirá a los ingenieros utilizar y observar el

estándar cuando el proyecto pase a plazo e identificar los requisitos para la alteración rápidamente.

4. Tome una copia de seguridad

Una vez que se han aplicado las normas iniciales una copia de seguridad debe ser tomado para que pueda ser reutilizado para proyectos futuros.

5. Definir Planta Modelo Vista

La vista del modelo representa la agrupación física o lógica del sistema y debe representar una evaluación real de cómo está
estructurado el sistema.

6. identificar el equipo

Identificar los distintos equipos en el sistema y entender si existen o no las plantillas que se ajustan a sus necesidades ya dentro
de la Plataforma Sistema 2017 Biblioteca de objetos

7. Plantillas de diseño (Ejercicio de papel)

Donde no existen plantillas proporcionadas; Identificar las partes comunes de los equipos y planificar una estructura de derivación que

representa estas diferencias sin tener que configuración de repetición.

Considere estructuras más grandes usando contención para las secciones más repetibles de diseño.

Página 3 de 29
 8. creación de plantillas de inicio

Iniciar las plantillas de diseño una vez que la planificación se ha hecho. Una vez que se definen las plantillas de inicio derivar casos y pruebas de E /

S, guiones y la lógica.

5. Galaxy general

5.1. Configuración de seguridad

Por defecto una galaxia no tiene ningún tipo de seguridad configurado. Hay tres tipos de seguridad que están disponibles para su uso. Cuando

está habilitada la seguridad del usuario “administrador” se crea sin una contraseña por defecto. Esto se debe cambiar cuando la seguridad está

configurado inicialmente.

La seguridad intrínseca “Archestra” provee de acceso y de seguridad común en todas las plataformas y es el más adecuado cuando se requieren señal

de encendido y de seguridad, pero el sistema no es parte de un dominio.

OS del usuario y la seguridad basada Grupo OS utilizan el sistema operativo como una fuente de autoridad, esto es adecuado para entornos de dominio

como el uso de usuario del sistema operativo o del OS del grupo de seguridad basada permite el máximo provecho de seguridad de Windows y la política

de contraseñas que deban tomarse. OS Grupo de seguridad basado es más escalable que la seguridad basada en sistema operativo del usuario, sino que

requiere un poco más implicación con el equipo que gestiona el directorio activo.

Siempre que sea posible se recomienda utilizar seguridad basada Grupo OS.

5.2. tiempo Maestro

Algunas de las funciones del servidor de aplicaciones tales como la escritura, alarmante, y historizante dependen de todos los equipos

miembros de una galaxia que ser sincronizados a la misma vez. Un maestro de tiempo es un tiempo de red Protocolo de servidor que

proporciona un tiempo que otros nodos de la red pueden sincronizar. El maestro de tiempo puede ser un nodo no ArchestrA dentro del Galaxy.

Los nodos ArchestrA en el Galaxy sincronizan periódicamente sus relojes al maestro tiempo.

Esto se puede configurar dentro de la IDE en 'Galaxy'> 'Configuración'> 'Tiempo Maestro'.

Se recomienda para sincronizar el tiempo del nodo Historiador a la fuente de tiempo solicitado y entonces cada uno de los nodos en el sistema

“Wonderware” a la máquina servidor Historian. La sincronización del tiempo se puede lograr utilizando construido en la funcionalidad de Microsoft

Windows, 3 rd Los productos de terceros o la configuración de un “Time Master” dentro de su galaxia.

funciones de software fundamentales pueden verse afectados por el fracaso para asegurar la sincronización de tiempo. No hay circunstancias en las

que no se requiere sincronización de tiempo a través de la galaxia.

5.3. Gestión de las comunicaciones

Si Communication Management avanzado está habilitado, el sistema permitirá el Galaxy objetos para ser activado en la demanda (asesorar

sobre la premisa activo). El grupo de exploración de objetos DI debe estar configurado para “ActiveOnDemand” para tomar ventaja de esta

configuración.

Página 4 de 29
 5.4. Caja de herramientas de diseño

La caja de herramientas de plantilla se utiliza para la gestión de sus plantillas. El uso de estos le permite organizar las plantillas en carpetas comunes

(conjuntos de herramientas) así que es más fácil de navegar a la plantilla que necesita. Se recomienda que el prefijo de los conjuntos de herramientas

con un número para que se mantengan en el orden correcto, siendo el más alto plantillas base de modo prefijado con un cero (0).

También se recomienda que las plantillas base que se suministran con el software también se ponen en su propio conjunto de herramientas marcado como

“99. Sólo lectura”o ocultar la carpeta de vista de los usuarios.

Página 5 de 29
6. modelo Vista
Vista del modelo representa la disposición lógica de la planta que representa la galaxia. Debe ser un desglose lógico de las zonas
en el sistema, esta ruptura podría incluir sitios, edificios, líneas de producción y subdivisiones dentro de cualquiera de estos. La
vista del modelo puede ser considerado como un “Equipo de Vista” cuando se evaluó con el estándar ISA-95.

El modelo de planta, en última instancia define la forma alarmas se recuperan, cotejados y agregados a través del sistema.

En el diseño de un sistema que se va a utilizar InTouch OMI la vista del modelo tiene la función adicional de definir la navegación

configurado automáticamente dentro de la aplicación. La visualización automática de gráficos puede mostrar gráficos asociados de ambos

recipientes y objetos contenidos. Asegurarse de que su vista del modelo se alinea con un desglose lógico de cómo navegar a través de los

operadores de la planta, se reducirá la cantidad de navegación personalizada que va a crear dentro de InTouch OMI.

Para construir el modelo de área a partir de cero, se recomienda que dos zonas se crean en primer lugar. Un área llamada mandos de control; esta

área será el lugar donde se colocan todas las plataformas y motores. Esto permite que la capacidad de producción de las alarmas Separar de alarmas

del sistema de control dentro de InTouch.

La siguiente área sería el nombre de la planta; este será el área principal que contendrá todas las demás áreas de la planta. Esto permite que la

capacidad de consultar todas las alarmas de la planta sin tener que enumerar todas las áreas.

Una vez que se ha creado el área de la planta, cada sección de la planta se crea por ejemplo, la ingesta, producción y dada de alta.

El siguiente paso sería dividir las áreas antes mencionadas abajo en sus áreas más pequeñas, por ejemplo, tiene varias líneas de producción.

Página 6 de 29
Puede tener tantas áreas como le gustaría, sin embargo hay que tener en cuenta el mantenimiento del sistema será más difícil si
usted tiene la planta dividida abajo en miles de áreas.

Como se puede ver en la imagen de abajo, utilizando una convención de nomenclatura bien permite la posibilidad de revisar los datos basados ​ya sea en

el nombre del área específica o su ubicación.

La alarma de la agrupación en el sistema se realiza basándose en el modelo de área que se ha definido. Al consultar las alarmas en vivo para

un área, si existen áreas adicionales en el área como zonas infantiles, también se devuelven estas alarmas.

En el ejemplo de la imagen Vista del modelo esbozado anteriormente, se puede consultar cualquiera de las alarmas en la línea 1, 2 o 3 o, si quisiera

recuperar todas las alarmas para todas las líneas, a continuación, usted podría simplemente consulta las alarmas de Producción.

Página 7 de 29
7. Ver el despliegue
La vista despliegue representa cómo se distribuye la carga de trabajo de un sistema entre los servidores y las tareas que se asigna a

cada nodo. No hay ningún requisito para esta agrupación para estar alineados con la vista del modelo, sin embargo muchos clientes les

resulta útil contar con motores dedicados a partes específicas de la vista del modelo para permitir el mantenimiento más fácil de las

piezas individuales del entorno de producción.

En un entorno multi-nodo sólo los mejores zonas de nivel de sistema y son recibidos por un motor en la plataforma Nodo GR.

El punto de vista de implementación es el único lugar en el IDE de Plataforma del sistema que le permite ver la relación completa entre los objetos

desplegados y cómo anular la implementación de un objeto podría afectar a otro. Se recomienda que todas las acciones de implementación se

inician a través de la vista de implementación para asegurar que no hay efectos inesperados.

AppEngines son el componente de la plataforma de aplicaciones del sistema que gestionar la ejecución de la aplicación configurada a

excepción de los componentes de visualización. Ellos deben ser distribuidos entre las plataformas dentro de la galaxia. Como regla general

cada nodo debe tener una primaria y un motor de copia de seguridad por núcleo, sin embargo, es importante que cada nodo tiene los

recursos para ejecutar sus funciones principales y de respaldo al mismo tiempo.

No hay se fija recomendación para el número de objetos o IO atributos que cada motor o plataforma debería ser la sede sin
embargo 2.000 objetos y 10.000 IO por AppEngine es un buen punto de partida. Tú

Página 8 de 29
puede encontrar que parte de la lógica en un sistema tiene una carga de trabajo mayor que los demás. Usa los parámetros de rendimiento

descritos en la sección 14 para determinar el rendimiento del sistema.

Los motores estándar pueden manejar una carga más pesada que los motores redundantes, al comprobar el rendimiento de asegurar que el motor está

configurado para redundancia antes de empezar la prueba.

ViewEngines host administrado aplicaciones InTouch y gestionar el proceso de transferencia de los archivos necesarios entre el nodo

Galaxy repositorio y la plataforma del cliente. Una plataforma puede tener más de un ViewEngine sin embargo, esto no es necesario.

En los sistemas más grandes de implementación puede ser un tiempo y un proceso que consume muchos recursos. La parte que más tiempo de este

proceso es normalmente usando las plataformas. Las plataformas están sin desplegar y desplegados en raras ocasiones y por lo general este tipo puede

implementar en su propia medida que se crean. En un sistema más grande, se recomienda que las plataformas se despliegan de forma individual y sin

“Cascade Implementar” seleccionan entonces los motores en la parte superior de estas plataformas se despliegan con “Cascade Implementar”

seleccionado. El despliegue de las secciones permite que los tiempos de espera que deben evitarse y reduce las posibilidades de que las

implementaciones que fallan. Una vez que una comprensión de las escalas temporales necesarias para el despliegue se obtiene entonces un despliegue

completo del sistema puede ser considerado. complejas secuencias de comandos en “Inicio” y “guiones” OnScan son las causas más probables de falla

despliegue objeto.

7.1. Implementación redundante Sistemas

En un par redundante de los motores principales y de respaldo deben ser desplegados para diferentes plataformas. En un entorno con

múltiples hipervisores es común para desplegar motores redundantes a las plataformas que se asignan a las máquinas virtuales con

diferentes hosts físicos.

Cada nodo del sistema de producción de anfitrión de una redundancia permitido AppEngine debe tener un mínimo de dos tarjetas de red

por máquina. La primera máquina es para la red de supervisión y el segundo es para el canal de mensajes de redundancia (RMC). La red

RMC está dedicado para control de la redundancia y la sincronización de datos entre pares de AppEngine redundantes.

Cuando la configuración de las redes, debe asegurarse de que la red de supervisión primaria es la primera en el orden de enlace de red (ver

configuración de red avanzada). Se recomienda que IPv6 está desactivado, ya que no está soportado directamente por el software de

Wonderware. La Red RMC debe estar configurado para una dirección IP estática.

Wonderware han descubierto problemas con la redundancia de servidor de aplicaciones y el RMC cuando se activa el motor de descarga TCP

(TOE).

La integración de dispositivos Los objetos no deben ser desplegados para motores redundantes y siempre deben ser desplegados para motores

estáticos.

Página 9 de 29
8. Plantillas sistema
8.1. Plataforma

Una plataforma representa un instancias de un sistema operativo. Si el sistema operativo es físico o virtual, para que se aloja ningún funcionalidad de

la plataforma del sistema (excluyendo Historiador) y luego una plataforma debe implementarse en ella. Un hipervisor de alojamiento máquinas

virtuales que se ejecutan funcionalidad Plataforma del sistema no necesita una plataforma desplegada a ella.

Si el tienda de directorio historia hacia adelante se cambia desde el valor predeterminado en blanco, este directorio debe ser excluido del

software anti-virus, en su caso.

8.1.1. proveedor de la alarma InTouch Habilitar la proveedor de la alarma InTouch para establecer la Plataforma como un proveedor de la

alarma para el sistema. Generalmente la máquina Historiador podría ser utilizado como el proveedor de la alarma InTouch. La razón es que la máquina

Historiador generalmente se maneja por su disponibilidad (es decir, el tiempo inicial mínimo).

En un entorno de Servicios de Escritorio remoto, los nodos de servidor RDS se pueden habilitar como proveedor de la alarma InTouch linfáticos ya que

esto permite que las aplicaciones InTouch a consulta a la plataforma local de alarmas, esto permite la conmutación por error de alarma con los clientes

RDS sin secuencias de comandos o configuración adicional.

8.1.2. Redundancia
Para configurar la redundancia de la plataforma, el dirección IP Redundancia de canal de mensajes se debe configurar en las

plataformas que serán sede del par redundante. La dirección IP registrada debe ser la IP del adaptador de RMC local en el equipo.

8.1.3. El intercambio de mensajes mensaje de tiempo de espera ajuste es el número de milisegundos para un mensaje de
respuesta para las comunicaciones a través del motor. La configuración por defecto es 30,000ms. Se recomienda que este ajuste se

incrementa en la GRNode para evitar problemas de comunicación del motor (AppEngine no responder dentro de los plazos por lo tanto

causando un error de comunicación) durante el despliegue de grandes galaxias. El ajuste puede ser configurado para 300,000ms para

grandes galaxias.

Página 10 de 29
los número consecutivo de los latidos del corazón NMX perdidas permitió tiene un valor predeterminado de 3, para los sistemas de medianas y

grandes este valor puede ser aumentado a alrededor de 6. Este es el número de latidos consecutivos que se permiten se puede perder desde una

plataforma antes de que un “error de comunicación plataforma” se genera para esa plataforma.

8.2. Motor

8.2.1. Pestaña General

El período predeterminado es de 500 ms. Esto es suficiente para la mayoría de las operaciones. La disminución de la período de exploración aumenta la

carga de trabajo del motor, aumentando el período de exploración disminuye la carga de trabajo del motor. Si una tarea debe llevarse a cabo con mayor

rapidez que 500 ms después del periodo motor de exploración tendrá que ser disminuido. Esto debería ser juzgado en una base de caso por caso.

El Período de Checkpoint, para sistemas con alrededor de 20K I / O, el valor recomendado es de al menos 20,000ms y para sistemas con 40K + I / O el

valor debe ser 60.000 ms. Al establecer este valor demasiado bajo puede resultar en el uso de recursos de alto, y la corrupción de los archivos de

control. Establecer el valor medio demasiado altas que si fallan ambos socios, los datos de un punto de control puede no estar actualizada.

Si la ubicación del directorio de punto de control que no sea por defecto (es decir, en blanco) nada, entonces esta carpeta debe ser excluido de las

exploraciones Anti-Virus.

los Fallo de motor ajuste Tiempo de espera se utiliza para determinar el tiempo que el motor tiene que informar a la rutina de carga que se está
desplegado Plataforma Y, los latidos del corazón serán enviados por la plataforma Y a la plataforma X.
ejecutando. Si el motor no indica el atributo de 3 tiempos de espera consecutivos, el motor se determina que es 'en problemas' y el socio

redundante se hace cargo. El valor recomendado para este ajuste es 20,000ms. Al establecer este atributo demasiado baja hace que el

redundante asociado a reaccionar de forma exagerada cuando el uso de la CPU es alta. Establecer el valor demasiado alto puede retrasar las

notificaciones que el motor está en problemas ya que el Bootstrap considera que el motor 'sano' hasta que el tiempo de espera expira. El tiempo

de espera de fallo del motor es la cantidad de tiempo, en milisegundos, que el motor puede funcionar sin notificar al arranque de su salud.

Después de este tiempo transcurre, el atributo EngineFailureAlarm se establece en TRUE en el objeto WinPlatform. Asegúrese de que especifica

un tiempo suficientemente largo para dar cabida a la realización de las acciones relacionadas con el motor que podrían impedir o retrasar la

notificación de arranque (por ejemplo, el despliegue cascada de objetos con un gran número de secuencias de comandos). Internamente, el

sistema triplicará el valor que especifique para este atributo.

plataformas. El valor por defecto es 2,000ms y no se requiere ningún ajuste para este ajuste. Si la plataforma X está suscrito a los datos en un motor

Si el puerto TCP para la conexión Historiador se cambia desde el valor predeterminado de 32568 entonces el puerto TCP debe ser cambiado en el

servidor Historiador, ya que este es el puerto TCP en el servidor Historiador a la que se enviarán los datos de la historia.

El motor puede ser configurado para comprimir los datos de la historia. Para ello la casilla de verificación Habilitar la compresión debe ser

marcada. Si está habilitado el historial de datos se comprime antes de ser enviada al historiador través de la red. Esto se puede utilizar para

reducir el uso de la red, sin embargo permite que esto aumentará la carga de la CPU. Por lo tanto, si se habilita esta configuración, la carga de

la CPU debe ser monitoreada.

Página 11 de 29 El NMX periodo del latido del corazón es la frecuencia en milisegundos en el que se envían los latidos del corazón a otras
 8.2.2. redundancia Tab
Habilitación de la redundancia en un motor es una tarea simple de control de una caja de redundancia Habilitar en la pestaña de redundancia del

motor. La plataforma de alojamiento para este motor debe estar configurado para redundancia mediante la configuración de la dirección IP de canal

de mensajes.

La recomendación para el tiempo de espera de conmutación por error forzada puede variar a través de los sistemas. Un sistema de Pequeño (hasta 3 K

/ S) es la recomendación sobre 30,000ms. 45,000ms se aconseja durante más de 3 K / S y 240,000ms por alrededor de 40 K / S. 300,000ms ha sido

recomendado para un sistema muy grande. Si este valor es demasiado pequeño, la conmutación por error forzada no tendrá éxito. Si el ajuste es

demasiado grande, no se detectará el fracaso de una manera oportuna. Este ajuste debe ser probado y ajustado al sistema.

El valor por defecto para el período de latido motor de espera / activo es 1000 ms. Este ajuste puede aumentarse para evitar falsas conmutaciones

por error.

Los latidos máximos consecutivos perdidas del motor activo puede variar a través de sistemas de escala diferentes. Un pequeño sistema podría tener un

valor de 5, un medio - grande sistema está entre 10 y 30 años y para un sistema muy grande la recomendación es de alrededor de 60. Los mismos

valores recomendados se pueden utilizar para los latidos máximos consecutivos perdidos desde el motor de espera. Al establecer este valor demasiado

bajo produce falsas conmutaciones por error, mientras estableciendo el valor resultados demasiado alta en la detección lenta de una conmutación por

error requerida.

El tiempo máximo para mantener una buena calidad después del ajuste por defecto es la falta de 15,000ms, se recomienda utilizar este valor para

un sistema pequeño y se puede aumentar a 120,000ms para medianas y grandes sistemas, y para sistemas muy grandes el valor se puede

aumentar a alrededor de 150.000 Sra.

El tiempo máximo para descubrir socio es el máximo periodo de tiempo, en milisegundos, se admiten para la conexión con el socio de conmutación

por error no se ha establecido antes de que el nivel de compañeros de conmutación por error se establece en “desconocido”. El valor por defecto es

15,000ms. No existen recomendaciones establecidas para este entorno y que no necesita ser afinado.

8.2.3. R W Tab /
El número de interrupciones de lectura / escritura de forma predeterminada el valor es 5. Este es el número de veces de lectura / operación de escritura se

produce durante la fase de ejecución objeto en cada ciclo de exploración del motor. El número máximo es 256.

La interrupción estándar Habilitar se puede habilitar. Si se habilita todos los DIObjects reciben aportaciones de otros objetos y escritura a los

dispositivos de campo durante la fase de ejecución del objeto en cada ciclo del motor.

La habilitar las interrupciones completos se pueden activar. Si se habilita todos los objetos de enviar y recibir actualizaciones y todas DIObjects en este

motor de escritura y reciben actualizaciones de los dispositivos de campo durante la fase de ejecución del objeto en cada sistema de motor.

8.3. ViewEngine
Una plataforma sólo necesita 1 ViewEngine, pero puede manejar más. Múltiples InTouch Ver aplicaciones se pueden asignar a un solo ViewEngine.

A ViewEngine también se puede utilizar para soportar las aplicaciones de InTouch por; proporcionar matrices de atributos específicos, estaciones de

trabajo, las constantes globales manejados con una plantilla ViewEngine.

Página 12 de 29
 • Puede alojar múltiples instancias de aplicaciones InTouch

• Puede servir como un motor Activo en tiempo de ejecución

o Plantilla para los valores de configuración

o Titular de Archestra gráficos como Windows

• Ver múltiples motores se pueden utilizar en la misma plataforma

8.4. Zona
Un área representa un área de una planta dentro de una galaxia. El objeto Área actúa como un concentrador de alarma y se utiliza para poner otros

objetos de automatización en el contexto de la disposición real de automatización física.

Múltiples motores requieren múltiples áreas. Evitar la asignación de un gran número de objetos a una sola área; romper la zona en

una jerarquía. 500 objetos es un objetivo de diseño máximo bien, sin embargo esto es totalmente subjetivo a la carga, el rendimiento

y los objetos individuales.

• Estipula la autorización de objetos a través de los motores

o Modelo jerárquico
o Alarmante y Eventos
• Los datos históricos (si está habilitado a 1 S t Historiador nivel)

• Las áreas son hermanas en ejecución no jerárquica

• Debe tener múltiples áreas de apoyo a múltiples motores

• El paquete acumulativo de los Condes de alarma / Activar / Silencio /

Desactivar límite de 500 objetos / Zona es una regla bien de historización

pulgar de las alarmas que se hace por el motor.

Página 13 de 29
9. Integración de dispositivos

9.1. DI objetos
Dentro de la galaxia hay múltiples DIObjects que podrían utilizarse. Para conectar a los dispositivos en el campo se requiere un objeto

de la integración de dispositivos. Estos pueden ser específicos al PLC que está utilizando o uno genérico como el DDESuitelinkClient,

OPCClient o la InTouchProxy.

La ruta de conexión recomendado es utilizar el objeto de cliente DDE / SuiteLink para conectarse a un servidor de integración de

operaciones. Cuando se utiliza una licencia ejemplo, una “profesional” OI servidor debe ser creado por el PLC y por lo tanto un objeto

DDE / SuiteLink cliente debe existir por PLC.

Si el objeto OPCClient se va a utilizar, entonces es recomendable que este objeto se implementa en la misma máquina que ejecuta

el servidor OPC. Con OPC se requiere un número de permisos. Localmente en la máquina estos permisos están configurados, sin

embargo a través de la red tienen que ser configurado manualmente. Colocar el objeto OPCClient en la misma máquina el medio de

conexión OPC es local y la comunicación de red cruz se maneja usando el protocolo interno de Plataforma del sistema, NMX. Si por

alguna razón el objeto OPCClient no se puede implementar en la máquina servidor OPC, una tuneladora OPC se debe utilizar.

objetos DI sólo deben ser organizadas por una aplicación de motor estático (es decir, un no redundante App Engine). Un objeto DI estándar no

debe ser puesto en un motor redundante; ello dará lugar a la conmutación por error del motor tomando más tiempo de lo necesario. Esto se debe

al objeto DI tener que cancelar el registro de todos los IO sobre sí mismo y volver a registrar todos los IO. El RedundantDIObject se debe utilizar

y se coloca en un motor redundante en lugar; el proceso de registro no se produce en este escenario.

Los objetos DI deben configurarse con una script de reconexión para garantizar que el objeto DI se volverá a conectar a su fuente de datos debe

producirse una desconexión. El manual de capacitación y la Nota Técnica 300 proporcionan scripts de ejemplo de reconexión para DIObjects.

9.2. objeto RedundantDI

Application Server proporciona redundancia dentro de adquisición de datos. Para ello debe configurar dos objetos DI (fuentes de datos) y

un RedundantDIObject. Los monitores RDI y controla las fuentes de datos DIObject a nivel de objeto. A diferencia de AppEngines

redundantes, fuentes de datos DIObject individuales no tienen estados relacionados con la redundancia. A efectos prácticos, funcionan

como objetos independientes.

Sólo una fuente de datos DIObject proporciona datos de equipos de campo a través de la RDI a la vez. Ambas fuentes de datos deben tener

DAGroups comúnmente configurados. Estos deben reflejarse en y canalizados a través de la IDR, que supervisa las dos fuentes de datos DIObject.

También determina que la fuente de datos está activa en un momento dado. Ambas fuentes de datos también deben tener el mismo espacio de

direcciones artículo. El RDI puede ser hospedado por una aplicación de motor redundante.

A continuación muestra una captura de pantalla de cómo el objeto redundante DI se sienta en el motor redundante con la DI Objetos sentado en

motores no redundantes.

Página 14 de 29
Dentro de la IDR, en la pestaña Exploración de Grupo, el usuario debe configurar un “ping artículo”. El artículo Ping está configurado por

grupo de exploración. Se recomienda el uso de un elemento que es menos dependiente de las etiquetas en el PLC para evitar convertirse

en el elemento de ping válido. Tales como: $ SYS $ FreeMem, $ SYS $ TOTALMEM, $ SYS $ revisión, etc. Cualquiera de estos artículos

requieren el DAServer para conectarse al PLC para obtener la información periódicamente. Puesto que son los elementos del sistema que

pueden ser utilizados en cualquier momento para comprobar la conectividad sin importar qué programa del PLC se ha descargado en el

PLC. Si estos elementos son malas, entonces es definitivamente un problema con la conectividad. Si el artículo Ping se deja en blanco, se

le asignará automáticamente el elemento válido primero conocido como su artículo Ping, sin embargo, si el objeto se despliega en un

momento en que no hay ningún elemento válido se puede encontrar (es decir,

9.3. Servidores de integración operaciones

Considere el uso de los tiempos de espera del servidor OI, ping al PLC y ver lo que el tiempo de respuesta que está viendo. El valor por defecto es 2000

ms. Se recomienda que este se revisa, específicamente para el PLC en áreas de conexión remota / pobres. Por ejemplo, si un PLC tiene un tiempo de

respuesta de ping de 100 ms más de entonces se aconseja aumentar el tiempo de espera del PLC a alrededor de 5000 ms. Tener el valor de ajuste más

alta evitará primeros tiempos de espera para los PLC que se encuentran en áreas remotas.

Utilizar el objeto $ DDESUITELINK para conectarse a los servidores de Wonderware OI u otros conductores que soportan el protocolo SuiteLink, por

ejemplo TopServer.

En el nivel de configuración de grupos de dispositivos de la OI servidor de asegurar la Intervalo de actualización se establece en un número primo; esto

evitará que varios grupos de dispositivos de actualización exactamente al mismo tiempo. Cada grupo de dispositivos debe tener un número primo diferente Intervalo

de actualización.

• En el nivel superior de la configuración del servidor OI considere lo que se requiere el modo de empuje para su sistema. El valor por

defecto depende del Servidor OI utilizado. Modo de control - conserva el orden empuje absoluto. Este modo se utiliza típicamente

por aplicaciones de lotes y de control que dependen de la orden de los empujes y también en el procesamiento de cada artículo

asomó.

Página 15 de 29
 • Modo de transición - conserva el orden empuje absoluta manteniendo las primera, segunda, y los valores de la última empuje de un

elemento. Este modo es utilizado por aplicaciones de lotes y control que depende del orden de los empujes pero no procesan cada

artículo asomó.

• Modo de optimización - no conserva el orden y tiene empuje máximo plegado sólo meter el último valor de un elemento.

Este modo es utilizado habitualmente por las aplicaciones HMI.

Modo de control y el modo de transición requieren más trabajo por hacer por el OI Server para mantener el orden de los empujes.

10. Objetos de aplicación

Los objetos de aplicación son específicos de una aplicación. Los objetos de nivel de aplicación pueden estar contenidos objetos. Los objetos se pueden

utilizar para crear instancias de objetos.

10.1. Derivación
La estructura de la plantilla debe ser de una manera lógica y ordenada de las plantillas de base. Las plantillas base suministrados con el

software son de sólo lectura, como todas las plantillas de este tipo deben derivarse de prefijo y b_ - por ejemplo $ UserDefined tiene una

plantilla derivada de $ b_UserDefined. Estas serán las plantillas de base utilizados.

Las plantillas base de nueva creación deben tener cualquier configuración en ellos que es consistente en toda la galaxia.

El siguiente nivel de derivación es las plantillas maestras; que son específicos de la planta e incluyen ninguna información específica

con respecto a la planta que puede no ser elegible para las plantillas base. Estos deben tener el prefijo $ m_ - por ejemplo $ m_Valve

El tercer nivel de la derivación es específica de la aplicación que se está construyendo. Este es el principio de donde se está

implementando su diseño. Esta es la plantilla más alto nivel con todas las funcionalidades comunes en él para el tipo específico de

objeto, por ejemplo, $ Valve.

Tenga en cuenta que no hay limitación en el número de plantillas y el número de plantillas no influye en el funcionamiento
del sistema en vivo. Los más plantillas que tienen la mayor base de datos de la Galaxy será, por tanto, más carga habrá en
el motor de base de datos y el proceso de ArchestrA IDE.

Cuando un objeto ha sido creado y atributos asociados se han creado considerar si es o no el campo se puede bloquear. Esto evita

cambios adicionales en las plantillas y los casos derivados incluidos los cambios de tiempo de ejecución. atributos bloqueados hacer

cumplir las normas y se consideran “sólo lectura”, que también son

Página 16 de 29
retirado de los campos editables cuando se utiliza “Galaxy de basura”. cuerpos de configuración y de la escritura de guión también se pueden bloquear.

Esto también significa que los cambios realizados en la plantilla se propagan automáticamente a los objetos secundarios.

10.2. Contención
Plantillas a nivel de aplicación deben ser construidos en estructuras complejas que se hace referencia como la contención. Esto le permite

construir piezas complejas de la planta que puedan duplicarse varias veces con velocidad.

Plantillas con contención deben ser utilizados en todo momento siempre que sea posible, incluso si sólo hay una mesa de mezclas y que no se

duplica en cualquier parte de la planta, la contención todavía se debe utilizar. Esto es para permitir la expansión, uso futuro y un fácil entender

la estructura de los futuros ingenieros que trabajan en el proyecto.

Contención trabaja con la funcionalidad automática-asignar IO para construir referencias utilizando el nombre jerárquico y el
nombre del atributo. La referencia IO asignado automáticamente utiliza la estructura
DIObject.ScanGroup.Hierarchicalname.AttributeName”

10.3. Convenio de denominación

En el diseño del sistema de una buena convención de nomenclatura debe ser considerado.

El nombre de los objetos es la identidad de los objetos; es decir, ningún otro objeto debe tener el mismo nombre. Un nombre de objeto identifica

de forma única un objeto en el Galaxy. Un buen ejemplo de una convención de nomenclatura sería el estándar R1992 ANSI ISA S5.1 / 1984.

Un nombre contenido identifica de forma única un objeto dentro de su contenedor. Otros objetos de la galaxia pueden tener el mismo nombre que

figura, pero no si se encuentran en el mismo contenedor. Se aconseja para asegurarse de que el nombre contenido es descriptivo del papel o función

en el recipiente, por ejemplo Inlet_Valve, Outlet_Valve, etc Usted puede crear un objeto llamado Válvula sin embargo, el sistema de tiempo de ejecución

puede requerir que sea llamado SS01TM3V1. Con el nombre contenido todavía se puede hacer referencia a este objeto como Inlet_Valve, esto le

permite asignar IO fácilmente dentro de secuencias de comandos.

Los atributos son las interfaces públicas de un objeto; Por lo tanto, se recomienda que utilice una fuerte convención de nomenclatura. Por

ejemplo:

SP. podría ser utilizado para los valores de ajuste,

Cfg. podría ser utilizado para un parámetro configurable.

Cmd. podría ser utilizado para los comandos.

Página 17 de 29
Además, una buena convención de nomenclatura incorporará anteponiendo nombres de script con Scr_ o secuencias de comandos. Por ejemplo

Scr_TotalOutput.Calculation o Script.TotalOutput.Calculation.

También se recomienda el uso de una convención de nombres fuertes para la plataforma y motores. Esto es totalmente abajo a la preferencia

del cliente. El uso de algo tan simple como AppEngine01 está bien; sin embargo, no es necesario nombrar el AppEngine como AppEngine

como el logotipo sí indica que la instancia es una App Engine. Una convención de nomenclatura podría nombrar el AppEngine para que

coincida con sus objetos de división lógica (geográfica o función), por ejemplo NorthEngine, SouthEngine, o ProductXEngine, etc.

10.4. atributos
Se recomienda que un objeto no más de 60 atributos que más que esto puede ahorrar impacto y el tiempo de carga durante el
despliegue tiene. Si un objeto requiere más de 60 atributos y luego considerar la división del objeto y el uso de la contención para
representarlo.

Sólo alarmas de configure, historia y eventos cuando sea necesario. Cada parte de la configuración añade la carga y la complejidad de los objetos

cada vez más los recursos necesarios para su funcionamiento.

Parte de la definición del atributo debe ser la definición de la seguridad, ya que es mucho más fácil definir la seguridad por adelantado (y antes

de que se crean instancias) que redefinir una vez se han creado instancias. Las diferencias en la seguridad ejemplo normalmente se manejan

a través de grupos de seguridad dentro de la configuración de seguridad.

10.5. vinculación de gráficos

La funcionalidad símbolo enlazado se recomienda actualmente a información de tipo de visión general asociado con objetos de nivel de zona. Evitar

la vinculación de los símbolos a las plantillas con un gran número de casos derivados ya que esto reducirá el rendimiento en tiempo de diseño.

10.6. Guiones

En general, las consideraciones se deben dar a las secuencias de comandos y cómo se ejecutan. guiones de inicialización se pueden ejecutar OnScan por

ejemplo, pero un guión que escribe en un archivo de texto debe ser un ejecutan guión. Tenga en cuenta que un gran número de secuencias de comandos

que se deben ejecutar cuando el objeto está empezando o de ir de exploración puede afectar el arranque del motor (y por lo tanto de conmutación por

error) el rendimiento.

Puesta en marcha y las secuencias de comandos de apagado debe evitarse tanto como sea posible; estos scripts pueden retrasar las implementaciones y,

como tal, si el script toma un largo tiempo para su ejecución puede resultar en el despliegue tiempo de espera.

Ejecutar secuencias de comandos sólo pueden correr tan rápido como el ciclo del motor, como por ejemplo si se configura y esperar una secuencia de

comandos para ejecutar cada segundo, pero el ciclo del motor está configurado para ejecutarse cada 2 segundos y luego el guión sólo se ejecutará cada 2

segundos.

Cuando se utiliza un tipo de disparo de verdad / cierto tiempo, tener en cuenta que si la expresión contiene atributos y la calidad no es

buena, no se realizará y, como tal, nunca se ejecutará.

También se debe tener en cuenta cómo se ejecutan las secuencias de comandos, por defecto las secuencias de comandos se ejecutan de forma

sincrónica, es decir, en el mismo hilo que el motor. Por lo tanto, los scripts pueden 'bloquear' otras escrituras síncronas se ejecute si el guión está mal

escrito, que darán lugar a un rebasamiento de detección del motor. Algunas secuencias de comandos deben configurarse para ejecutar de forma

asincrónica para asegurar que otros scripts en

Página 18 de 29
el motor puede ejecutar sin ser afectados. Un buen ejemplo de un script que debe ser asíncrono es el que interactúa con una base
de datos, esto es debido al hecho de que no se puede confirmar el estado de un servidor de base de datos sin conexión
inmediata.

La regla de secuencias de comandos sin importar el idioma / aplicación que está utilizando es comentar el guión en cada ocasión. La depuración de

secuencias de comandos es mucho más fácil con los comentarios, especialmente de 6 meses después de que el guión fue escrito.

Al escribir el guión por primera vez, poner en la depuración de los mensajes que le escritura en el archivo de registro de SMC utilizando la función Mensaje

de registro (). Estos podrían ser encapsulados con una sentencia if que sólo se ejecuta si una depuración UDA se establece en true, por lo que durante el

funcionamiento del sistema si algo no funciona como se espera que este indicador se puede activar para depurar el sistema, ya que se está ejecutando .

guiones dataChange siempre son preferibles a que los scripts se ejecuta como expresiones sólo se evalúan en el cambio de datos, no

siempre.

10.6.1. El bloqueo de secuencias de comandos

Todos los objetos en un motor de ejecutar 1 a la vez. No hay puntos en los que los objetos están siendo ejecutados simultáneamente por el mismo motor.

Todas las secuencias de comandos en cada objeto deben completar dentro del ciclo de exploración o puede ocurrir un desbordamiento de exploración. Al

escribir guiones complicados debe tener en cuenta si alguna de las acciones que se están requiriendo del sistema son “bloqueo” acciones.

Un “bloqueo” es una acción que las fuerzas del proceso propietario que esperar para que la actividad completa. Ejemplos de esto se conecta a

una base de datos, solicitar información a un servicio web o abrir un archivo en un disco duro. Esto evita que un motor de hacer cualquier otra

tarea hasta que la acción se ha completado. Es mejor evitar es “bloqueo” guiones siempre que sea posible. En algunos casos puede ser necesario

para ejecutar secuencias de comandos asíncronos que se ejecutan como un hilo separado.

10.6.2. Secuencias de comandos de base de datos

El uso de la funcionalidad de .NET Framework es posible crear una conexión a una base de datos a través de una secuencia de comandos

objeto. Sin embargo, no se recomienda para crear una conexión con la base de datos y luego cerrar la conexión cada vez que se ejecuta la

secuencia de comandos. En su lugar, una conexión compartida debe crearse a nivel motor y luego utilice esta conexión dentro de sus objetos

de modo que todos los objetos utilizan la misma conexión. La conexión no está disponible para otros procesos en la máquina, como tal,

tendrá una conexión compartida en cada motor cuando sea necesario y la conexión no estará disponible para los gráficos ArchestrA como

éstas se ejecutan dentro del proceso de InTouch Vista.

Cuando intenta utilizar la conexión se debe comprobar que está activa, si no es entonces una reconexión debe ser activado. Un

ejemplo de mantener la conexión viva es ejecutar periódicamente una consulta básica a la base de datos como SELECT 1 - esto se

traducirá en el servidor de base de datos simple devolución '1'.

Un ejemplo de conexiones compartidas se puede encontrar en la página 98 de la Guía de aplicación de secuencias de comandos del servidor.

Cualquier conexión a una base de datos que se utiliza para los valores de escritura o de retorno, hacia y desde una base de datos, debe cerrarse

periódicamente; de manera que la memoria utilizada por la conexión y las transacciones se puede liberar. De no hacerlo puede resultar en una pérdida de

memoria, lo que podría causar que el motor se quede sin memoria.

Página 19 de 29
 10.7. Asignación de E / S auto-asignar IO

Al asignar IO utilizando la funcionalidad de IO auto-asignar con fuentes de datos basados ​en etiquetas la convención de nomenclatura de la

fuente de datos y Wonderware Application Server se puede alinear a reducir la necesidad de reconfiguración y aliasing. Al usar fuentes de datos

basado en direcciones una lista de alias se puede configurar dentro del objeto de integración de dispositivos para centralizar la configuración

alias.

Usando funcionalidad Auto-Assign es el método preferido.

10.8. Asignación de E / S a través de script

Al asignar IO dentro de un script, se recomienda que el tipo de ejecución del script es ejecutar y utilizando un 'mientras que la verdadera' tipo de

disparo. El script también debería tener un pequeño retraso antes de ejecutar; esto permite que el motor se reduzca después de desplegar

objetos.

Un ejemplo de una expresión sería como sigue;

10.9. Objeto ficha Información

Las descripciones de objetos deben ser configurados para que los usuarios puedan ver qué es el objeto y comprender el objeto sin tener que revisar su

funcionalidad. Tenga en cuenta que la restauración de una galaxia con una configuración de intercalación diferente puede dejar este campo en blanco.

10.10. Asistentes de objetos

Asistentes de objetos pueden ser utilizados para crear opciones que permitan la vista de derivación sea menos complicado.
Objeto Wizards asocia atributos, guiones y gráficos específicos con una opción o combinación de opciones. Esta configuración y
el desarrollo es toda la carga “diseño” y reduce la huella del objeto en el entorno de ejecución.

Un beneficio adicional de los Wizards de objetos es que reducen la complejidad de trabajar con la aplicación. Un objeto creado con un

asistente de objeto puede proporcionar opciones de configuración y combinaciones de opciones que permiten a un ingeniero para cubrir

una gran parte de los equipos que van a encontrarse con el sitio. Una biblioteca de los magos objeto puede ser creado como una empresa

o estándar sitio. Esto reduce el esfuerzo y el nivel de habilidad requerido para ingeniero de modificaciones adicionales al sistema como la

creación de objetos complejos puede ser reducido a la selección de las opciones apropiadas dentro de la configuración.

Página 20 de 29
11. Gráficos
11.1. Creación de gráficos
Se recomienda que se crean gráficos en la caja de herramientas gráficas y gráficos individuales están incrustados dentro de las
ventanas en lugar de InTouch InTouch ventanas que se componen de muchos gráficos incrustados.

11.2. Consideraciones sobre el rendimiento general

En lugar de intentar construir todos los gráficos de la manera más óptima importa que usted debe poner de relieve las importantes mayoría de los gráficos

y asegúrese que éstos son tan eficientes como sea posible. Compruebe cada ventana para ver el tiempo de carga y poner de relieve las ventanas de bajo

rendimiento. Luego de identificar los más significativos de gráficos en cada ventana para centrar los esfuerzos de optimización.

Archestra gráficos tienen un “ciclo de vida”, en cada etapa del ciclo de vida hay diferentes variables que pueden afectar el rendimiento. A

continuación se muestra una visión general simplificada de los principales contribuyentes al consumo de tiempo cuando se muestra un gráfico

Recuperar Definición: El tamaño y la complejidad de la Gráficos Archestra

El enlace de datos: Número de propiedades personalizadas y referencias

• Utilice una organización inteligente de la información: 1 número entero propiedad personalizada en lugar de 16 propiedades personalizadas

booleanas la hora de diseñar un símbolo que se utilizará en todas las gráficas de la aplicación (iconos, los estados de alarma)

• Trate de evitar la información redundante mediante la reutilización de las propiedades personalizadas para los símbolos incrustados. El uso

inteligente de privado / público

• Ser propietario de usar Objeto / setCustomProperty / ShowGraphic

• opciones de hardware que pueden proporcionar mejores resultados para Recuperar y encuadernación son:

o Relojes CPU rápida - más rápido de doble núcleo es mejor que el de cuatro núcleos más lento.

o Tienen 3 o 4 GB disponibles para cada sesión de Vista

o Rápido disco duro - discos de estado sólido

o Rápido GPU - Uso de la experiencia de Windows y vistazo a los gráficos y juegos

Gráficos puntajes.

Tiempo de renderizado: Número total de simples y complejos elementos gráficos, tiempo de ejecución efectos gráficos

El tiempo de renderizado se ve afectada por el elevado número de primitivas invoca: cada uno de una sola línea, círculo, cuadro de texto que estamos

dibujo tiene un costo.

• Extremadamente alta definición de los pequeños detalles pueden afectar el rendimiento de la representación

• Reutilizando varias veces un pequeño icono símbolo extremadamente alta detallada puede reducir el rendimiento de la representación de

toda la aplicación

• Gradientes, transparencias, efectos gráficos que el cálculo necesidad de tiempo de ejecución puede afectar el rendimiento de

procesamiento (CPU vs GPU: GDI + vs GDI)

o Unidad de Procesamiento Central vs unidad de procesamiento gráfico: La GPU mejora la

capacidades de la CPU

o La última versión de la interfaz de dispositivo gráfico es una mejora en GDI como

cepillos de degradado, mezcla alfa, y más apoyo formato de imagen

Página 21 de 29
 • Tenga cuidado de un mayor número de pequeños elementos gráficos utilizando gradientes. El efecto puede ser mínimo, pero visualmente

severa en términos de rendimiento.

• Cambiar el tamaño de los gráficos no reduce el tiempo necesario para la carga, ya que el sistema todavía tiene los mismos detalles, los

mismos cálculos, mismo costo, pero diferente valor visual. A veces puede ser digno de mostrar una imagen PNG en lugar de una pequeña

gráfica.

• Reducir detalle de fondo tanto como sea posible - Manual HMI / HMI eficiente aconsejó en el fondo limpio. La ganancia de

rendimiento puede ser enorme. Tener agujas sobre un fondo de calibre (el aspecto de un cuentarrevoluciones) es pesado en el

rendimiento en comparación con los que tienen agujas en movimiento sobre un fondo gris. Una prueba con 134 instancias en 1

ventana mostró una diferencia de: uso de la CPU 80% para el uno con el fondo de calibre, y uso de la CPU 3% para las agujas

en un fondo gris. Por ejemplo:

En espera de los datos: ciclo del motor, que la velocidad de O, la estrategia / Comunicación

• Esta sección está a la espera de nuevos valores para los datos.

• ActiveAll reduce la llamada hasta el tiempo de la gráfica

Expresión de evaluación: Número total, la complejidad, la eficiencia del código

• expresiones múltiples variables - cada variable deben ser suscritas, atados y publicados de forma individual. Por lo tanto, las

expresiones son scripts ad-hoc que requieren la ejecución. El AppEngine se adapta mejor a la ejecución de los volúmenes de

guiones y debe manejar la carga siempre que sea posible.

• Tenga en cuenta que una referencia es más rápido que una expresión en tiempo de ejecución. es decir, “True” es más rápido a la carga en

tiempo de ejecución en lugar de “1 == 1”.

• También mirar las animaciones o condiciones que pueden agruparse, trabajar con la lógica de que 10 es mejor que 100 cálculos.

Así que si múltiples animaciones pueden trabajar de la misma condición o referencia a continuación, utilizar este.

• Recuerde, la incrustación tiene un costo en el rendimiento, por lo que no puede haber un efecto negativo de la incrustación de un

gráfico que es sólo una línea o una adición muy pequeña, puede ser digno de dibujo ese elemento en el gráfico principal para

reducir la cantidad de incrustación.

• guiones dataChange siempre son preferibles a que los scripts se ejecuta como expresiones sólo se evalúan en el cambio de

datos, no siempre.

Delta Representación: Número de cambios de datos + total de simple y elementos gráficos complejos, los efectos de tiempo de ejecución, etc.

Otras referencias están en Notas Técnicas:

Página 22 de 29
628 - Gestión de la comunicación avanzada para Servidor de aplicaciones

644 - Mejora de rendimiento de aplicaciones con gráficos ArchestrA

Rendimiento Manual alta de operador.

11.3. símbolo Wizards

Asistentes de símbolos dentro de los gráficos proporcionan la misma funcionalidad que Wizards objeto dentro de los objetos. funcionalidad

gráfica se puede añadir y quitar en tiempo de diseño. En tiempo de ejecución sólo los elementos necesarios son cargados en el sistema. Esto

puede ser utilizado para hacer gráficos que representan ligeras diferencias en objetos muy similares y reduce la necesidad de volver a dibujar y

volver a crear los gráficos.

11.4. Agrupamiento

Al dibujar un gráfico, es la mejor práctica para agrupar todas las partes estáticas (no animados) del gráfico en un solo grupo. Esto
reduce la carga en el motor gráfico cuando se representa el gráfico, como el motor gráfico dibujará el grupo como un único objeto,
en lugar de elementos gráficos individuales.

Tenga en cuenta Agrupación sí tiene un costo, tales como que tienen enormes cantidades de grupos para ningún uso en realidad puede ser perjudicial

para el rendimiento.

11.5. Los gráficos pequeños

Si se requiere un pequeño gráfico o un icono, crear el gráfico en el tamaño requerido. No es la mejor práctica para cambiar el tamaño de un gráfico

complejo a un tamaño más pequeño; esto es debido a que el motor gráfico hará que todos los elementos gráficos y animaciones, incluso si son demasiado

pequeñas para ser vistas.

11.6. Gráficos estándar

Gráficos estándar son símbolos que determinan el estilo de los objetos estándar, tales como botones, paneles, interruptores, etc. Los gráficos

deben ser creados en la caja de herramientas Gráfico y luego incorporados en otros gráficos como sea necesario. Gráficos que ya han sido

creados por entidades físicas, tales como una bomba, pueden ser clasificados como un gráfico estándar también. Debe tenerse en cuenta que si

se utiliza un símbolo de la biblioteca de símbolos por defecto y es necesario hacer cambios al símbolo, a continuación, una copia del símbolo debe

ser realizada y utilizada en lugar de editar el símbolo de base directamente. Si no se requieren cambios en el símbolo de base, entonces el

símbolo de base puede ser utilizado directamente.

La biblioteca de conocimiento de la situación ofrece una gran cantidad de gráficos que pueden ser la base de una norma. Estos gráficos utilizan la

tecnología de “Asistente de símbolos” para ser extremadamente herramientas configurables para representar gran parte del equipo común en un sitio.

También son totalmente compatibles con el equipo de Desarrollo Aveva. Ayuda configuración de los mismos está disponible haciendo clic derecho

cualquier gráfico en la caja de herramientas y seleccionando la opción “Símbolo de ayuda”.

11.7. Pop Up Gráficos

Pop gráficos son gráficos que combinan gráficos estándar para crear gráficos genéricos. Normalmente se utilizan este tipo de gráficos como gráficos

de la placa frontal para mostrar información sobre una entidad.

Página 23 de 29
 11.8. Gráficos específicos de objetos

Estos tipos de gráficos se construyen y se asignan a las plantillas que representan entidades físicas de la planta, por ejemplo: mezcladoras,

calderas, reactores, fermentadores, etc.

gráficos a objetos específicos se componen de gráficos estándar, gráficos y gráficos genéricos pop-up. Estos gráficos deben ser

conscientes objeto y normalmente utilizar referencias relativas (Me, MyContainer, MiArea etc.) para animarlos.

Página 24 de 29
12. Aplicación InTouch
12.1. Configuración general WindowViewer
Inicio de Windows se puede utilizar en lugar de scripts de inicio que exigen las ventanas deseadas.

Use “Alta Prioridad ventana Almacenamiento en caché” para dar prioridad a las ventanas más grandes que se conservan en la memoria. Esto puede

ayudar con las ventanas “pesados” para mejorar los tiempos de carga. Vea abajo:

• La cantidad total de memoria accesible a WindowViewer se ha extendido a los máximos por defecto.

• 2 GB en OS 32 bits; 4 GB en OS 64 bit

• El caché de memoria eliminará ventanas más antiguas de la memoria caché para hacer espacio para las nuevas ventanas se abre.

• Primero en entrar / primero en salir y el envejecimiento basada en el tiempo

• Ventanas que son de alta prioridad para el acceso rápido se pueden designar lo que se traducirá en ellos se consideran siempre

reciente.

Página 25 de 29
13. Aplicación OMI InTouch
InTouch OMI es la nueva interfaz de usuario que está disponible con la plataforma de Sistema de 2017. Si usted es un usuario de la plataforma de

sistemas con experiencia hay un curso de un día que le llevará hasta la fecha con Qué hay de nuevo en InTouch OMI: http://wonderware.co.uk/training/

13.1. Instalación de InTouch OMI

InTouch OMI no requiere que no sea el Bootstrap Archestra a instalar nada. La implementación de una plataforma, viewengine y
una instancia de una aplicación transfiere InTouch OMI e instala todos los componentes necesarios para ejecutar InTouch OMI.

13.2. Ejecución de InTouch OMI

A diferencia tradicional InTouch, múltiples sesiones y aplicaciones que utilizan InTouch OMI se pueden ejecutar simultáneamente en el

mismo sistema. Simplemente basta con abrir las aplicaciones de “Wonderware Application Manager”. No recomendaríamos ejecución de

más de 40 casos de InTouch OMI en un solo nodo ya que esto tiende a dar lugar a una degradación del rendimiento.

13.3. La vista del modelo y de InTouch OMI

InTouch OMI construye automáticamente su estructura de navegación para usted, basado en el modelo que se crea dentro del IDE

Plataforma del sistema. Esto significa que pensar por adelantado sobre su modelo de vista es especialmente importante si usted va a

utilizar InTouch OMI. Los objetos “área” van a servir como puntos focales para la navegación automática.

13.4. Gráficos de construcción para InTouch OMI

Una nueva opción existe dentro de InTouch OMI que le permite definir los tipos de contenido “” para los gráficos que haya creado.

Cuando se define un tipo de contenido para un gráfico a continuación, se puede utilizar para rellenar automáticamente las pantallas se

crean en InTouch OMI. Un gráfico puede tener uno o más tipos de contenido.

13.5. Pantalla Perfiles y Distribución

Dentro de la caja de herramientas gráfico que ahora tiene la opción de crear perfiles de pantalla y diseños. Un perfil de pantalla describe la

pantalla que una aplicación se aplicará a. Puede ser un sistema más amplio de resolución o abarcar varios monitores.

Diseños describen cómo van a ser dispuestos dentro de un perfil de pantalla de los gráficos y qué tipos de contenido se muestran en

qué lugares. Esto simplifica el proceso de creación de varias aplicaciones diseñadas para diferentes resoluciones. Los gráficos se

muestran en los paneles definidos en la disposición que se adapta para ajustarse al perfil de pantalla.

13.6. El espacio de nombres InTouch OMI

InTouch OMI no tiene un “diccionario tagname” como una aplicación tradicional InTouch hace. En cambio, tiene su propio espacio de nombres que

contiene información similar a las etiquetas de sistema dentro de una aplicación tradicional. El resultado de esto es que los gráficos que se

construyen con referencias a las etiquetas InTouch usando la sintaxis “En Contacto: <> Tagname” no funciona como se espera serán cuando se

utiliza con InTouch OMI. Usted tendrá que acceder al espacio de nombres InTouch OMI

Página 26 de 29
 13.6.1. Espacio de nombres de encargo ViewApp

La creación de etiquetas personalizadas en el espacio de nombres InTouch OMI es posible dentro de Plataforma del sistema de actualización de 2017

2. Si necesita variables locales en su aplicación InTouch (accesibles a todos los gráficos ArchestrA), entonces esta es la herramienta que debe utilizar.

Puede crear y gestionar estos espacios de nombres ViewApp en la Caja de Herramientas Gráfica. Véase más abajo ejemplo, espacios de nombres.

13.7. El uso de 3 rd Controles partido .Net

InTouch OMI no admite la incorporación directa de 3 rd partido .Net cliente controla. En su lugar hay un conjunto de herramientas que le

permite crear “Aplicaciones” utilizando los estándares de Windows Presentation Foundation (WPF). Si estás utilizando un control .Net

Cliente entonces usted tendrá que crear un envoltorio e importar la App en el IDE antes de clavarse en InTouch a OMI. Actualización 3

será la introducción de un asistente para ayudar con la envase de los controles .NET en WPF.

13.8. funciones útiles

La función ShowContent () se puede utilizar desde Update 2 en adelante. Esto permite especificar un fragmento de contenido (gráfico, ventana, aplicación)

a un panel específico dentro de la disposición. Por ejemplo, puede crear un desplazamiento personalizado en lugar de utilizar la aplicación de navegación.

es decir, al hacer clic en el botón de mi alarmas, que puede entonces mi escritura indicador de alarma para mostrar en el panel banner superior cuando se

hace clic en el botón, en lugar de utilizar una ventana emergente.

Página 27 de 29
14. Rendimiento y métricas
Algunos atributos Visor de objetos que se pueden ver a revisar el desempeño y escala.

14.1. Plataforma general Métrica

Cargando CPU:

• cpuload,
• CPULoadAvg,

• CPULoadMin,
• CPULoadMax.

Memoria:

• RAM,
• RAMAvailableAvg.

S de disco:

• DiskBytesReadAvg [],

• DiskBytesWritesAvg [],

• DiskReadsAvg [],

• DiskWritesAVG [].

14.2. Avanzado motor Mediciones de

aplicaciones métricas del motor:

• Scheduler.ScanPeriod,

• Scheduler.TimeIdleAvg (debería ser 50% mínimo del período Scan),

• Scheduler.TimeIdleMax,

• Scheduler.TimeIdleMin,
• Scheduler.ExecutionTimeAvg.

Cargando CPU:

• ProcessCPULoad,

• Scheduler.ScanOverrunsCnt (no siempre es una cosa terrible),

• Scheduler.ScanOverrunsConsecCnt (Éste es mucho más grave).

Motor de la Escala:

• Engine.AsyncScriptsWaitingCnt,

• Engine.EngineAlarmRate (El número de alarmas planteadas en este objeto durante la exploración previa de todos los objetos

que se ejecutan en este objeto), CheckpointPeriodAvg.

Página 28 de 29
El documento ha sido proporcionada sujetas a las siguientes salvedades:

• El documento es sólo para fines de asesoramiento y no garantiza el rendimiento del sistema. Como tal, no hay aceptación del

riesgo o responsabilidad en nombre de SolutionsPT.

• Este compromiso no constituye la de una autoridad de diseño y las observaciones de SolutionsPT en este
documento no son los de AVEVA y son, por tanto, no necesariamente apoya o patrocinado por AVEVA.

• Se supone que el lector de este documento está familiarizado con el entorno de trabajo de los sistemas operativos de Microsoft

y las suites de productos de referencia de Wonderware.

• Este documento debe considerarse como siempre en desarrollo y no es una guía completa; como tal, está sujeto a
cambio.
• Este documento cubre la Wonderware System Platform 2017 Update 2.

Página 29 de 29