System Platform contempla la posibilidad de incluior varios niveles de redundancia y alta disponibilidad a los proyectos. Estos niveles son:
Redundancia a nivel comunicaciones. System Platform incluye el objeto Redundan Device Integration Object (RDI Object). En caso de que un PLC tenga dos redes de comunicación disponibles, si un canal falla el RDI Object permite conmutar automáticamente a la otra red, evitando la pérdida de comunicación.
Redundancia a nivel aplicación. System Platform incorpora un sistema de Redundancia automática. Es decir, no es necesario desarrollar un Scripting específico para esta funcionalidad, sino que solo se tendrá que activar la redundancia en el objeto "engine" para que esté operativa.
Desde el punto de vista de licencias software, esta activación es transparente a nivel objetos.
Desde un punto de vista económico es importante señalar que la redundancia a nivel Software es una funcionalidad más incluida en la licencia de System Platform. Es decir, no es necesario la adquisición de una "Licencia Redundante" para activarla. Solo se necesita un elemento Hardware adicional (un servidor).
La redundancia funciona de la siguiente manera. Existen dos servidores, uno primario y otro esclavo. Los servidores ejecutan al mismo tiempo todas las operaciones (es decir, se realiza un despliegue doble de objetos) que permiten que la aplicación esté en marcha. Se almacenan históricos y registros de alarmas, se gestionan las comunicaciones con la Red de Campo, se gestiona la configuración de seguridad, se gestiona el funcionamiento de la aplicación.
Si el servidor primario cae, automáticamente (en caliente) el servidor esclavo toma el control de la aplicación sin perder datos y aportando alta disponibilidad a la aplicación. Una vez que el primario se recupera, los dos servidores vuelven a funcionar simultáneamente.
Desde el punto de vista de desarrollo, la redundancia se activa a través de un “clic”. Es decir no hay que desarrollar código a medida para llevarla a cabo. Esto hace que la aplicación sea muy robusta. Es la propia plataforma software la que facilita esta funcionalidad y no el código desarrollado para una aplicación específica.
System Platoform permite aprovechar la redundancia para realizar balanceo de cargas. Es decir, se podrían utilizar los dos servidores para repartir la carga Ej. el 70% de los objetos corren en el servidor activo y el 30% en el esclavo, y configurar la redundancia para que cualquiera de los dos hiciera de backup en caso de caída de uno de ellos.
Alta disponibilidad de históricos. En cuanto a la redundancia de históricos, se recomienda que el servidor de Base de Datos se configure de forma independiente de los servidores de objetos.
Los objetos recogen la información y esta información se almacena en la Base de Datos.
Si el Servidor de Base de datos cayera, el propio objeto sería el que recogería la información y la almacenaría como buffer en el disco duro del servidor de objetos. Tras recuperarse, enviaría estos datos al servidor de históricos. Es decir, el propio sistema incorpora de esta manera una forma de redundancia de históricos embebida en la propia configuración de los objetos.
Se asegura que en ningún caso, se pierdan datos.
Redundancia a nivel de interfaz de visualización y control. La solución que se propone se basa en arquitecturas Terminal Services. En un servidor con sistema operativo servidor Windows se instalan sesiones (InTouch for SP for Terminal Services) que permiten la visualización y control de los procesos. (NOTA: En este servidor deberán instalarse también las licencias de MS Terminal Services).
m
El acceso a este servidor, y por tanto a las sesiones, se realiza desde el escritorio remoto que Windows incorpora de forma estándar. Las sesiones terminal services podrán ser por usuario logado o bien concurrentes. En paralelo se activa otro servidor en el que se instalan las mismas sesiones (en este caso Wonderware hace un descuento del 80% sobre el precio de las licencias). Si el servidor primario cae, el operario puede redirigir su petición al servidor secundario, haciendo así que en ningún caso se pierda visibilidad sobre el proceso.
m
- Redundancia a nivel comunicaciones.
- Redundancia a nivel aplicación.
- Alta disponibilidad de históricos.
- Redundancia a nivel de interfaz de visualización y control.
Redundancia a nivel comunicaciones. System Platform incluye el objeto Redundan Device Integration Object (RDI Object). En caso de que un PLC tenga dos redes de comunicación disponibles, si un canal falla el RDI Object permite conmutar automáticamente a la otra red, evitando la pérdida de comunicación.
Redundancia a nivel aplicación. System Platform incorpora un sistema de Redundancia automática. Es decir, no es necesario desarrollar un Scripting específico para esta funcionalidad, sino que solo se tendrá que activar la redundancia en el objeto "engine" para que esté operativa.
Desde el punto de vista de licencias software, esta activación es transparente a nivel objetos.
Desde un punto de vista económico es importante señalar que la redundancia a nivel Software es una funcionalidad más incluida en la licencia de System Platform. Es decir, no es necesario la adquisición de una "Licencia Redundante" para activarla. Solo se necesita un elemento Hardware adicional (un servidor).
La redundancia funciona de la siguiente manera. Existen dos servidores, uno primario y otro esclavo. Los servidores ejecutan al mismo tiempo todas las operaciones (es decir, se realiza un despliegue doble de objetos) que permiten que la aplicación esté en marcha. Se almacenan históricos y registros de alarmas, se gestionan las comunicaciones con la Red de Campo, se gestiona la configuración de seguridad, se gestiona el funcionamiento de la aplicación.
Si el servidor primario cae, automáticamente (en caliente) el servidor esclavo toma el control de la aplicación sin perder datos y aportando alta disponibilidad a la aplicación. Una vez que el primario se recupera, los dos servidores vuelven a funcionar simultáneamente.
Desde el punto de vista de desarrollo, la redundancia se activa a través de un “clic”. Es decir no hay que desarrollar código a medida para llevarla a cabo. Esto hace que la aplicación sea muy robusta. Es la propia plataforma software la que facilita esta funcionalidad y no el código desarrollado para una aplicación específica.
System Platoform permite aprovechar la redundancia para realizar balanceo de cargas. Es decir, se podrían utilizar los dos servidores para repartir la carga Ej. el 70% de los objetos corren en el servidor activo y el 30% en el esclavo, y configurar la redundancia para que cualquiera de los dos hiciera de backup en caso de caída de uno de ellos.
Alta disponibilidad de históricos. En cuanto a la redundancia de históricos, se recomienda que el servidor de Base de Datos se configure de forma independiente de los servidores de objetos.
Los objetos recogen la información y esta información se almacena en la Base de Datos.
Si el Servidor de Base de datos cayera, el propio objeto sería el que recogería la información y la almacenaría como buffer en el disco duro del servidor de objetos. Tras recuperarse, enviaría estos datos al servidor de históricos. Es decir, el propio sistema incorpora de esta manera una forma de redundancia de históricos embebida en la propia configuración de los objetos.
Se asegura que en ningún caso, se pierdan datos.
Redundancia a nivel de interfaz de visualización y control. La solución que se propone se basa en arquitecturas Terminal Services. En un servidor con sistema operativo servidor Windows se instalan sesiones (InTouch for SP for Terminal Services) que permiten la visualización y control de los procesos. (NOTA: En este servidor deberán instalarse también las licencias de MS Terminal Services).
m
El acceso a este servidor, y por tanto a las sesiones, se realiza desde el escritorio remoto que Windows incorpora de forma estándar. Las sesiones terminal services podrán ser por usuario logado o bien concurrentes. En paralelo se activa otro servidor en el que se instalan las mismas sesiones (en este caso Wonderware hace un descuento del 80% sobre el precio de las licencias). Si el servidor primario cae, el operario puede redirigir su petición al servidor secundario, haciendo así que en ningún caso se pierda visibilidad sobre el proceso.
m
No hay comentarios:
Publicar un comentario