redindustria

Previsión cifras macroeconómicas 2013

Fuentes:

Instituto de Empresa; http://economy.blogs.ie.edu/archives/2012/10/perspectivas-economicas-para-2013.php
Funcas; www.funcas.es/Indicadores/Indicadores.aspx?Id=1

Cloud Computing en entornos industriales. SCADA as a Service

Los conceptos y tecnologías asociados al paradigma Cloud Computing se encuentran cada vez más arraigados en la implantación y despliegue de sistemas de información. En el ámbito industrial su introducción está siendo más lenta, pero las tendencias indican que el modelo Cloud Computing se extenderá en breve a todos los entornos tecnológicos, incluido el nuestro.

Es por ello que creímos conveniente realizar un seminario sobre Cloud Computing en el que se proporcionara una visión general de los conceptos tecnológicos y de negocio asociados a los sistemas Cloud y su aplicación en entornos de gestión en tiempo real, en concreto en entornos de tipo industrial.

A este seminario acudieron diferentes integradores, entre los que se encontraban Acisa, CMC, Elecpa, FCC Industrial, Nucleo y Sampol.

Durante la última parte del seminario analizamos que el desarrollo de proyectos SCADA lleva asociadas una serie de características que deben considerarse a la hora de decidir la forma de realizar un proyecto utilizando para ello:

Un entorno tradicional "in house" con soluciones a medida, utilizando productos de una software factory o desarrollando sobre plataformas de código libre.
Un entorno Cloud.

Las características principales que analizamos fueron:

El cumplimiento de latencias.
La fiabilidad del sistema, entendiendo como fiabilidad el grado de determinismo de la solución.
La disponibilidad de la plataforma hardware sobre la que se despliega el proyecto.
La disponibilidad de la red de comunicaciones.
La gestión de entornos distribuidos.
La gestión de eventos.
La gestión de grandes volúmenes de información.
La utilización de protocolos específicos del sector industrial y de infraestructuras.
La seguridad de los sistemas.
La integración con otros tipos de sistemas tiempo real o transaccionales.

A continuación debatimos acerca de qué características pueden gestionarse de manera más eficiente dependiendo del entorno utilizado (tradicional&Cloud). En general hubo consenso en determinar que:

El cumplimiento de latencias, la fiabilidad del sistema, la disponibilidad de la red de comunicaciones, los protocolos específicos y la integración con otros sistemas se resuelven mejor utilizando un entorno tradicional. Aunque en este último caso hay que considerar que el paso a soluciones Cloud implica cierto grado de estandarización (servicios web, virtualización, etc) que puede favorecer esta integración.
Mientras que la disponibilidad de la plataforma hardware, la gestión de entornos distribuidos y la gestión de grandes volúmenes de información son características que en un entorno Cloud, se gestionarían mejor.
La seguridad fue la característica que más debate levantó. De hecho no llegamos a ninguna conclusión consensuada por la disparidad de opiniones que se expresaron. Algunos de los integradores comentaron que un entorno Cloud les parece más seguro ya que la inversión en seguridad informática para los sistemas locales por parte de las empresas es muy escasa. Otros sin embargo, mantenían que el hecho de tener el sistema de forma propietaria facilita la gestión de la seguridad si ésta se lleva a cabo.

En la siguiente figura hemos resumido las ideas arriba expuestas.

A la conclusión que llegamos es que sigue habiendo mucha desconfianza por parte de los clientes a la hora de "perder el control" de sus sistemas core y por ende, de utilizar sistemas tipo Cloud en el ámbito industrial. Después de analizar diferentes posibilidades de despliegue e integración, parece que todos los integradores coincidieron en que la introducción de soluciones híbridas en las que se mantenga el núcleo del SCADA tradicional en sistemas propietarios de los clientes, pero complementado con soluciones en la nube de Real Time Information as a Service, Analytics as a Service, Historian as a Service, etc; parece un primer paso que aporta valor y diferenciación y que permite familiarizar poco a poco a los clientes con el nuevo paradigma.

¿Qué es MapReduce?

Ya hemos hablado en entradas anteriores de las aplicaciones de Big Data. Este tipo de aplicaciones suelen explotar el paralelismo de datos, de manera que diferentes núcleos de procesador, procesadores o nodos de cómputo (dependiendo de la arquitectura que haya por debajo) realicen las mismas tareas sobre conjuntos de datos diferentes para producir un resultado en el menor tiempo posible,

MapReduce es un framework o entorno de desarrollo (pensado para lenguaje C inicialmente, aunque luego se han implementado versiones para otros lenguajes como Java) que permite trabajar en paralelo con grandes cantidades de datos en sistemas de memoria distribuida (clusters, sistemas Grid y entornos Cloud).

Con este entorno tanto los datos de entrada como los de salida (los resultados) se almacenan en ficheros, así como todos los resultados intermedios que se produzcan. Se basa en el modelo maestro/esclavo, de manera que uno de los nodos de cómputo lleve el control del programa y vaya enviando trabajo al resto de los nodos (los esclavos) según vayan quedando libres. Se ofrecen dos interfaces a los programas de usuario: el de Map y el de Reduce. El interfaz Map mapea los datos iniciales que aparecen en el fichero de entrada a pares clave/valor intermedios con los que sea más fácil trabajar. Después de ordenar, agrupar, filtrar, etc; estos pares con interfaces internos, el interfaz Reduce, reduce de alguna forma los pares intermedios a un conjunto de datos menor que el inicial en el que se agrupan los que comparten la misma clave. El ejemplo típico es el de la cuenta de palabras (está extraído de este enlace).

MapReduce nos facilita las siguientes tareas:

Particionamiento de datos y de cómputo.
Tratamiento de ficheros de entrada y de salida.
Sincronización (hasta que todos los esclavos no terminan de hacer el Map, no se comienza con las tareas de Reduce).
Comunicación (que se realiza mediante RPC).
Sort y Group (interfaces internos para trabajar en paralelo con los grandes conjuntos de datos).
Map y Reduce (interfaces externos disponibles para los programas de usuario).

En futuras entradas hablaremos de las implementaciones que existen de este framework en la actualidad y haremos una comparativa entre ellas.

NoSQL

Con este término nos referimos a sistemas de gestión de bases de datos que no utilizan el lenguaje de consultas SQL ya que la información, a diferencia de en los sistemas relacionales clásicos se almacena de manera estructurada pero no obligatoriamente en forma de tablas (existen bases de datos de documentos, de objetos, de pares clave-valor, aunque también las hay tabulares).

Las bases de datos NoSQL no suelen garantizar completamente las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad), pero presentan la ventaja de estar muy optimizadas para realizar las operaciones de recuperar y agregar información en tiempo real, son altamente escalables y el tiempo de proceso no es un cuello de botella ni siquiera manejando grandes cantidades de datos.

Esto ha hecho que en entornos de Big Data (de los que ya hemos hablado en entradas anteriores) se haya optado en muchos casos por estos tipos de bases de datos, ya que las tres Vs (velocidad, volumen y variedad) hacen que el modelo de datos típico en estos entornos pueda aprovechar a la perfección estas características.

Tanto las grandes compañías del mundo de las redes sociales (Twitter y Facebook) como otras grandes de Internet (como Google o Amazon) han optado por este tipo de bases de datos para algunas de sus aplicaciones. E incluso en algunos casos, han diseñado sus propios sistemas de gestión. Hablaremos de alguno de ellos en futuras entradas.

Autonomic Computing

El número de nodos de los sistemas distribuidos en muchos de sus campos de aplicación está creciendo de manera espectacular en los últimos años. Este crecimiento añade una gran complejidad a la gestión de los sistemas, y en muchos casos, es esta complejidad la que limita el crecimiento de las infraestructuras tecnológicos y no, como se podría pensar sus costes o sus consumos energéticos.

Cuando se habla de Autonomic Computing, concepto introducido en el año 2001 por IBM, se trata de diseñar sistemas que se autogestionen de manera que se reduzca la complejidad de su integración, gestión y operación. Los sistemas autónomos deben cumplir, como mínimo tres propiedades: la automatización, la capacidad de adaptación y la conciencia del entorno.

Aunque existen diferentes aproximaciones al problema, este tipo de sistemas suele basar su diseño en el sistema nervioso humano y en la implementación de bucles de control que permitan realizar ciclos de monitorización, análisis, planificación, ejecución y predicción cuyos objetivos sean la auto-protección, la auto-configuración, el auto-mantenimiento, la auto-optimización, etc.

Aunque parece que este es el futuro de las grandes infraestructuras desplegadas, por ejemplo, por los proveedores Cloud más importantes, en el campo de la autonomía todavía queda mucho por avanzar, y en los centros de datos actuales no se puede hablar de Autonomic Computing más que a niveles muy básicos, siendo todavía necesaria mucha intervención humana en la mayor parte de los procesos. Poco a poco.