Como consecuencia del importante aumento previsto de la generación estocástica en la red eléctrica, se espera que aumente la necesidad de flexibilidad y coordinación en el lado de la demanda. Los mercados energéticos descentralizados se encuentran entre las soluciones más prometedoras que permiten impulsar la coordinación entre la producción y el consumo, permitiendo incluso a los pequeños actores capitalizar su flexibilidad. El objetivo principal de Hive Power es desarrollar una plataforma basada en blockchain para apoyar a los grupos de prosumidores que quieran crear su propio mercado energético. El elemento central de este marco es el llamado Hive, es decir, una implementación de un mercado energético basado en la tecnología blockchain (véase nuestro libro blanco en hivepower. tech para tener información detallada sobre la plataforma Hive Power).Este artículo describe Demo Hive, el primer banco de pruebas desarrollado por nuestro equipo y presentado durante el Energy Startup Day 2017 en Zúrich, Suiza, el 30 de noviembre de 2017. Prácticamente, la demo es un caso simple pero también significativo de una colmena; está constituida por un productor y un consumidor, los llamados trabajadores. Un tercer elemento es la REINA, cuyo objetivo es gestionar la interacción entre las obreras y la red externa y hacer un seguimiento de las mediciones relacionadas con la energía consumida/producida por las obreras. El productor, a continuación denominado SOLAR, simula una planta fotovoltaica con una potencia nominal de 5 kWp. En cambio, el otro trabajador(LOAD) genera datos sobre el consumo de una carga. La Fig. 1 muestra el banco de pruebas de demostración.

Fig1: El banco de pruebas Demo Hive

Esencialmente, los principales componentes de hardware de Demo Hive son:

• dos SmartPIsuno para cada trabajador. Este dispositivo está constituido por una placa de adquisición de las medidas eléctricas (tensiones y corrientes) conectada a una Raspberry Pi 3. En la Fig. 1 los dos trabajadores son las cajas negras de la parte inferior.
• A Raspberry Pi 3 para proporcionar las funcionalidades de Queen.
• Un router 5G para proporcionar la conectividad a Internet y una WLAN dentro del banco de pruebas.

Tokenización de la energía:Uno de los objetivos más significativos de Demo Hive es tokenizar la energía producida/consumida y guardar la información relacionada en una cadena de bloques. Por esta razón, se desplegó un contrato inteligente compatible con ERC20 en la red Ropsten para crear un token de demostración, llamado DHTque tiene el siguiente valor fijo:

• 1 DHT = 1 cts = 0,01 CHF

La idea básica de Demo Hive es que LOAD posee una cierta cantidad de DHTs y envía parte de ellos a los productores (típicamente SOLAR, pero también la red externa a través de QUEEN) para comprar energía. En el siguiente capítulo se describirán exhaustivamente estos aspectos.Modo de funcionamiento: Unconjunto de aplicaciones se ejecutan en los dispositivos mencionados para accionar la plataforma Demo Hive, una parte de ellas desarrolladas por Hive Power. En este artículo sólo se describirá el comportamiento principal del banco de pruebas demo, evitando explicar todo el código en detalle. La siguiente imagen informa de las interacciones del software dentro de la demo y fuera de ella con la red Ropsten.

Fig. 2: Demostración de las interacciones del software Hive

Tal y como está escrito en nuestro whitepaper, periódicamente la plataforma Hive real guardará los datos sobre la energía tokenizada en un blockchain. Esto es bastante poco conveniente en un banco de pruebas de demostración porque el período puede ser demasiado largo. Por ello, el software de demostración considera días virtuales con una duración de sólo 10 minutos. Esto significa que el trabajador SOLAR produce en 10 minutos la misma energía que realmente realiza en 24 horas. Del mismo modo, las mediciones de energía, que en una aplicación real se realizan fuera de la cadena y suelen adquirirse cada 15 minutos, en Demo Hive se miden cada 5 segundos. Como se muestra en la Fig. 2, durante el día virtual de 10 minutos las mediciones de energía son guardadas por los trabajadores en QUEEN (flechas negras) en una InfluxDB base de datos, un SGBD orientado a series temporales que se utiliza habitualmente en aplicaciones de monitorización. Cuando el día simulado termina, las energías de los trabajadores son calculadas y tokenizadas en DHTs considerando las siguientes tarifas estáticas.

• Compra en la red: 20 cts/kWh
• Vender en la red: 5 cts/kWh
• Compra en la Colmena: 10 cts/kWh
• Vender en la Colmena: 10 cts/kWh

Considera que el trabajador LOAD/SOLAR sólo puede comprar/vender energía. En cambio QUEEN, que gestiona la interfaz con la red, puede realizar ambas operaciones. Al final de un día simulado, un algoritmo de tokenización intenta maximizar la autarquía de la colmena utilizando las siguientes reglas (ver también la Fig. 2):IF 𝑬_𝑳𝑶𝑨𝑫>𝑬_𝑺𝑶𝑳𝑨𝑹 :
LOAD compra 𝑬_𝑺𝑶𝑳𝑨𝑹 a SOLAR (10 cts/kWh) y 𝑬_𝑳𝑶𝑨𝑫-𝑬_𝑺𝑶𝑳𝑨𝑹 a QUEEN (20 CHF/kWh)ELSE IF 𝑬_𝑺𝑶𝑳𝑨𝑹>=𝑬_𝑳𝑶𝑨𝑫 :
SOLAR vende 𝑬_𝑳𝑶𝑨𝑫 a CARGA (10 CHF/kWh) y 𝑬_𝑺𝑶𝑳𝑨𝑹-𝑬_𝑳𝑶𝑨𝑫 a REINA (5 CHF/kWh)Prácticamente las trabajadoras intercambian toda la energía disponible en la colmena, aprovechando las tarifas más convenientes.Así, las energías se tokenizan en DHTs y los tokens correspondientes (como se ha escrito antes, 1 DHT = 1 cts) son enviados por los compradores (LOAD o QUEEN) a los vendedores (SOLAR o QUEEN) según el algoritmo mencionado. En la Fig. 2 estas operaciones están representadas por las flechas roja y celeste. A continuación, las transferencias de DHTs se guardan en la blockchain de Ropsten. Esto puede realizarse porque en cada dispositivo de demostración un geth cliente mantiene un nodo sincronizado con la red testnet de Ethereum. Para minimizar el espacio de disco necesario, las instancias de geth ejecutan la red Ethereum protocolo de cliente de luz. Las cuentas de Ropsten de los componentes se informan a continuación:

• CARGAR: 0x888d0aafc4d7c95fcaff9264d4bc2c1829a575be
• SOLAR: 0x3b5b6bbF5A14259bdF499f526A51aE7bF21c7476
• QUEEN: 0x7ab0c357cf3ae3c36b7ee8d4a84722a96790a6bd

Simulation results:As explained above, the Demo Hive testbed simulates “virtual” days with a duration of 10 minutes. During a single day the produced/consumed power of the two workers is saved every 5 seconds. At the end of the day (i.e. 10 minutes) the related energies are calculated, tokenized and saved on Ropsten network. In order to have days with both the aforementioned cases of the autarky algorithm (i.e. solar production > load consumption and solar production < load consumption) the following power profiles are taken into account for the workers:

• SOLAR: se consideran dos perfiles, el primero (a continuación denominado CLEAR) con una producción importante, relacionada con un día sin nubes. En cambio, el segundo (denominado a continuación NUBLADO) tiene una producción escasa, que simula un día nublado. La secuencia de los perfiles en los días simulados es una alternancia continua, es decir, después de un día CLEAR hay uno CLOUDY, y así sucesivamente.
• CARGA: se tiene en cuenta un único perfil típico como línea de base, y luego cada día se le añade un ruido. Como consecuencia, durante los días simulados los perfiles resultantes son siempre similares, pero nunca iguales.

La Fig. 3 muestra un ejemplo de dos días simulados. Es sencillo observar la diferencia entre los casos CLEAR y CLOUDY.

Fig. 3: Perfiles de dos días simulados (azul claro: SOLAR, amarillo oscuro: CARGA)

Los perfiles mostrados en la Fig. 3 se realizaron durante el Energy Startup Day 2017. Considerando el primer perfil (CLEAR), es sencillo entender cómo la producción SOLAR supera el consumo de LOAD. Como consecuencia, toda la energía que necesita el LOAD se compra localmente en la colmena al productor SOLAR a la conveniente tarifa Hive (es decir, 10 cts/kWh). Por otro lado, la cantidad restante de energía producida no comprada por LOAD será vendida por SOLAR en la red con una tarifa menos conveniente (es decir, 5 cts/kWh). Actuando como se ha descrito, el intercambio de energía local se maximiza y, en consecuencia, los dos trabajadores se dan cuenta de que ahorran/ganan dinero aprovechando las tarifas Hive.En el segundo caso (perfil CLOUDY), la producción no es capaz de cubrir todo el consumo. En el segundo caso (perfil CLOUDY), la producción no es capaz de cubrir todo el consumo, por lo que LOAD tiene que comprar parte de la energía necesaria a la red pagando 20 cts/kWh. Al final del día simulado, los datos de ahorro/ganancias son tokenizados y los DHTs relacionados distribuidos por el consumidor (por ejemplo, LOAD en un caso CLOUDY) a los productores (por ejemplo, SOLAR y QUEEN en un caso CLOUDY) para pagar la energía utilizada. En la siguiente lista, los beneficios/costes de la energía en los DHTs se reportan comparando los casos de Demo Hive contra una situación de business as usual (BAU), donde el mercado de hive no existe (es decir, sólo las tarifas de la red, 20/5 cts/kWh para comprar/vender energía, están disponibles).

• Ingresos solares:

12:00-12:10 (DESPEJADO):
COLMENA = 432 DHT
BAU = 254 DHT
COLMENA-BAU = 178 DHT12:10-12:20 (NUBLADO):
COLMENA = 135 DHT
BAU = 68 DHT
COLMENA-BAU = 67 DH

• Costes de carga:

12:00-12:10 (CLARO):
HIVE = 356 DHT
BAU = 713 DHT
HIVE-BAU = -357 DHT12:10-12:20 (CLARO):
HIVE = 590 DHT
BAU = 725 DHT
HIVE-BAU = -123 DHEs fácil notar como el dinero ahorrado/ganado de LOAD/SOLAR es mucho mayor durante el día CLARO, siendo la producción solar capaz de cubrir toda la energía necesaria dentro de la colmena. La siguiente lista informa de las cantidades exactas:

• LOAD ahorra 3,57 CHF durante los días CLEAR
• LOAD ahorra 1,23 CHF durante los días de CLOUDY
• SOLAR gana 1,78 CHF durante los días de CLEAR
• SOLAR gana 0,67 CHF durante los días de CLOUDY

Las siguientes URLs informan de los detalles de las transacciones de Ropsten relacionadas con los días simulados.

• TX_CLEAR_1: 356 DHTs enviados por LOAD a SOLAR
• TX_CLEAR_2: 76 DHTs enviados por QUEEN a SOLAR
• TX_CLOUDY_1: 455 DHTs enviados por LOAD a QUEEN
• TX_CLOUDY_2: 135 DHTs enviados por LOAD a SOLAR

Próximos pasos:El banco de pruebas de Demo Hive implementa un caso muy sencillo de hive. Es un punto de partida importante para el desarrollo del marco completo, pero hay que implementar algunas mejoras. La siguiente lista informa de las características más significativas que aún quedan por desarrollar.

• Prototipo de un contador "preparado para blockchain": El dispositivo SmartPi se basa en una placa Raspberry Pi 3, una gran plataforma de hardware para la creación de prototipos y pruebas iniciales, pero que no está proyectada para ser integrada fácilmente en un producto industrial. Para desarrollar un contador blockchain, naturalmente necesario en nuestro marco, la idea de Hive Power es tener en cuenta plataformas de hardware más orientadas a la industria y utilizarlas para sustituir a los dispositivos SmartPi.
• Perfiles de potencia: Actualmente los perfiles de los trabajadores son bastante similares durante los "días simulados" de 10 minutos. Prácticamente hay una alternancia precisa de días claros y nublados para la producción SOLAR. En cuanto a la CARGA, cada día simulado se añade un ruido al mismo perfil predefinido. Para tener una situación más realista, hay que considerar nuevos perfiles (por ejemplo, dos perfiles de CARGA diferentes, el primero para los días laborables y el segundo relacionado con el fin de semana)
• Canales de estado: en nuestro banco de pruebas de demostración, las mediciones de potencia se adquieren cada 5 segundos y los datos relacionados se guardan en una base de datos que se ejecuta en QUEEN. Para tener un enfoque totalmente descentralizado, nuestra idea es manejar los datos de potencia utilizando la tecnología de Canales de Estado evitando utilizar una base de datos local.
• Más trabajadores: Para tener una simulación más realista de un mercado energético de la Colmena, el número de trabajadores debería aumentar.
• Prosumidor/trabajador de almacenamiento: Siendo actualmente en Demo Hive sólo un consumidor (LOAD) y un productor (SOLAR), tendrá sentido introducir prosumidores y trabajadores de almacenamiento para tener un mercado completo. Es interesante considerar que con los sistemas de almacenamiento sería posible implementar algoritmos de cambio de carga para maximizar el ahorro de costes.
• Tarifas dinámicas: En Demo Hive sólo se tienen en cuenta las tarifas estáticas para la compra/venta de energía. Evidentemente, esta situación no es realista y, por lo tanto, hay que implantar un sistema dinámico de tarifas.

‍