Big Data

El término Big Data surge cuando los conjuntos de datos con los que se trabaja son demasiado costosos de capturar, compartir, almacenar, buscar, segmentar, visualizar y analizar con las herramientas hardware y software tradicionales. Se suele asociar este concepto a volúmenes de datos de exabytes y zettabytes (es decir, en órdenes de magnitud de 10 a la 18 y de 10 a la 21 respectivamente). 

Aunque tradicionalmente esta dificultad para extraer información y conocimiento valiosos de grandes conjuntos de datos se daba sólo en aplicaciones científicas, en la actualidad son las aplicaciones industriales y empresariales las que más rápidamente están incrementando sus necesidades de procesamiento de datos. Esto se debe sobre todo a la utilización de Internet y redes sociales, a los nuevos paradigmas de computación como Pervasive Computing (asociado a conceptos como Smart City o Internet of Things) y a la generalización de tecnologías como RFID, loa sensores wireless o los dispositivos móviles. Según un informe de IBM el 90% de los datos que se manejan en soporte digital actualmente, han sido creados en los dos últimos años. Y los datos se consideran hoy en día un recurso, al menos tan valioso como el resto de recursos de una organización. Siempre y cuando se pueda extraer de ellos conocimiento valioso para la toma de decisiones.

Es muy difícil hacer un resumen de todas las tecnologías, conceptos y metodologías que se asocian en la actualidad a Big Data, ya que además es un término que han adoptado rápidamente tanto los fabricantes de hardware como los de software. Pero intentaremos hacer un recorrido por las más importantes en entradas futuras.

¿Qué es una SmartCity?

Durante los últimos años se han llevado a cabo proyectos consistentes en la introducción de elementos domóticos e inmóticos para la gestión inteligente de casas, espacios comerciales e infraestructuras. Los distintos sistemas que concurren en una infraestructura (iluminación, calefacción, ventilación, climatización, anti incendios, video, megafonía, CCTV, control de accesos, suministros de energía, CPD…) han requerido de sistemas de información que han facilitado su integración y han proporcionado información que ha permitido realizar una gestión inteligente de dichos entornos. Cuando los conceptos de integración de sistemas, acceso a información en tiempo real, eficiencia, sostenibilidad o reducción de emisiones se extrapolan a la gestión integral de las infraestructuras y servicios que conviven en una ciudad (riegos, iluminación, tráfico, sistemas electromecánicos, recogida de residuos, etc…) es cuando surge el concepto de SmartCity.

No existen ciudades inteligentes. El desarrollo de una Smart City ofrece a los ciudadanos la posibilidad de actuar de forma inteligente, acercándoles toda la tecnología que se despliega en una ciudad (sensores, medidores, controladores, cámaras, sistemas de información). Los ciudadanos pueden aprovecharse de este despliegue tecnológico:

• Reduciendo los tiempos de desplazamiento ya que conocen en tiempo real y a través de cualquier tipo de dispositivo móvil el estado del tráfico y la disponibilidad de plazas de parking.
• Reduciendo los costes energéticos ya que se les proporciona información contextualizada de sus hábitos de consumos.
• Incrementando la facilidad de acceso a lugares públicos porque se lleva a cabo una gestión de alarmas que permite reaccionar en tiempo real ante posibles averías de escaleras, pasadores urbanos…

Además de tener un impacto positivo y directo sobre los ciudadanos, las administraciones públicas se aprovechan de las inversiones realizadas, reduciendo drásticamente los costes asociados a las infraestructuras.

En este documental ofrecido por Informe Semanal, se tratan tres casos de éxito de aplicación del concepto SmartCity en las ciudades de Málaga, Rivas Vaciamadrid y el distrito 22@ de Barcelona. En particular, en la ciudad de Málaga la inclusión de inteligencia a la red de farolas de la ciudad ha permitido que los costes se reduzcan hasta un 30% o que se reduzcan las emisiones de C02 hasta un 20%.

Para finalizar, una de las claves que permite que una ciudad se convierta en SmartCity está en la integración de todos los sistemas que conviven en ella y la incorporación de sistemas de información que faciliten dicha integración y proporcionen la información necesaria en tiempo real para que los ciudadanos puedan tomar decisiones inteligentes.

Windows, Linux y transacciones de entre 2 y 12 segundos

En anteriores entradas se ha tratado el concepto de sistema tiempo real y qué características hacen que un sistema se considere tiempo real. De estas entradas pueden extraerse estas dos conclusiones:

• Un sistema tiempo real no debe confundirse con uno que deba ejecutar tareas o gestionar información en intervalos pequeños de tiempo.
• Un sistema en tiempo real debe asegurar que se cumplen las latencias.

En algún foro, ha surgido la siguiente discusión: ¿pueden considerarse sistemas operativos como Windows o Linux sistemas RTOS (Real Time Operating Systems)? La respuesta es no por varios motivos, pero el principal es que son sistemas operativos que no garantizan tiempos de respuesta deterministas.

¿Qué significa esto? Que la probabilidad entra en su funcionamiento (son estocásticos), es decir no se puede prever que un resultado se produzca siempre con la misma latencia. ¿Y qué factores hacen que un SO sea determinista? Principalmente dos, la planificación de procesos y el tratamiento de interrupciones de E/S.

Ninguno de los dos sistemas operativos mencionados gestiona estos dos aspectos de manera que se pueda garantizar el cumplimiento de unas latencias deterministas. Por este motivo no pueden utilizarse en entornos de tiempo real "estricto" o tradicional.

En paralelo a esta cuestión, surge otra discusión. Para la supervisión, control y gestión de información desde centros de control de infraestructuras y entornos industriales se requieren normalmente latencias de entre 2 y 12 segundos. ¿Son Windows y Linux capaces de realizar transacciones en este rango de tiempos aunque no me puedan garantizar que siempre van a tardar lo mismo en ejecutar las mismas tareas? La respuesta es afirmativa. Actualmente Windows tiene la capacidad de realizar transacciones de entre 0.1 ms y 100 ms, y Linux de alrededor de 1ms.

Por tanto, si nuestro sistema es realmente de tiempo real (valga la redundancia), no podemos utiilizar los sistemas operativos habituales y será necesario recurrir a sistemas RTOS diseñados específicamente con este objetivo. Pero para las típicas aplicaciones de supervisión y control de infraestructuas y entornos fabriles, con las latencias antes mencionadas, suele ser más que suficiente cualquiera de estas dos alternativas.

Tipos de hipervisor

Ya hemos hablado en entradas anteriores del concepto de virtualización. En entornos industriales cada vez es más frecuente la utilización de la virtualización del hardware, es decir, la utilización de máquinas virtuales. Estas máquinas se basan siempre en un hipervisor, o monitor de máquina virtual, que hace de intermediario entre el hardware de la máquina host y el sistema operativo invitado (guest) instalado sobre la máquina virtual. Es decir, que permita el acceso de este sistema operativo guest al procesador, la memoria, el almacenamiento y la red reales.

Existen dos tipos diferentes de hipervisores:

• Tipo I (unhosted, bare metal o nativo): Se instala directamente sobre el hardware de la máquina host, sin necesidad de que ésta incorpore un sistema operativo. De esta manera, el sistema operativo guest pasa directamente del hipervisor al hardware físico.
• Tipo II (hosted): Necesita que la máquina host lleve instalado un sistema operativo, de manera que el sistema operativo guest tiene que pasar por el hipervisor y por él antes de llegar al hardware físico.

Al primer tipo corresponden hipervisores como VMware ESX (versiones gratuitas y de pago), Xen (gratuito y tremendamente extendido en entornos Cloud) ó Microsoft HyperV (de pago) Al segundo tipo corresponden QEMU (gratuito y muy utilizado con fines didácticos por su sencillez), Oracle VirtualBox (gratuito),  VMware Workstation (de pago) ó Microsoft Virtual PC y Virtual Server (ambos gratuitos).

En teoría la utilización de hipervisores de Tipo I permite obtener configuraciones con un rendimiento mayor (al reducir las capas intermedias entre el sistema operativo guest y el hardware real) y de una mayor robustez (por no depender de un sistema operativo host). Pero en la mayor parte de los casos se opta por los hipervisores de tipo II dada su facilidad de instalación y configuración y sus garantías de acceso al hardware físico (a través del sistema operativo host).

En los últimos años se habla también de paravirtualización o full-virtualization, que son términos que se refieren al soporte hardware que los fabricantes de procesadores están proporcionando a las técnicas de virtualización. En estos casos lo que se persigue es que la traducción que el hipervisor hace habitualmente de las llamadas del sistema operativo guest al hardware y de las respuestas de este harwdare, se pueda realizar parcial o totalmente desde el propio hardware (por lo tanto, de una manera mucho más eficiente). En futuras entradas hablaremos de las tecnologías AMD-V e Intel VT-x que los dos grandes fabricantes de procesadores han propuesto para facilitar la virtualización de sus arquitecturas x86.

Servidores tipo Blade

La mayor parte de sistemas HPC (High Performance Computing) actuales se basan en el concepto de Blade, que al contrario de lo que habitualmente se cree, no pertenece a un fabricante concreto ni implica un modelo de arquitectura concreto.

Un Blade es una placa base que incorpora procesadores, memoria y buses de E/S. Pero no alimentación, dispositivos de red o de almacenamiento o mecanismos de refrigeración. Por lo tanto, un servidor Blade por si mismo no se puede utilizar. Es necesario que vaya montado en un rack o chasis que incorpore estos componentes esenciales. En cada chasis se insertan varios Blades que los comparten, depende del fabricante, pero se suelen "empaquetar" en conjuntos de entre 8 y 16 por chasis.

Existen Blades de propósito general y Blades de función específica (sólo memoria, sólo almacenamiento, sólo red, sólo conectores de E/S), se suele encontrar de los dos tipos dentro de cada chasis. La ventaja es que al tratarse de placas y chasis con dimensiones estándar, cada usuario puede construirse su propia configuración en función de sus necesidades.

Este tipo de organización ha permitido la reducción del espacio que ocupa el sistema, la minimización del consumo de potencia y la sencillez en el montaje y administración de los servidores (cableado y refrigeración, modificaciones en caliente, reducción de componentes mecánicos y por tanto mayor tolerancia a fallos), etc. Por eso suele encontrarse habitualmente en la mayor parte de centros de cómputo y CPDs actuales.

Sistema para telecontrol de vertidos en la Isla de la Cartuja

Alfonso López Escobar, Jefe de Automatización y Control y José Manuel Barrera Cuadra, Técnico de Automatización de Control, ambos de la Empresa Metropolitana de Abastecimiento y Saneamiento de Aguas de Sevilla (EMASESA) han escrito este artículo que lleva por título "Sistema para telecontrol de vertidos en la Isla de La Cartuja".

Para dar respuesta a lo establecido en el Reglamento de la Calidad de las Aguas Litorales, así como en el Real Decreto 334/1994 por el que se regula el procedimiento para la tramitación de las autorizaciones de vertidos, en el año 2007 se elaboró por el Departamento de Control y Servicios Técnicos de EMASESA, un proyecto cuyo resultado debía ser un sistema para supervisión y registro histórico de los parámetros fundamentales de calidad del vertido al río en cuatro puntos de la Isla de la Cartuja, en Sevilla Capital.

En este enlace podéis encontrar el artículo completo.

Wonderware Intelligence 1.5

Wonderware Intelligence 1.5 es la solución desarrollada por Wonderware que permite estandarizar y homogenizar procesos de extracción, carga, transformación, contextualización y análisis de datos. El enfoque de esta solución está basado en el concepto Business Intelligence (BI) que a continuación se describe.

Actualmente existe un gran número de aplicaciones individuales y aisladas (desarrollos a medida, aplicaciones comerciales, soluciones mixtas) que se ejecutan en diferentes servidores, tienen diferentes fuentes de datos y utilizan diferentes formatos de información, distribuidas geográficamente y con diferentes propietarios.

En estos entornos, es deseable una capa de integración que permita un intercambio de información fiable entre todas estas aplicaciones heterogéneas y la compartición de funciones y procesos entre ellas de una manera completamente interoperable.

A partir de un estilo de integración de BBDD compartida, puede definirse Business Intelligence como el conjunto de herramientas, aplicaciones, tecnologías, soluciones y procesos que permiten a diferentes usuarios acceder a información valiosa para la toma de decisiones proveniente de distintas fuentes de datos.

Partiendo de esta definición surge la adaptación realizada por Wonderware que acuña el concepto Low Latency Data Intelligence (LLDI) y que a su vez se define como el conjunto de herramientas, aplicaciones, tecnologías, soluciones y procesos que permiten a diferentes usuarios acceder a información valiosa para la toma de decisiones proveniente de datos asociados a entornos industriales y/o infraestructuras que son gestionados con sistemas tipo SCADA, BMS, DCS, HMI…y otros datos de carácter transaccional. Puede observarse que uno de los factores diferenciales del enfoque LLDI es que tradicionalmente los proveedores de soluciones BI sólo consolidan datos de BBDD transaccionales, obviando la información que generan los sistemas de información asociados a entornos industriales o infraestructuras.

Las soluciones LLDI se desarrollan partiendo de procesos ETL (Extract, Transform and Load).

El proceso de extracción consiste en comunicar con diferentes fuentes de datos y la capacidad de leer la información contenida en dichas fuentes. Estas fuentes pueden ser BBDD transaccionales tipo SQL y Oracle, BBDD asociadas a entornos industriales (Historian, PI, etc..), servidores OPC o ficheros planos (.txt o .csv).

El proceso de transformación consiste en contextualizar la información bruta recogida de las distintas fuentes de datos.

Por último, el proceso de carga consiste en almacenar toda esta información ya contextualizada en un repositorio centralizado que normalmente recibe el nombre de Datawarehouse. Asociado a este repositorio suelen vincularse otras bases de datos. Una BBDD en la que se recogen los datos de configuración y metadatos y otras BBDD que son pequeñas réplicas del Datawarehouse central que reciben el nombre de Datamart.

Se puede convenir que asociado a estos procesos ETL, existe un proceso de explotación de la información. Es decir, una vez que los datos están contextualizados, almacenados y disponibles en el Datawarehouse, existen herramientas que permiten explotar dicha información. Esta explotación permite realizar minería de datos (Data Mining), visualizar los principales indicadores de gestión (KPI) y definir informes predefinidos.

Es necesario precisar, que más del 80% del esfuerzo que requiere el desarrollo de una solución LLDI se concentra en la realización de los procesos ETL y no tanto en la configuración o parametrización de las herramientas vinculadas a la explotación de la información.

A partir de los conceptos antes nombrados, Wonderware Intelligence 1.5 permite abordar tanto los procesos ETL como los de explotación de la información con soluciones estándares, fácilmente parametrizables y permitiendo un aproximación escalonada.

Para desarrollar los procesos ETL, Wonderware Intelligence 1.5 proporciona tres plantillas de objetos que se integran de forma natural en el entorno de desarrollo de System Platform, el Integrated Development Studio (IDE) e incorpora una BBDD predefinida basada en SQL donde se almacenan todos los datos contextualizados (que recibe el nombre de Intelligence) que cubre el proceso de carga (Load). Estas plantillas de objetos son:

$Data Sources (que permiten los procesos Extract): son interfaces con diferentes fuentes de datos (Historian, SQL Server, Oracle, Access, Text (CSV), OSIsoft PI Server...)

$Measures (que permiten los procesos Transform): las medidas son valores numéricos que representan consumos, hechos, transacciones. Ejemplo: litros depurados; litros desalados; litros decantados; Kw consumidos…

$Dimension (que permite los procesos Transform): las dimensiones son variables que permiten contextualizar las medidas. Ejemplo: turno, equipo, producto…

Es decir la información puede proporcionarse de forma NO CONTEXTUALIZADA. Ejemplo: 10.000 litros de agua desalados (sólo con la medida), o bien puede proporcionarse de forma CONTEXTUALIZADA. Ejemplo: 10.000 litros de agua desalados, el día 28 de febrero, durante el turno de mañana, con el equipo de personas 3, utilizando los filtros de arena 1 y 3 y consumiendo 30.000 Kwh.

Wonderware Intelligence proporciona el entorno de desarrollo que permite integrar información de diferentes fuentes de datos, definir las medidas y contextualizarlas a través de diferentes dimensiones.

Adicionalmente, para realizar los procesos de explotación de la información, Wonderware Intelligence 1.5 incluye herramientas de reporting basadas en la solución Tableu Software. En cualquier caso es preciso matizar que la información contextualizada que está recogida en la base de datos Intelligence puede ser explota con cualquier otra herramienta de explotación de información (tipo Click View, Cognos, Microstrategy...), ya que se trata de una BBDD SQL accesible vía ODBC y OLE DB.

Se puede concluir que las principales funcionalidades de Wonderware Intelligence 1.5 son las siguientes:

• Crea información contextualizada en tiempo real a partir de datos de diferentes fuentes.
• Permite estandarizar y homogenizar procesos de integración de datos.
• Facilita el desarrollo de cuadros de mando sin necesidad de programación.
• Combina información en tiempo real e información transaccional.
• Utiliza un único entorno de desarrollo para gestionar ambos tipos de información.

En este link puede accederse a un vídeo en el que se muestra la parametrización de las fuentes de datos, medidas y dimensiones desde la solución Wonderware Intelligence 1.5, así como la posterior explotación de la información a través de las soluciones que proporciona Tableu Software.

SOA en entornos industriales (y II)

Volviendo a los entornos industriales, la pregunta que surge es la siguiente: ¿Tiene sentido incluir una capa de integración SOA que de forma estándar permitiera integrar y comunicar todos los dispositivos y sistemas para facilitar la gestión de entornos industriales?

La respuesta es afirmativa. De hecho ya existen varias iniciativas que corroboran la idoneidad de este planteamiento (SIRENA, SODA, SOCRADES, VINNOVA...) de las que hablaremos en futuras entradas.

En esta, resumimos y relacionamos los principales beneficios que se han obtenido al orientar el desarrollo de aplicaciones a servicios o a integrar diferentes sistemas a través de una arquitectura orientada a servicios.

1. Se facilita la integración de todos los dispositivos y sistemas ya que han sido desarrollados bajo una arquitectura SOA. En este sentido se puede hablar de una integración horizontal (entre dispositivos y sistemas existentes al mismo nivel, como entre dos PLC o dos SCADA) y una integración vertical (entre dispositivos y sistemas existentes a diferente nivel, como entre un SCADA y un ERP). En caso de que las aplicaciones no hayan sido desarrollados bajo SOA, la práctica común consiste en desarrollar un "envoltorio" basado en Web Services para estas aplicaciones monolíticas que puedan ofrecer sus datos como servicios y ser accesibles por otras aplicaciones.
2. Se proporciona una nueva generación de dispositivos y sistemas industriales “Plug&Play” en los que la integración sea una funcionalidad natural asociada a estos y en los que los cambios de configuración, parametrización y mantenimiento se realicen en tiempo real con alta disponibilidad de los sistemas.
3. Se reducen los costes de integración entre sistemas transaccionales y sistemas tiempo real.

Por último, en esta imagen (extraida del artículo "Towards an Architecture for Service-Oriented Process Monitoring and Control") se puede observar cómo la incorporación de un capa de servicios sobre todos los dispositivos y aplicaciones asociados al entorno industrial permite que todos ellos puedan integrarse fácilmente.

SOA en entornos industriales (I)

Los entornos industriales se caracterizan por la complejidad de los procesos de fabricación, por la heterogeneidad de dispositivos de campo instalados (PCL, RTU, Controladores), por la diversidad de sistemas de información implantados (SCADA, MES, LIMS) y por la escasa integración existente entre los diferentes sistemas.

La existencia de islas de información y del desaprovechamiento de los datos generados por todos estos sistemas para la toma de decisiones es una realidad asociada a la gestión industrial.

En el ámbito de los sistemas transaccionales (ERP, CRM, SCM...), también existía este problema, pero la inclusión de arquitecturas SOA ha permitido resolver buena parte de las barreras que se encontraban para realizar proyectos de integración de aplicaciones.

El concepto de SOA ha sido tratado previamente en anteriores entradas.

http://redindustria.blogspot.com/2008/09/qu-es-soa-i.html

http://redindustria.blogspot.com/2008/09/qu-es-soa-ii.html

http://redindustria.blogspot.com/2008/09/qu-es-soa-y-iii.html

De todas ellas podemos extraer las siguientes ideas principales:

• Service Oriented Architecture (SOA), es una nueva filosofía de diseño de aplicaciones que propone una alternativa a las tradicionales aplicaciones de negocio monolíticas basadas en objetos.

• SOA propone que los procesos de negocio no se traduzcan en aplicaciones clásicas (desarrolladas con códigos difícilmente integrables y reutilizables), sino que éstos llamen a los servicios que necesitan para obtener resultados.

• Los servicios deben estar débilmente acoplados y ser altamente interoperables, por lo que son muy importantes los protocolos que definen formalmente estos servicios y que permiten la comunicación con ellos y entre ellos.

• Los estándares que han estado relacionados con SOA desde los comienzos han sido XML, SOAP y WSDL. Es decir, los que proporcionan la base para los Web Services. La definición más extendida de un Web Service es "función pública, encapsulada y débilmente acoplada ofrecida a través de protocolos estándar".

• Por tanto, los Web Services son componentes accesibles desde diferentes aplicaciones, y que al estar basados en protocolos estándares, facilitan mucho la reutilización.