El término smart grid es uno de los temas más recurrentes hoy día en el sector eléctrico y su desarrollo o puesta en práctica conllevará sin duda gran cantidad de proyectos de modernización en los que las tecnologías de la información jugarán un papel fundamental.
Básicamente, el smart grid (o red de distribución de energía eléctrica inteligente) es una visión del futuro del modelo de distribución de energía eléctrica en el que los usuarios finales dejarán de ser meros consumidores pasivos de energía para pasar a desempeñar un rol más activo, a través de una mayor y más detallada información de consumo, y su posible incorporación en el mercado como productores de energía (típicamente a través de las energías renovables).
El desarrollo del smart grid está habilitando un conjunto de tecnologías a varios niveles (tecnologías de almacenamiento de energía, el vehículo eléctrico, smart metering, etc) que en su conjunto posibilitarán la modernización de las infraestructuras, la inclusión de los consumidores en la toma de decisiones sobre la producción (consumerization) y el alineamiento con los objetivos nacionales y globales en materia medioambiental.
En este artículo, trataremos con un supuesto práctico una de las tecnologías que permitirán hacer más inteligente la red de distribución de energía eléctrica en términos de conocimiento operativo en tiempo real: el complex-event processing o CEP.
Complex-event processing
El complex-event processing (CEP) es un estilo de computación que permite implementar sistemas conducidos por eventos (event-driven) y de inteligencia continua. En contraste con los sistemas de business intelligence (BI) que permiten analizar la información de datos generados en el pasado (responden a “¿qué ha pasado en el negocio y por qué?”), los sistemas de inteligencia operacional permiten analizar los datos en tiempo real, y en el contexto en el que estos se producen, ayudando a detectar riesgos y amenazas, pero también oportunidades de diferenciación (responden a “¿qué está pasando en el negocio?”).
En CEP, el conocimiento se deriva de la combinación de dos o más sucesos, llamados eventos, y del contexto en el que se producen. Además, se dice que es conducido por eventos (event-driven) porque el cálculo o la respuesta se produce en cuanto se almacena el dato, en contraste con los sistemas tradicionales que requieren de una programación de ejecución (time-driven) o de una petición típicamente del usuario final (request-driven). Es decir, la latencia, entendida como el tiempo que transcurre desde que el dato es registrado hasta que es tratado, es mucho menor en los sistemas de CEP que en los tradicionales permitiendo el análisis en tiempo real de los datos relevantes para el negocio (business activity monitoring o BAM), habilitando la capacidad de responder rápidamente ante amenazas y oportunidades, y reduciendo los costes asociados al mantenimiento de grandes volúmenes de datos no relevantes.
La aplicación de CEP (y BAM) en el smart grid está muy ligada al desarrollo de tecnologías operacionales como los dispositivos de medida eléctrica, sensores, software de control como los sistemas SCADA y el resultado de la monitorización de elementos físicos y procesos en tiempo real. Los casos de uso más típicos son por tanto:
- el análisis del consumo eléctrico y
- la monitorización de los equipos y las redes (especialmente los sistemas SCADA y los dispositivos de medida)
Caso práctico: monitorización de dispositivos de medida
Para una compañía eléctrica que participa en el mercado energético, la disponibilidad y la gestión de la medida de energía eléctrica producida se configura como el elemento fundamental que habilita los procesos de negocio de la compañía impactando en el margen de beneficios cuando se realiza de manera efectiva y aplicando los parámetros de negocio adecuados. En este sentido, los equipos o dispositivos de adquisición de la medida deben ser monitorizados en tiempo real para asegurar su buen funcionamiento y poder responder a tiempo en caso de avería o falta de cobertura.
En el caso de la energía eólica, es habitual que los parques se encuentren ubicados en lugares apartados y de difícil acceso, por lo que a menudo, la comunicación con estos se realiza a través de módems GPRS.
Para este ejemplo, supongamos una compañía eléctrica que dispone de 500 parques o instalaciones de producción de energía eléctrica. Cada parque tiene asociados idealmente 2 puntos de medida, uno principal y otro redundante, ambos conectados a un módem GPRS que habilita la conectividad TCP/IP a través de una red VPN. El firmware de cada uno de estos 500 módems permite programar el envío de un trap SNMP cada minuto con información sobre el estado del dispositivo, por ejemplo sobre su nivel de cobertura. Cada trap SNMP no es más que una traza de información que serializada puede tener el siguiente aspecto:
V1TRAP[reqestID=0, timestamp=0:00:00.00, enterprise=1.3.6.1.4.1.15732, genericTrap=6, specificTrap=122, VBS[1.3.6.1.4.1.15732.2.4 = -97]
Los traps recibidos se normalizan a un formato de mensaje XML para ser tratados por un ESB (enterprise service bus), adaptador XML, un middleware orientado a mensajes (MOM) o por un motor de CEP por ejemplo. El mensaje normalizado que representa el trap podría tener de forma simplificada el siguiente aspecto:
<trapInfo>
<ip>192.168.0.123</ip>
<cobertura>31</cobertura>
</trapInfo>
donde el 31 representa un nivel de cobertura óptimo expresado en rssi (received signal strength indication o indicador de potencia de señal recibida).

Es decir, cada minuto se deberían recibir 500 mensajes indicando el grado de cobertura de los dispositivos. Sin embargo, cuando el dispositivo no dispone de cobertura suficiente, ni siquiera es capaz de enviar el trap. Esta circunstancia se traduce en que el sistema de adquisición de la medida no podrá leer la medida, horaria o cuarto-horaria, ni ningún otro dato almacenado en el registrador instalado en cada uno de los 2 puntos de medida conectados al módem.
Los sistemas de mensajería y orientados a eventos tradicionales responden adecuadamente ante la ocurrencia de eventos conocidos, pero ¿qué ocurre cuando la información de valor se obtiene de la concurrencia de dos o más eventos en un espacio temporal dado?, y como se ha descrito en el caso expuesto, ¿qué ocurre cuando lo relevante para el negocio es precisamente la no aparición del evento?.
Solución
Una forma de modelar el caso descrito es haciendo uso de un motor de CEP aplicando las reglas de procesamiento temporal adecuadas. Una de estas reglas temporales puede evaluar los mensajes de trap que llegan al motor de CEP lanzando alertas tras detectar que un dispositivo lleva más de un minuto sin enviar traps. Esta alerta se modela como un nuevo evento, esta vez complejo o de negocio, que indica que el dispositivo está sin cobertura. Otra regla puede evaluar si la ausencia de traps excede por ejemplo de 10 minutos lo cual podría generar un nuevo evento de negocio que indique que el dispositivo está en fallo.
De cara al análisis en tiempo real de esta información, las alertas pueden servir para actualizar un mapa geográfico de cobertura en el que se representen en verde aquellos dispositivos que tienen una cobertura óptima, en ámbar aquellos que tienen baja cobertura y en rojo aquellos dispositivos que están sin cobertura. Contextualmente, el usuario podría disponer de ciertas utilidades asociadas al dispositivo que le permitan actuar ante una situación de fallo en el dispositivo, como por ejemplo, ejecutar un estudio proactivo de cobertura, ruido y ping, o abrir un chat o llamada telefónica con el operador del parque en el que está instalado el dispositivo para tratar de resolver la incidencia.
En la actualización del mapa de cobertura pueden intervenir también tecnologías como comet o web sockets (HTML5) que permiten la comunicación asíncrona y bidireccional (también denominado AJAX inverso) entre el navegador y el servidor web.

Si un dispositivo que estaba en situación de fallo vuelve a enviar traps, el motor de CEP puede interpretar esta circunstancia como un evento de recuperación de la cobertura y lanzar una alerta en forma de evento complejo. La ocurrencia de este evento de recuperación de la cobertura puede suscitar que el sistema de adquisición de la medida trate de recoger la medida que no ha podido ser leída con anterioridad por la falta de cobertura del dispositivo.
Conclusión
El desarrollo del smart grid va a propiciar la consolidación y la evolución de ciertas tecnologías en el ámbito de TI que permitirán el aprovechamiento en tiempo real del contexto y de los innumerables eventos que producirán los dispositivos inteligentes, sensores y los procesos de negocio. En este contexto resulta fundamental la aplicación de arquitecturas desacopladas como SOA y EDA, así como de las tecnologías BAM y CEP en proyectos clave, que permitan el desarrollo de sistemas innovadores que nos diferencien de la competencia mientras que los sistemas básicos y procesos de negocio fundamentales permanecen estables.


diciembre 19, 2011 - 20:13
Estupendo artículo, sobre todo para los que hemos trabajado alguna vez en desarrollos de software que reacciona a eventos en tiempo real. Coincido en que tanto las tecnologías que comentas como el sector de las energías renovables van a ofrecer un campo de posibilidades hoy difíciles de imaginar, extendiendo por ejemplo el control del que hablas en tu caso práctico a l gestión en tiempo real de paneles solares privados, con dispositivos de control baratos y enfocados al gran consumo. Un placer volver a leerte.