OpenEMS

Open Source Energy Management System

OpenEMS

OpenEMS Backend

Info

OpenEMS UI

OpenEMS Edge

Info

Info

OpenEMS UI

Configuración en Visual Studio

OpenEMS Backend

Backend OpenEMS

Info

Entorno de desarrolloEclipse IDE

Configurar Backend OpenEMS_Eclipse IDE

Run OSGi

Info

Apache Felix Web ConsoleConfiguration

Info

Conecte la interfaz de usuario de OpenEMS UI con el backend

Configurar el backend

Configurar OpenEMS Edge

OpenEMS Edge está utilizando la plataforma OSGi para proporcionar un sistema orientado a servicios completamente modular y dinámico. OSGI (Open Services Gateway Initiative) es una capa sobre Java que permite crear módulos que pueden interactuar entre sí en tiempo de ejecución MULTIPLES MODULOS UNICA INTERFAZ.

• OSGi proporciona la capacidad de habilitar, modificar o deshabilitar un componente OpenEMS en cualquier momento, sin necesidad de reiniciar el software.
• OSGI proporciona un marco de trabajo que soporta el despliegue dinámico de aplicaciones («Bundles» o módulos)
• La instalación, arranque, parada, actualización y desinstalación de bundles se realiza dinámicamente en tiempo de ejecución sin tener que detener por completo la plataforma.
• Es una arquitectura orientada a servicios.

Bundles.OSGi es un framework de Java para desarrollar y desplegar módulos de software. Cada bundle es un conjunto acoplado, una colección que de clases, jars, y archivos de configuración que se pueden cargar dinámicamente, en las cuales se declara explícitamente sus dependencias externas, si es necesario. El framework está dividido conceptualmente en las siguientes partes: BundlesLos bundles son componentes en formato de archivos JAR con el agregado de archivos cabecera llamados manifest headers (manifiesto de encabezado). Un bundle es un conjunto de clases Java y de recursos adicionales que incluye el agregado de un archivo manifiesto detallado MANIFEST.MF que informa de todo el contenido, así como de los servicios adicionales que son necesarios para dar al grupo de clases de Java comportamientos más sofisticados, hasta el punto de considerar a todo el agregado como un componentet.

Servidor web. La consola web es la interfaz estándar para la configuración de OSGi.Proporciona una interfaz de usuario para editar las distintas propiedades, donde es posible seleccionar valores de listas predefinidas. Como tal, es el método más fácil de usar. Cualquier configuración realizada con la consola web se aplica inmediatamente y se aplica a la instancia actual, independientemente del modo de ejecución actual o de cualquier cambio posterior en el modo de ejecución.

Conecte la interfaz de usuario de OpenEMS UI con el backend

Configurar Visual Studio Code

Info

La interfaz de usuario de OpenEMS puede funcionar tanto para conexiones locales a OpenEMS Edge como para conexiones en la nube a OpenEMS Backend. El switch requiere algunos parámetros básicos que se definen en archivos de 'entorno'. Los posibles parámetros para se definen en el archivo. ui/src/themes/openems/environmentsng serve -c...​ui/angular.json

Configurar OpenEMS Edge

Componente back-end de la API del controlador

Info

Apikey se usa para autenticar este perímetro en el servicio de metadatos back-end. Tiene que ser único para cada Edge. Uri se establece en ws://localhost:8081. Esto define una conexión websocket sin cifrar (ws://) al ordenador local en el puerto 8081 como configuramos antes para el Edge.Websocket. Para una configuración de producción debería utilizar un websocket encriptado TLS con una uri wss://.

Configurar el backend

Info

bases de tiempo/base de datos

metadatos

Edge.Websocket

Ui.Websocket

Info

Info

Info

Info

El soket es un puente virtual que conecta el cliente con el servidor. Para enviar atraves de ete puente virtual la información. Se necesitga saber la ip o el dominio del servidor para encontrarlo y el puerto por el que el servidor recibira la informacion. A diferencia de HTTP, los WebSockets establecen una conexión bidireccional persistente entre el cliente y el servidor. A través de esta conexión, el cliente puede enviar datos al servidor en cualquier momento, y el servidor puede enviar datos al cliente por iniciativa propia en cualquier momento. Por lo tanto, los websocket son mucho más adecuados para desarrollar aplicaciones en tiempo real que el protocolo HTTP.

El servicio Edge.Websocket es responsable de la comunicación entre OpenEMS Backend y OpenEMS Edge. En el ejemplo estamos configurando el archivo . Este puerto debe coincidir con lo que configuramos más adelante en OpenEMS Edge. La configuración nos ayuda a obtener algunos detalles más sobre el comportamiento interno.

El servicio Ui.Websocket es responsable de la comunicación entre OpenEMS Backend y OpenEMS UI. En el ejemplo estamos configurando el archivo . Este puerto debe coincidir con lo que configuramos más adelante en el archivo de entorno de interfaz de usuario de OpenEMS. Estamos configurando de nuevo Port '8082'Debug Mode 'DETAILED'

El proveedor de servicios Timedata es responsable de mantener los datos actuales e históricos de cada dispositivo Edge conectado. En el ejemplo estamos configurando el servicio Timedata.Dummy. El valor predeterminado para _Component-ID' se puede aceptar sin cambios, así que simplemente presione Guardar. En un sistema de producción, querrá utilizar una implementación real como Timedata.InfluxDB.

El proveedor de servicios de metadatos es responsable de la autenticación de los dispositivos perimetrales y los usuarios que se conectan a través de la interfaz de usuario. Todas las aplicaciones de tu negocio funcionan juntas e integradas. Entre las aplicaciones de Odoo y las decenas de miles de aplicaciones de la Comunidad, seguro hay algo que te ayude a abordar todas las necesidades de tu negocio en una solución única, rentable y modular: no más esfuerzo para lograr que diferentes tecnologías colaboren. Las aplicaciones de Odoo están perfectamente integradas entre sí, lo que te permite automatizar completamente los procesos de tu negocio y aprovechar las ganancias y beneficios. En un sistema de producción, querrá utilizar una implementación real como Metadata.File, que utiliza un archivo JSON estático como entrada, o Metadata.Odoo, que utiliza el software empresarial Odoo para la autenticación y la gestión de dispositivos IoT. Esto requerirá que el Addon Odoo-OpenEMS esté instalado en su instancia de Odoo. Consulte el espacio de trabajo de Gitpod OpenEMS Live-Demo para obtener una configuración de ejemplo completa y lista para producción. Para obtener más información, consulte → Espacio de trabajo de Gitpod.

OpenEMS Backend

En lugar de que Edge y UI se comuniquen entre sí directamente, la comunicación también se puede reenviar a través de Backend. OpenEMS Backend proporciona dos implementaciones de "Backend-to-Backend-Api", que proporcionan una forma de comunicarse con uno o más dispositivos OpenEMS Edge a través de la conexión backend. Están diseñados utilizando el protocolo de comunicación JSON-RPC a través de la conexión REST/JSON (io.openems.backend.b2brest) o mediante Websocket (io.openems.backend.b2bwebsocket). Protocolo de comunicación JSON-RPC a través de la conexión REST/JSON.

OpenEMS Edge

OpenEMS Edge

Info

Entorno de desarrolloEclipse IDE

Arquitectura software

Para un uso productivo, el software generalmente se ejecuta en una puerta de enlace IoT industrial o una placa de desarrollo como una Raspberry Pi con sistema operativo GNU / Linux. Usa algoritmos (controladores) para comunicarse con los dispositivos. Usa los controladores para saber cada segundo el estado de los dispositivos OpenEMS Edge está utilizando la plataforma OSGi para proporcionar un sistema orientado a servicios completamente modular y dinámico. • OSGI (Open Services Gateway Initiative) es una capa sobre Java que permite crear módulos que pueden interactuar entre sí en tiempo de ejecución MULTIPLES MODULOS UNICA INTERFAZ. • OSGi proporciona la capacidad de habilitar, modificar o deshabilitar un componente OpenEMS en cualquier momento, sin necesidad de reiniciar el software. • OSGI proporciona un marco de trabajo que soporta el despliegue dinámico de aplicaciones («Bundles» o módulos).

OpenEMS Edge

INPUT

El modelo input-process-output en OpenEMS Edge maneja la configuración de una imagen de proceso en la fase de entrada y ejecuta los controladores en la fase de proceso, ver figura.

PROCESS

OUTPUT

La fase de salida toma los resultados de la fase de proceso y los aplica, por ejemplo, enciende o apaga la salida digital. Los datos y el histórico de los datos se guardan en la nube, para una aplicación en tiempo real se puede utilizar InfluxDB, que es una base de datos de series temporales diseñada para el almacenamiento rápido y de alta disponibilidad y la recuperación de datos de series temporales. El modelo input-process-output en OpenEMS Edge se ejecuta en un Cycle - implementado por el componente Cycle. Maneja la configuración de una imagen de proceso en la fase de entrada y ejecuta los controladores en la fase de proceso. Además, emite eventos de ciclo que se pueden usar en otros componentes para sincronizarse con el ciclo. La mayoría de los medidores de potencia externos proporcionan mediciones aproximadamente solo una vez por segundo. En este escenario, no es factible ejecutar el ciclo de ejecución con más frecuencia que una vez por segundo.

Output

BEFORE_WRITE

AFTER_WRITE

EXECUTE_WRITE

Info

La ejecución de las Tareas Modbus es gestionada por el ModbusWorker. Ejecuta las Tareas de Escritura tan pronto como sea posible (directamente después del evento EXECUTE_WRITE) - ejecuta las Tareas de Lectura tan tarde como sea posible para tener los valores disponibles exactamente cuando se necesitan (es decir, justo antes del evento BEFORE_PROCESS_IMAGE). Para lograr esto, el ModbusWorker evalúa todos los tiempos de ejecución y 'aprende' un tiempo de retardo ideal, que se aplica en cada Ciclo - el 'CycleDelay' - maneja ModbusComponents defectuosos (es decir, aquellos en los que las tareas han fallado repetidamente) y retrasa la lectura desde/escritura a esos componentes con el fin de evitar que los componentes defectuosos bloqueen todo el bus de comunicación. El retraso máximo es de 5 minutos para la lectura de componentes defectuosos. Los ModbusComponents pueden activar un reintento desde un Componente defectuoso llamando al método retryModbusCommunication().

Info

PROCESS

Durante la fase de "proceso", diferentes algoritmos (controladores) pueden intentar acceder a los mismos recursos, por ejemplo, dos controladores intentan cambiar la misma salida digital. Por lo tanto, es necesario priorizar su ejecución y restringir el acceso según la prioridad. OpenEMS Edge utiliza implementaciones de Scheduler para recibir una lista ordenada de controladores. Los controladores se ejecutan en orden. Los controladores ejecutados posteriormente no pueden sobrescribir un resultado escrito previamente. Toda la fase del proceso se activa a través de Apache.

PROCESS

Programador/Scheduler

Controladores

Controladores

Info

Control por consigna

Control por parametrización

Dispositivos y servicios

Info

Datos de tiempo

Info

InfluxDB

RRD4j

Info

InfluxDB es una base de datos de series temporales diseñada para el almacenamiento rápido y de alta disponibilidad y la recuperación de datos de series temporales. Los datos y el histórico de los datos se guardan en la nube, para una aplicación en tiempo real se puede utilizar InfluxDB, que es una base de datos de series temporales diseñada para el almacenamiento rápido y de alta disponibilidad y la recuperación de datos de series temporales.

Un servicio OpenEMS Edge Timedata es responsable de... valores persistentes de canales a lo largo del tiempo proporcionar datos históricos, por ejemplo, para el historial de la interfaz de usuario de OpenEMS

Tiene código fuente para distintos dispositivos, baterías, inversores...

Es el algoritmo de control que evalúa los datos de entrada y define los puntos de ajuste para el hardware controlado. Idealmente, las implementaciones de controladores siguen el principio KISS (Keep It Simple Stupid), lo que significa que solo llevan a cabo una tarea específica y encapsulada. Este enfoque permite arquitecturas de sistema muy flexibles y evita el código duplicado. Un controlador OpenEMS Edge contiene la lógica de negocio real o el algoritmo real que controla el hardware. La lógica de cada Controlador activo se ejecuta regularmente en cada Ciclo, es decir, una vez por segundo. En cada ciclo de ejecución, por ejemplo una vez cada segundo, el EMS puede enviar un comando de control, lo que permite dos formas diferentes de controlar el hardware: Control por consigna y Control por parametrización. OpenEMS proporciona una gran variedad de controladores de código abierto. Por ejemplo, el OpenEMS Edge Modbus-Slave-API es proporcionado por el "Modbus-API Controller". Como el protocolo Modbus es ampliamente utilizado en el monitoreo y automatización industrial, esto permite un fácil acceso a los canales OpenEMS desde sistemas externos. La configuración del controlador Modbus-API define qué componentes de OpenEMS deben exportarse y estar disponibles a través de la API. Luego genera un protocolo Modbus dinámico que está estructurado en bloques de direcciones que se asignan a componentes de OpenEMS y direcciones de registro Modbus que se asignan a canales OpenEMS.

Durante la fase de "proceso", diferentes algoritmos (controladores) pueden intentar acceder a los mismos recursos, por ejemplo, dos controladores intentan cambiar la misma salida digital. Por lo tanto, es necesario priorizar su ejecución y restringir el acceso según la prioridad. OpenEMS Edge utiliza implementaciones de Scheduler para recibir una lista ordenada de controladores. Los controladores se ejecutan en orden. Los controladores ejecutados posteriormente no pueden sobrescribir un resultado escrito previamente.

Programador/Scheduler

Orden fija

Diariamente

Todo alfabéticamente

Info

Diariamente

Ejecutar siempre antes

Ejecutar siempre después

Este programador puede ejecutar diferentes controladores en diferentes momentos del día de acuerdo con la configuración de "Programación diaria". Controladores que necesitan ejecutarse independientemente de la hora del día como 'ctrlBackend0' y 'ctrlDebugLog0', etc., se puede especificar en la configuración utilizando "Ejecutar siempre antes" y "Ejecutar siempre después".

Toma una lista ordenada de identificadores de componentes. Todos los Controladores restantes se ordenan alfabéticamente por su ID.

ENTRADA Durante la fase de entrada, toda la información relevante, por ejemplo, el "estado de carga" actual de una batería, se recopila y proporciona como una imagen de proceso. Se garantiza que esta imagen de proceso nunca cambiará durante el ciclo. OpenEMS utiliza una "Imagen de Proceso", una técnica bien probada en el campo de la programación de PLC. La idea es desvincular a los productores y consumidores de datos e introducir un búfer central para todos los datos del canal. Este búfer -la Imagen de Proceso- se actualiza sólo una vez en cada ciclo de computación, cuando activa los últimos datos de cada canal.

INPUT

AFTER_PROCESS_IMAGE

BEFORE_PROCESS_IMAGE

Switch Process Image

La implementación de objetos de canal en OpenEMS tiene dos variables de datos: - El campo value que mantiene el valor actualmente activo que debe ser utilizado por los consumidores - El campo nextValue que representa el último dato que se recibió, por ejemplo, a través de la comunicación Modbus. En - y sólo en - 'Switch Process Image' del Ciclo, el nextValue se copia en el campo value. Esto asegura que los datos de la imagen de proceso no cambian durante un ciclo de cálculo.

Info

Info

Info

Info

Info

Info

Info

Lo que se corresponde a la entrada esta entre las dos líneas verdes.

Un componente OpenEMS es el bloque de construcción fundamental en OpenEMS. Dentro del marco OSGi Java utilizado, un componente OpenEMS representa un servicio con requisitos y capacidades.Como ejemplo, un componente OpenEMS puede declarar tener las capacidades de un sistema de almacenamiento de energía (ESS) y, como tal, representa el gemelo digital de un dispositivo real. Se puede implementar un algoritmo de control específico como un componente OpenEMS separado que declara un requisito para un ESS. Usando estos metadatos, estos bloques de construcción están conectados entre sí en tiempo de ejecución y forman un sistema muy flexible. OSGi proporciona la capacidad de habilitar, modificar o deshabilitar un componente OpenEMS en cualquier momento, sin necesidad de reiniciar el software. El recableado de los bloques de construcción ocurre de forma transparente en segundo plano por el marco. Para declarar un componente OpenEMS, la clase Java tiene que la interfaz OpenemsComponent.implement

Una instancia es comparable a un "objeto", es decir, una instancia en tiempo de ejecución de una fábrica con parámetros de configuración definidos. La instancia se denomina entonces un componente OpenEMS y se identifica de forma única por su ID de componente.

Una fábrica es comparable a una 'clase' en el desarrollo de software orientado a objetos que se enriquece con metadatos Java / OSGi como un identificador de cadena único y define un conjunto de parámetros de configuración requeridos. Una fábrica implementa una o más Naturalezas para indicar que proporciona todos los canales definidos por la Naturaleza. Además, una fábrica puede definir otros canales que son específicos para la implementación individual.Ejemplo: La "fábrica" OpenEMS Edge para la batería BMW implementa la naturaleza. Además, declara que canales como ese no están disponibles y son requeridos por cada implementación de batería.BatteryAmbientTemperature

Las naturalezas extienden las interfaces Java normales con 'Canales'. Si un componente implementa una naturaleza, también debe proporcionar los canales requeridos. Por ejemplo, el simulador del sistema de almacenamiento de energía (ESS) Simulator.EssSymmetric.Reacting implementa la interfaz Ess y, por lo tanto, debe proporcionar un canal que proporcione el "Estado de carga" actual de la batería.Soc Ciertas categorías de dispositivos y servicios proporcionan el mismo tipo de información (es decir, canales). Para agrupar estos dispositivos y servicios similares, OpenEMS define "Naturalezas" como conjuntos de características y atributos que deben ser proporcionados por cada componente que los implementa. Es decir, una naturaleza extiende una interfaz Java normal con canales. Una naturaleza se define como un conjunto de características y atributos. En OpenEMS Edge, una naturaleza es una "interfaz" de Java, que define los canales requeridos de un componente OpenEMS en implementación. Ejemplo: La naturaleza de BATERÍA define canales como , y (estado de carga) que deben ser proporcionados por cada implementación de batería.BatteryChargeMaxVoltageDischargeMaxVoltageSoc. El hardware físico se abstrae en OpenEMS Edge usando Natures. A Nature define un conjunto de características y atributos que deben ser proporcionados por cada componente de OpenEMS que lo implementa. Estas características están definidas por canales. Por ejemplo, una implementación de un (Sistema de almacenamiento de energía), necesita proporcionar un -Channel (Estado de carga de la batería).EssSoc Técnicamente, las naturalezas se implementan como paquetes de API OSGi.

Cada componente de OpenEMS tiene un conjunto definido de puntos de datos. Estos puntos de datos se denominan "Canales". Cada uno representa una sola pieza de información sobre un componente. Por definición, cada canal tiene un ID único, el "Channel-ID", dentro de su componente padre. Los canales se definen mediante metadatos como texto descriptivo, modo de acceso (, , ), tipo de datos (, , , etc.) y unidad de medida (, , , etc.). Depende del componente OpenEMS proporcionar la entrada para sus canales de lectura, así como desencadenar acciones en los canales de escritura.read-onlyread-writewrite-onlystringintegerfloatWattVoltDegree Celsius. Un canal representa una sola pieza de información sobre un componente; enriquecido con metadatos como una descripción, unidad de medida y más. Ejemplo: El canal de la naturaleza de la batería tiene un texto descriptivo "Voltaje máximo para cargar", se define como tipo Entero con la unidad Amperio.ChargeMaxVoltage. Ejemplo: Un componente OpenEMS que representa un dispositivo conectado a través del protocolo de comunicación Modbus lee continuamente los datos, como la potencia medida actual y proporciona los datos en sus canales. Otros componentes del sistema pueden utilizar los datos del canal para su aplicación, por ejemplo, como entrada para un algoritmo de control, para analizarlos, almacenarlos localmente o publicarlos a través de una interfaz de programación de aplicaciones (API).

Bridge

Modbus

Imprimir información detallada de registro en la Consola

Ejecución de Tareas Modbus

Canales

Prioridad de tareas

Info

Info

Info

Info

La ejecución de las Tareas Modbus es gestionada por el ModbusWorker. Ejecuta las Tareas de Escritura tan pronto como sea posible (directamente después del evento EXECUTE_WRITE) - ejecuta las Tareas de Lectura tan tarde como sea posible para tener los valores disponibles exactamente cuando se necesitan (es decir, justo antes del evento BEFORE_PROCESS_IMAGE). Para lograr esto, el ModbusWorker evalúa todos los tiempos de ejecución y 'aprende' un tiempo de retardo ideal, que se aplica en cada Ciclo - el 'CycleDelay' - maneja ModbusComponents defectuosos (es decir, aquellos en los que las tareas han fallado repetidamente) y retrasa la lectura desde/escritura a esos componentes con el fin de evitar que los componentes defectuosos bloqueen todo el bus de comunicación. El retraso máximo es de 5 minutos para la lectura de componentes defectuosos. Los ModbusComponents pueden activar un reintento desde un Componente defectuoso llamando al método retryModbusCommunication().

Las tareas de lectura pueden tener dos prioridades diferentes, que se definen en la definición de ModbusProtocol: - ALTA: la tarea se ejecuta una vez por ciclo - BAJA: sólo una tarea de todas las tareas de prioridad BAJA definidas de todos los componentes registrados en el mismo puente se ejecuta por ciclo Las tareas de escritura siempre tienen prioridad ALTA, es decir, un punto de ajuste siempre se ejecuta tan pronto como sea posible, siempre que el componente no esté marcado como defectuoso.

Cada Puente Modbus proporciona Canales para información más detallada: - CycleTimeIsTooShort: el Ciclo-Tiempo global configurado es demasiado corto para ejecutar todas las tareas planificadas en un Ciclo - CycleDelay: ver 'CycleDelay' en la descripción de 'ModbusWorker' más arriba.

A menudo es útil imprimir información detallada de registro en la Consola para propósitos de depuración. El registro puede habilitarse a nivel de tarea en la definición del ModbusProtocol añadiendo .debug() o globalmente por Modbus Bridge mediante el parámetro de configuración. NONE: No mostrar logs DEBUG_LOG: Muestra información básica de registro a través de Controller.Debug.Log READS_AND_WRITES: Muestra los registros de todas las peticiones de lectura y escritura. READS_AND_WRITES_VERBOSE: Muestra los registros de todas las peticiones de lectura y escritura, incluyendo los valores hexadecimales o binarios reales de la petición y la respuesta. READS_AND_WRITES_DURATION: Muestra los registros de todas las peticiones de lectura y escritura, incluyendo la duración real de cada petición. READS_AND_WRITES_DURATION_TRACE_EVENTS: Muestra los registros de todas las solicitudes de lectura y escritura, incluido el tiempo de duración real por solicitud y rastrea la máquina de estados interna basada en eventos. El nivel de registro a través del parámetro de configuración se puede cambiar en cualquier momento durante el tiempo de ejecución sin efectos secundarios en la comunicación.

Configurar e iniciar el simulador

Run OSGi

Info

Apache Felix Web ConsoleConfiguration

Info

Configuración de controladores

Servidor web. La consola web es la interfaz estándar para la configuración de OSGi.Proporciona una interfaz de usuario para editar las distintas propiedades, donde es posible seleccionar valores de listas predefinidas. Como tal, es el método más fácil de usar. Cualquier configuración realizada con la consola web se aplica inmediatamente y se aplica a la instancia actual, independientemente del modo de ejecución actual o de cualquier cambio posterior en el modo de ejecución.

OpenEMS Edge está utilizando la plataforma OSGi para proporcionar un sistema orientado a servicios completamente modular y dinámico. OSGI (Open Services Gateway Initiative) es una capa sobre Java que permite crear módulos que pueden interactuar entre sí en tiempo de ejecución MULTIPLES MODULOS UNICA INTERFAZ.

• OSGi proporciona la capacidad de habilitar, modificar o deshabilitar un componente OpenEMS en cualquier momento, sin necesidad de reiniciar el software.
• OSGI proporciona un marco de trabajo que soporta el despliegue dinámico de aplicaciones («Bundles» o módulos)
• La instalación, arranque, parada, actualización y desinstalación de bundles se realiza dinámicamente en tiempo de ejecución sin tener que detener por completo la plataforma.
• Es una arquitectura orientada a servicios.

Bundles.OSGi es un framework de Java para desarrollar y desplegar módulos de software. Cada bundle es un conjunto acoplado, una colección que de clases, jars, y archivos de configuración que se pueden cargar dinámicamente, en las cuales se declara explícitamente sus dependencias externas, si es necesario. El framework está dividido conceptualmente en las siguientes partes: BundlesLos bundles son componentes en formato de archivos JAR con el agregado de archivos cabecera llamados manifest headers (manifiesto de encabezado). Un bundle es un conjunto de clases Java y de recursos adicionales que incluye el agregado de un archivo manifiesto detallado MANIFEST.MF que informa de todo el contenido, así como de los servicios adicionales que son necesarios para dar al grupo de clases de Java comportamientos más sofisticados, hasta el punto de considerar a todo el agregado como un componentet.

Configuración de controladores

Controller Api Websocket

Controller Ess Balancing

Configurar un programador

Registro de depuración del controlador

Info

Info

Info

Info

Simulador EssSymmetric Reacting

Simulador GridMeter Acting

Configure un origen de datos de perfil de carga

Info

Info

Info

El Programador es responsable de ejecutar los algoritmos de control (Controllers) en orden y define el ciclo de aplicación OpenEMS Edge. En este caso lo hace alfabeticamente

Configure las salidas de depuración en la consola

Utiliza un servicio en Apache que le proporciona el Excel con los datos. Configure un origen de datos de perfil de carga estándar simulado. Configuración de Simulator DataSource: CSV Predefinido como fuente de datos de perfil de carga estándar

Coge los datos del punto anterior. Configure el para hacer referencia a la fuente de datos configurada anteriormente. Esta configuración hace que el medidor de cuadrícula simulado tome los datos de perfiles de carga estandarizados como parámetro de entrada. 'Actuación' en el nombre 'Simulador GridMeter Acting' se refiere al hecho de que este medidor proporciona datos activamente, a diferencia de un dispositivo simulado 'Reaccionando' que reacciona sobre otros componentes: Esta vez aparecerán algunos registros más. Lo más importante es que muestran que el medidor de red ahora mide (simula) un valor de potencia y el consumo se deriva directamente de este valor, porque aún no se ha configurado ningún sistema fotovoltaico o sistema de almacenamiento de energía.

Configure un sistema de almacenamiento de energía de reacción simulada.

Configurar el algoritmo de optimización de la BATERIA (autoconsumo): Controller Ess Balancing. Configure el y para hacer referencia a los componentes configurados anteriormente.Ess-ID'ess0'Grid-Meter-ID'meter0'. El registro de depuración ahora muestra datos para la batería, pero la potencia de carga / descarga permanece en "0 W" y el estado de carga permanece en "50 %" según lo configurado. El siguiente paso es configurar un algoritmo de control que le diga a la batería que se cargue o descargue dependiendo de la potencia medida por el medidor de red simulado.

Configure el controlador de API de websocket: Controller Api Websocket. El Websocket de la API del controlador es necesario para que la interfaz de usuario de OpenEMS pueda conectarse a OpenEMS Edge localmente.