Contexto General

El concepto de modelo SCADA de clases y objetos es algo muy consolidado en las plataformas SCADA de la suite Proficy. En concreto, en Cimplicity es algo nativo desde hacce muchas versiones; mientras que en iFIX es algo que comenzó a incorporarse en v6.5.


La hoja de ruta de GE es la de desplegar progresivamente este mismo concepto en todos los productos de la suite. Para ello, se va a utilizar Configuration Hub como el entorno de gestión de modelos.


Nota: Conviene señalar que en el caso particular de Cimplicity, el concepto de clases y objetos está implementado en un formato algo distinto, por ser muy anterior a la creación de Configuration Hub. Esto es algo que probablemente irá evolucionando con los años hasta converger en un mismo formato para todos los productos de la suite Proficy. 


En el caso de Proficy Historian, exite ya el concepto de modelo. Utiliza un formato muy similar al de iFIX y, como en éste, se gestiona desde Configuration Hub. Como en iFIX, el modelo en Historian es algo que puede utilizarse para registrar nuevas señales a historizar, o bien para agrupar o organizar las señales ya registradas, en este caso a modo de "Aliases" de Historian.


Implementación práctica

Siguiendo la misma nomenclatura aplicada para iFIX, en Historian tenemos "Types" (Clases) y "Objects" (instancias). Dentro de éstas podemos tener variables directas, indirectas y estáticas. 


La diferencia en Historian respecto a iFIX es que vemos que

  • los Types no admiten "substitutions". 
  • No podemos declarar las direcciones de las variables a nivel de Type, sino que se debe hacer a nivel de Objeto, ya sobre las variables concretas. 


La definición de los tres tipos de variables la tenemos recogida en los siguientes enlaces:


Parametrización de variables directas
Aquí apuntaremos a un colector y desde él haremos un browse para identificar lo que queramos.
El resultado será un nuevo tag en Historian


Ejemplo de variable directa
Vemos que a nivel de instancia declaramos toda la adquisición (parámetros de la columna dereceha)
Este es el procedimiento en caso de que se trate de un tag nuevo, no colectado por Historian todavía.
Información mínima a definir:
y el resultado es un nuevo tag en Historian:


Parametrización de variables indirectas
Aquí apuntamos un tag que ya esté siendo colectado por historian (algo que ya tuviese definido el colector. Seguramente por elevación desde el SCADA de turno)

Ejemplo de variable indirecta
Este caso es análogo, pero la diferencia es que estaremos referenciando a tags que ya están siendo historizados en Historian (por tanto ya están declarados en el listado de tags del servidor). 
Por consiguiente, el menú de parámetros es mucho más sencillo:
Como estamos apuntando a un tag que ya existe, el sistema nos ofrecerá la posibilidad de renombrar el tag que ya tenemos, o de aplicar un "alias" a este tag ya creado.
En el caso de que seleccionemos la opción "create alias" el resultado es que el tag pasa a tener un alias diferente. Pasará de llamarse "SCADA15.Simulation Examples.Function.Random4" a llamarse "TestObj01>Variable02":


Parametrización de variables estáticas
Estas son variables bidón. No se contabilizan en Historian sino que quedan a nivel de la BDD PostgreSQL que alberga el modelo

Ejemplo variable estática
Este caso simplemente declaramos un valor estático, que no se define como Historian tag, sino que queda en la BDD postgreSQL que alberga el modelo.



El resultado

Cuando se consulte la información en Historian desde un cliente, se podrá acceder al listado plano de tags tradicional, o bien acceder al modelo de objetos. Éste permitirá una organización semántica y jerárquica de los tags, lo cual puede facilitar en buena medida las búsquedas y la comprensión de la naturaleza de los tags. 


Un ejemplo rápido lo tenemos en la vista "Data" del plugin de Historian en Configuration Hub
(en el ejemplo de la imagen, se trata del mismo servidor Historian de los ejemplos anteriores, en el que únicamente hay 1 objeto de 1 clase, con 3 variables. Este modelo de objetos suele extenderse a múltiples objetos y clases para representar sistemas con un elevado volumen de señales)