EnergyBASE: Iot-based solution for innovative energy management

The market for electrical power has changed substantially during the last couple of years. Central power plants are getting less important while decentralised power production of regenerative energy becomes more common. The so called “Energiewende” in Germany, a political program to shut down nuclear power plants and foster solar power and wind farms, has fueled this development and allows private households to sell energy into the public power grid. EnBW, one of Germany’s biggest producer of electrical energy is driving a project which helps the typical home owner to migrate from mere energy consumption to becoming a “prosumer” (producer-consumer) with local power production and storage by solar panels and stationary batteries. “EnergyBASE” represents a paradigm shift for EnBW. Rather than just selling power to their customers, EnBW is now offering technology and process know-how for energy management.

EnergyBASE system components

The EnergyBASE system is comprised of the intelligent edge component (EnergyBASE hardware and software stack), an optional backend that integrates a variety of services, and a modern web UI provided by the local webserver on its EnergyBASE device. This customer frontend is optimized for desktop and mobile devices. As shown in the Illustration 2, the frontend is accessible through the local network and (if activated) also from remote.

EnergyBASE device

The EnergyBASE device contains a 450 MHz ARM9 processor, 128 MB RAM and 4 GB of flash storage. It provides ethernet and serial interfaces and also a polyphase electric meter. The EnergyBASE software stack is made up by a MicroDoc port of Oracle Java™ SE Embedded 8 JRE and a Smart Home OSGi framework.

EnergyBASE device system architecture

The EnergyBASE applications are written in Java. This allows for portable code for a variety of target platforms. While the project teams develop on Windows, Linux and Mac system, the same Java code can be used on cloud based test- and demo instances as well as on the actual target hardware of the EnergyBASE without any code changes. The


Java promise “write once, run anywhere” is real. The EnergyBASE architecture is also based on the OSGi component model. By choosing this technology, we are able to provision, deploy, start, stop and remove software components (called “bundles”) on-the-fly on remote devices without interrupting operation or other services on the device.

Bundles can be updated individually or within groups, which gives us the ability to react quickly and effectively to new requirements and potential problems in production environment.

The component model is used to assemble customer specific applications depending on parameters like hardware release, customer contracts, configuration, stage or use case scenario. As shown in the Illustration 3, there are many possibilities to combine the application bundles: multiple adapters to handle different kinds of devices from different manufacturers, implementation of protocols for communication purposes, external service connectors, selectable forecast algorithms, optimization methods to use the energy in an efficient way and much more.

There are a few preliminary decisions you’ll want to make while defining an OSGi bundle. One of these decisions is the dependency to other bundles. Each bundle can be independently defined or in conjunction with other. For example, let us assume Bundle B is dependent on Bundle A. In this case, it is sure that the startup process of bundle B will be initialized after bundle A is already in the correct state (started). In more concrete manner: it will not happen that one of the device adapter bundles get started while the necessary protocol implementation bundle is not available.
Furthermore, we developed a mechanism to define relationships between services and the ability of injection. According to the inversion-of-control pattern, our ServiceMonitor (or more specifically the OSGi BundleContext) observes and manages the complete lifecycle of each service and provides the requested instance. At this point the relationship between dependencies on Bundle- and Service-Layer becomes much more important. Following the Illustration 4 we can see, that Service X is injected in Service Z. The instance of Service X can only be created when Bundle B is running. Due to the relationship between Bundle B to Bundle A, its running state is also necessary. This small example shows that this technique give us a handy way to control dependencies but can also grow to a complex construct really fast. In practice we keep the dependencies as small as possible.

Despite having the loosely coupled components, the ability to communicate to each other by means of an event-based publish/subscribe mechanism is still present. In addition to the general properties of the OSGi-based platform, we also benefit from various add-ons created by the OSGi-Engine. It provides several features to monitor and manage external devices. The EnergyBASE behaves in a very performant and smooth way notwithstanding to the huge amount of functionality of the engine and the complexity (see Illustration 3) of our application.

The ability to communicate with our backend through a (SSL encrypted) TCP socket connection is already provided by the used OSGi engine. The EnergyBASE is obviously completely useable without an active connection to the internet or our backend. But there are some handy features, also used by most of our customers, like remote access through
the web (https://energybase.enbw.com), mail sending in case of malfunctioning or weather consumption which requires an active connection.

EnergyBASE backend

Our backend system is based on the “mPower Remote Management” (mPRM). It is built by using the same software stack Java/OSGi, as the EnergyBASE, which brings us many advantages. It provides some essential features out-of-the-box like monitoring external devices, configuration, remote software updates and the internal repository to handle different versions of software components. We are able to extend the existing set of functionalities by providing self-developed bundles. We use this technique, for example, to consume weather-data or electricity prices from external service providers, sending emails and push notifications or to activate and deactivate EnergyBASE(s).

The mPRM provides a generic RESTful API which allows executing its functions via HTTPS service calls. This feature is very convenient to develop automated test-cases which implement complete test scenarios over all system components.

Due to the use of Java and OSGi on server and device side, it’s easy to implement distributed services for both components. For example, in case the EnergyBASE is connected to a server, weather data can be consumed and prepared on the server-side, while the device is only collecting the relevant regional data from the backend. Furthermore, it is possible to shift functions from the EnergyBASE device up to the server to process computationally intensive operations.

Further aspects of the general software development process are affected by the homogeneous choice of technology. We can use the same IDE, with the same set of plugins and also the same testing framework to develop client and server bundles. Also, the build and publishing process on our CI system does not need any changes. This may not sound very important but when you have already worked with totally different technology stacks on the client and server side you will be very pleased with the simplicity of this approach.

Frontend Applications

The frontend applications are implemented using modern web-app technologies and are provided to allow end customers access to statistics and process control via desktop and mobile browser. Besides its browser-based access there exists also hybride, HTML5-based mobile web applications.The set of functionality is not as large as the default web application but it contains all important data to get a broad overview about the current energy production, batteries state of charge and further more (see
Illustration 6).

Each UI related bundle contains three directories to provide its content for different environments: one folder just for mobile application related files, one for web browser files, and one shared folder for both cases. The CI system chooses the right files in conjunction to the target environment while building the software.

The mobile applications are currently available for Android and iOS as well.

Virtualization & Testing

We are able to virtualize every component of the whole system, including the devices and the device adapters. This technology is very useful when it comes to testing individual device configurations as well as performing integration testing. Our continuous build process makes use of automated testing during nightly builds. It is also possible to model complete sample installations (virtual households) that can be used for training of the system maintenance staff or to support the sales process: it is always very convincing to demonstrate a live system rather than showing off a slide deck.

Creating a “white label” solution from a branded product

Our customer EnBW decided to offer a “white label” variant of the EnergyBASE product due to market demand. The main challenge for an OEM product provider is to allow for flexible extensions, customization and customer specific skinning of the applications. Our aim was to provide mechanisms for customizing the EnergyBASE software and offer customers limited or changed set of functions and UIs compared with the original software.

Backend changes

Since our software is implemented and structured in OSGi bundles, it is relatively easy to add, replace or remove functionality by deploying or removing bundles. So adding “white label” capabilities to our system was not really a technical challenge since the underlying architecture directly supports the necessary configurability.

To extend the backed for OEM use, we had to extend our system database for multi-client capabilities. This was done by extending the data model to include contract data for the OEM customers. The contract types are being used to configure which part of the software e.g. which OSGi bundle is included in the runtime environment for which particular contract.

The customer can also order (or implement) some kind of extra functionality besides the preexisting bundles and include them into his contract configuration.

In addition it was also necessary to provide a way to set specific contract information for any particular EnergyBASE device and to integrate the dynamically configured extensions into the systems management. mPRM provides an appropriate technology (called “control units”) which we used to monitor custom extensions on the backend.

 

Device changes

As a part of the implementation of the EnergyBASE device software, we developed a possibility to mark a bundle within its “Manifest.mf” configuration file as “ManagedByContract”. Such bundle will only be loaded when the currently applicable contract calls for it. The contract information is managed by a software component called ContractService. This service receives every change in the contract from the backend instantly through an event system and begins to start/stop different bundles according to the new configuration.

Additionally, we did many changes to the local UI layer and separated these bundles into smaller pieces. Now onwards, there is one bundle with the standard UI and one additional for each customer. This customer bundle does not only contains UI stuff but also arbitrary code to solve the required features or change existing behavior. In the case of UI, it contains just the difference between standard and customer specific CSS/HTML/Assets. The Illustration 7 demonstrates this kind of change in Web-UI just by changing the contract. Everything happens without any reboot or manual browser refresh.

Due to the dependencies between bundles shown in Illustration 4 it is possible to imagine that there can be several tricky situations to think about while developing this part.

Conclusion

The Java/OSGi software platform used for the EnergyBASE project has proven to be stable, flexible and extensible. Homogeneous runtime environments on all system components allow us to distribute code and functionality as needed. In particular, the OSGi component model and it’s hot deploy/undeploy
capabilities helped us to quickly implement the customer requirement to expand the system from a proprietary offering into an open multi-client platform.

Even new requirements, like opening up the system as a hosting platform for domain specific third party apps would not be a significant challenge for this robust architecture.

 

The first OEM customer

Let’s have a quick look on the requirements of our first real world OEM customer and the resulting efforts in development

  1. The EnergyBASE web app should not be available anymore after the installation is done.
    => Easy. The UI bundle will be marked as “ManagedByContract” and not included in the related contract-configuration.
  2. The customer wants to develop its own mobile application which displays the data collected by the EnergyBASE every five minutes.
    => Just implement a mechanism to send the needed data every five minutes to the mPRM within the customer-specific bundle. A kind of observer mechanism will be triggered after receiving the data on the mPRM side. After that, just forward it to the customer.
  3. Based on some cooperation contract, only two manufacturers should be available in this configuration. A specific solar inverter and one type of battery. Other devices and manufacturer should not be supported.
    => The same procedure as we did in point 1. The device adapters are already split into separate bundles for each manufacturer. Just add the allowed devices in related configuration.
  4. The remote support access should be activated all the time.
    => The original Version of EnergyBASE software does not force the user to enable the option for remote access. In this case, we just have to override this option within the customer-specific bundle.
  5. Additional function: Each device should consume and store the stock prices for electricity by using a defined service once per day.
    => Create a new “ManagedByContract” bundle and add it to the contract configuration.
  6. Additional function: The customer should consume energy for free to load its battery in the time periods with negative prices (based on the data from the previous point) until a specific amount is reached.
    => The same procedure as described in point five. This real-world example clearly shows that significant deviations between customer requirements and default implementation can be managed in a very clean way. We don’t need complex and error prone if/then/else code to solve the challenge.
  7. A split of functionality and responsibility on our bundles and the overall modular approach help us manage most of the requirements with a very low effort on the development side. All complex enhancements were  separated in custom bundles without any need to change the existing code.

Refrences:

EnBW Energie Baden-Württemberg AG – https://enbw.com
EnergyBASE – https://energybase.com
Oracle Java SE 8 Embedded – https://oracle.com/technetwork/java/embedded
ProSyst mBS Smart Home – https://dz.prosyst.com/pdoc/mBS_SDK_7.5
OSGi – https://www.osgi.org/