System Platform 3.1. Arquitecturas distribuidas y Centros de Control

System Platform permite desarrollar aplicaciones distribuidas utilizando una sóla licencia. Es decir , el modelo lógico de objetos es totalmente independiente del modelo Hardware. Una vez que se desarrolla la aplicación (objetos + modelo), se decide sobre que plataforma hardware se instala. El software no está ligado a un Hardware (los objetos podrán ejecutarse en cualquier PC conectado a la Red).

n
Es importante señalar que System Platform puede ejecutarse también en un MONOPUESTO. No es necesario desplegar una arquitectura distribuida de aplicación. Dependiendo del tamaño de la aplicación, se verá la conveniencia de ejecutarlo de manera más o menos distribuida.

El no estar ligado a una Arquitectura fija, ya que los objetos pueden distribuirse sobre cualquier PC, hace que el proyecto asuma la característica de alta disponibilidad. Es decir, se puede desarrollar una nueva funcionalidad de la aplicación y luego ponerla en marcha, sin que el sistema deje de funcionar. Solo se tendrán que ejecutar los nuevos objetos desarrollados.
n
Esta independencia hace que en caso de que un determinado servidor pudiera estar saturado, lo único que se debe hacer es, desde la herramienta de desarrollo, hacer que una serie de objetos se ejecuten en otro servidor. Desde el punto de vista de visualización, control y recolección de históricos, este proceso de distribución de cargas es transparente.
n
El mercado está demandando la capacidad de Desarrollar Salas de Control de entornos distribuidos de forma sencilla. Esta sala de control debe tener la capacidad de permitir que la aplicación sea desarrollada tecnológicamente desde un único sitio (en este caso llamamos aplicación a desarrollo de Software, Instalación de Drivers de forma remota, Mantenimiento de Hardware…) y además permita a un usuario visualizar y controlar de una forma operativa, toda esa aplicación desarrollada.
n
Del mismo modo, este desarrollo remoto, no debe estar condicionado a potentes comunicaciones. Se debe tener la capacidad de realizar este desarrollo y este mantenimiento con redes de banda baja (a nivel MODEM). La creación de centros de control con System Platform se realiza de forma eficiente gracias a las características de su tecnología:

• Posibilidad de contar con una licencia corporativa que sea desplegada entre diferentes plantas o infraestructuras (desde 250 señales hasta 1.000.000). System Platform permite la posibilidad de utilizar la solución System Platform Single Node para utilizar una sola máquina para el despliegue de objetos.
• Crear un centro de control de forma modular. Por ejemplo, comenzando con la consolidación de datos de proceso o instalaciones en un repositorio único, para luego hacer una visualización y control conjunta vía sinópticos, para terminar con la introducción de funcionalidades MES, gestión eficiente de recursos energéticos o integración con herramientas de mantenimiento.
• Capacidad para tomar datos de diferentes SCADA´s y dispositivos de campo (vía OPC, mediante drivers, conversores, gateways, etc).
• Administrar de forma centralizada, tanto a nivel usuario final, como a nivel desarrollo toda la aplicación.
• Utilizar la tecnología Terminal Services para acceder de forma remota a las instalaciones de forma concurrente.
• Una problemática habitual consiste en la necesidad de tener datos históricos locales para luego agrupar estos datos en un histórico central. Es decir, distribuir varios Históricos en plantas locales para que estos datos se consoliden en uno central de forma automática. La plataforma incluye la opción de Tier Historian que facilita la integración de Historian distribuidos en un Historian Central.

n

Procesadores VLIW

Los procesadores Very Long Instruction Word (VLIW, Palabra de Instrucción Muy Larga), estuvieron unos años casi en desuso pero han vuelto a estar de actualidad porque han inspirado el diseño de las arquitecturas como la del Itanium (arquitectura EPIC), que han resuelto la mayor parte de los problemas que presentaban los antiguos diseños VLIW.

En este tipo de arquitecturas el compilador empaqueta un conjunto instrucciones que pueden ejecutarse en paralelo en una única instrucción muy larga. Es decir, el compilador especifica explícitamente el paralelismo en cada instrucción, no es una responsabilidad del procesador. Para mantener todas estas unidades funcionales del procesador ocupadas, el paralelismo inherente al código tiene que ser alto. Es habitual utilizar técnicas que lo aumenten como el desenrollado de bucles, la reordenación del código, la ejecución de predicados, etc.

El principal problema de este tipo de arquitectura ha estado tradicionalmente en el tamaño de los códigos, ya que en cada instrucción suelen quedar huecos al ser imposible empaquetar siempre sub-instrucciones que rellenen palabras de instrucción muy largas por completo debido a los riesgos. Estos huecos ocupan espacio en la memoria innecesariamente.

Además, existen problemas de compatibilidad entre diferentes arquitecturas. Incluso entre diferentes implementaciones de la misma arquitectura (una nueva unidad funcional ó una latencia diferente para alguna de las unidades, por ejemplo), sería necesario recompilar el código para planificar adecuadamente las sub-instrucciones.

Los procesadores VLIW han sido una buena opción para el diseño de sistemas empotrados, ya que consiguen la emisión múltiple de instrucciones con menor consumo de potencia que otro tipo de diseños en los que la responsabilidad de la planificación recae sobre el hardware. Pero no se han utilizado mucho en otro tipo de sistemas, en los que se ha comprobado que cuando un procesador VLIW puede conseguir un rendimiento alto, también puede hacerlo casi siempre un procesador vectorial, con un diseño de compilador y del propio procesador bastante más sencillo.
aaa

Wonderware. Opciones de visualización, control y gestión de la información

Durante mis últimas reuniones me he encontrado con el problema de tener que explicar a algunos integradores y clientes finales, las diferentes opciones de visualización, control y gestión de la información que Wonderware proporciona.

Las siguientas tablas tienen como fin facilitar información acerca del tipo de funcionalidad y tipo de acceso que incluyen las diferentes soluciones Wonderware.

Podéis bajaros este documento accediendo a este link: Opciones de visualización, control y gestión de la información proporcionadas por Wonderware.

Evento. ANACAP 2009.

Los días 19 y 20 de Noviembre se celebra en la Universidad Rey Juan Carlos de Madrid (Campus de Móstoles), el segundo Workshop en Aplicaciones de Nuevas Arquitecturas de Consumo y Altas Prestaciones.

El ANACAP surgió el año pasado con la idea de ser un punto de encuentro de investigadores nacionales que usen estas tecnologías para acelerar sus soluciones algorítmicas, así como un foro para promover e incentivar nuevas propuestas de cómputo optimizado para diferentes aplicaciones, visión artificial y procesamiento de imagen especialmente.

Ya sabéis que además de las presentaciones de los artículos admitidos en esta edición, y de las presentaciones realizadas por las empresas patrocinadoras, por las tardes hay programados tutoriales muy interesantes acerca de GPGPU y CUDA, programación con OpenMP y programación del procesador Cell de la consola PlayStation 3.

Os dejo en enlace a la web del congreso por si queréis consultar el programa:

http://www.gavab.es/capo/anacap/index.html
aa

Actionable Enterprise Architecture (AEA)

El concepto de Enterprise Architecture (EA) define los procesos, entradas, infraestructura tecnológica, componentes software, servicios y roles que permiten conseguir los objetivos estratégicos de la organización. Esta arquitectura también debe definir las relaciones y jerarquías entre todas estas partes involucradas en el negocio.

m
En EA se definen cuatro categorías de elementos reutilizables:

• Arquitectura estratégica. En la que se incluye la visión, los objetivos organizativos y los planes estratégicos y operativos que permitan alcanzar dichos objetivos.
• Arquitectura de negocio. Entendiendo este elemento como el conjunto de productos, servicios, capacidades, roles y localizaciones de la organización.
• Arquitectura de sistemas. Incluyendo los procesos de negocio, sistemas de información y personas que soportan el desarrollo de la arquitectura de negocio.
• Arquitectura tecnológica. Siendo este elemento el conjuntode dispositivos hardware y soluciones software sobre las que se ha desarrollado la arquitectura de sistemas.

El modelo de gestión AEA (Actionable Enterprise Architecture) permite alcanzar los objetivos organizativos en tiempo real, gestionando eficientemente los procesos de negocio, cuyas actividades son ejecutadas por sistemas de información.

m

RAM estática vs RAM dinámica

En alguna ocasión me habéis preguntado por la diferencia entre una memoria RAM estática (SRAM) y una memoria RAM dinámica (DRAM), ya que os habéis encontrado con estos términos en las especificaciones de un sistema. Intentaré aclararlo en esta entrada con conceptos muy sencillos.

Las memorias RAM (Random Access Memory) son aquéllas que permiten acceder a una posición aleatoria de la memoria para leer o escribir en ella sin necesidad de acceder previamente a todas las anteriores. Es decir, se puede indexar directamente la fila y la columna en la que está almacenada la información a la que se desea acceder ya que los datos se almacenan en estas memorias en forma de matriz.

La diferencia entre una RAM estática y una RAM dinámica está en la tecnología que se utiliza para construirla. En una RAM estática son necesarios 6 transistores para almacenar 1 bit de información, mientras que en una RAM dinámica son necesarios 1 transistor y 1 condensador. Es decir, mucha menos lógica, por eso en el mismo área de una DRAM cabe más información que en una SRAM.

Entonces, ¿por qué se utiliza la tecnología SRAM?. Principalmente por dos motivos. Al estar fabricada sólo con transistores, se puede integrar en el mismo chip que un procesador, por ejemplo, construido también sólo con transistores.

Pero, el principal motivo es que es una memoria mucho más rápida que la DRAM ya que no necesita ciclos de refresco. La información almacenada en una celda SRAM no se pierde con el tiempo, sin embargo, la almacenada en una celda DRAM sí, ya que el condensador se descarga con el tiempo. Esto obliga a invertir tiempo en leer lo que está almacenado en la memoria antes de que los condensadores se descarguen y a reeescribirlo para que la información no se pierda (refresco), lo que ralentiza el funcionamiento de la memoria.

Para que tengáis un ejemplo que os resulte familiar, en las jerarquías de memoria que incorporan los PCs y los portátiles, se utiliza SRAM para la memoria caché (integrada con el procesador, pequeña y muy rápida) y DRAM para la memoria principal (en otro circuito externo, de mayor capacidad y más lenta).

yy

Evento. DISI 2009.

El DISI 2009, en su cuarta edición, se celebrará el lunes 30 de noviembre de 2009 a partir de las 09:00 en el Salón de Actos del Campus Sur de la UPM, Universidad Politécnica de Madrid.

Se trata del Día Internacional de la Seguridad de la Información, que se lleva celebramdo desde el año 1988. En esta edición un prestigioso investigador de IBM Research Estados Unidos abrirá el evento con la conferencia Randomized Hashing: Secure Digital Signatures without Collision Resistance (en castellano). A continuación se celebrarán dos coloquios, el primero sobre Tndencias en el Malware y el segundo sobre Mitos y Realidades en Hacking. El evento terminará a las 15.00.

La asistencia al evento es totalmente gratuita previa inscripción en

www.capsdesi.upm.es

O por teléfono contactando con Beatriz Miguel en el número 913367842.
tt

System Platform 3.1. Niveles de Redundancia

System Platform contempla la posibilidad de incluior varios niveles de redundancia y alta disponibilidad a los proyectos. Estos niveles son:

• 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