2 | Interrupt Inside Interrupt Inside |3 4 | Interrupt Inside Interrupt Inside |5 SMART HOME Java promise “write once, run anywhere” Furthermore, we developed a mecha- ergyBASE behaves in a very performant available for Android and iOS as well. is real. The EnergyBASE architecture nism to define relationships between and smooth way notwithstanding to is also based on the OSGi component services and the ability of injection. the huge amount of functionality of the VIRTUALIZATION & TESTING model. By choosing this technology, According to the inversion-of-control engine and the complexity (see Illustra- We are able to virtualize every compo- we are able to provision, deploy, start, pattern, our ServiceMonitor (or more tion 3) of our application. nent of the whole system, including the stop and remove software components specifically the OSGi BundleContext) devices and the device adapters. This (called “bundles”) on-the-fly on remote observes and manages the complete The ability to communicate with our technology is very useful when it comes devices without interrupting operation lifecycle of each service and provides backend through a (SSL encrypted) TCP to testing individual device configura- or other services on the device. the requested instance. At this point socket connection is already provided by tions as well as performing integration the relationship between dependencies the used OSGi engine. The EnergyBASE testing. Our continuous build process Bundles can be updated individually or on Bundle- and Service-Layer becomes is obviously completely useable without makes use of automated testing during within groups, which gives us the ability much more important. Following the an active connection to the internet or nightly builds. It is also possible to model to react quickly and effectively to new Illustration 4 we can see, that Service our backend. But there are some handy complete sample installations (virtual requirements and potential problems in X is injected in Service Z. The instance features, also used by most of our cus- households) that can be used for train- production environment. of Service X can only be created when tomers, like remote access through ing of the system maintenance staff or Bundle B is running. Due to the rela- the web (https://energybase.enbw.com), to support the sales process: it is always The component model is used to as- tionship between Bundle B to Bundle A, mail sending in case of malfunctioning very convincing to demonstrate a live semble customer specific applications its running state is also necessary. This or weather consumption which requires system rather than showing off a slide depending on parameters like hard- small example shows that this tech- an active connection. deck. ware release, customer contracts, con- nique give us a handy way to control figuration, stage or use case scenario. Illustration 5: EnergyBASE backend (mPRM) CREATING A “WHITE LABEL” SOLUTION As shown in the Illustration 3, there are FROM A BRANDED PRODUCT many possibilities to combine the ap- Our customer EnBW decided to offer a plication bundles: multiple adapters to or electricity prices from external service tionality is not as large as the default “white label” variant of the EnergyBASE handle different kinds of devices from providers, sending emails and push no- web application but it contains all impor- product due to market demand. The different manufacturers, implementa- tifications or to activate and deactivate tant data to get a broad overview about main challenge for an OEM product pro- tion of protocols for communication This feature is very convenient to develop automated EnergyBASE(s). the current energy production, batteries vider is to allow for flexible extensions, purposes, external service connectors, test-cases which implement complete test scenarios state of charge and further more (see customization and customer specific selectable forecast algorithms, optimi- over all system components. The mPRM provides a generic RESTful Illustration 6). skinning of the applications. Our aim zation methods to use the energy in an API which allows executing its functions was to provide mechanisms for cus- efficient way and much more. via HTTPS service calls. This feature is Each UI related bundle contains three tomizing the EnergyBASE software and very convenient to develop automated directories to provide its content for offer customers limited or changed set There are a few preliminary decisions dependencies but can also grow to a ENERGYBASE BACKEND test-cases which implement complete different environments: one folder just of functions and UIs compared with the you’ll want to make while defining an complex construct really fast. In prac- Our backend system is based on the test scenarios over all system compo- for mobile application related files, one original software. OSGi bundle. One of these decisions is tice we keep the dependencies as small “mPower Remote Management” (mPRM). nents. for web browser files, and one shared the dependency to other bundles. Each as possible. It is built by using the same software folder for both cases. The CI system BACKEND CHANGES bundle can be independently defined or stack Java/OSGi, as the EnergyBASE, Due to the use of Java and OSGi on chooses the right files in conjunction to Since our software is implemented and in conjunction with other. For example, Despite having the loosely coupled which brings us many advantages. It server and device side, it’s easy to im- the target environment while building structured in OSGi bundles, it is relative- let us assume Bundle B is dependent components, the ability to commu- provides some essential features out-of- plement distributed services for both the software. ly easy to add, replace or remove func- on Bundle A. In this case, it is sure that nicate to each other by means of an the-box like monitoring external devices, components. For example, in case the tionality by deploying or removing bun- the startup process of bundle B will be event-based publish/subscribe mecha- configuration, remote software updates EnergyBASE is connected to a server, The mobile applications are currently dles. So adding “white label” capabilities initialized after bundle A is already in the nism is still present. In addition to the and the internal repository to handle dif- weather data can be consumed and to our system was not really a technical correct state (started). In more concrete general properties of the OSGi-based ferent versions of software components. prepared on the server-side, while the challenge since the underlying archi- manner: it will not happen that one of platform, we also benefit from various We are able to extend the existing set device is only collecting the relevant re- Illustration 6: tecture directly supports the necessary the device adapter bundles get started add-ons created by the OSGi-Engine. of functionalities by providing self-devel- gional data from the backend. Further- EnergyBASE Mobile App configurability. while the necessary protocol implemen- It provides several features to monitor oped bundles. We use this technique, more, it is possible to shift functions tation bundle is not available. and manage external devices. The En- for example, to consume weather-data from the EnergyBASE device up to the To extend the backed for OEM use, we server to process computationally inten- had to extend our system database for sive operations. multi-client capabilities. This was done by extending the data model to include Further aspects of the general software contract data for the OEM customers. Illustration 4: Bundle and Service dependencies development process are affected by The contract types are being used to the homogeneous choice of technology. configure which part of the software e.g. We can use the same IDE, with the same which OSGi bundle is included in the set of plugins and also the same testing runtime environment for which particu- framework to develop client and server lar contract. bundles. Also, the build and publishing process on our CI system does not need The customer can also order (or imple- any changes. This may not sound very ment) some kind of extra functionality important but when you have already besides the preexisting bundles and in- worked with totally different technology clude them into his contract configura- stacks on the client and server side you tion. will be very pleased with the simplicity of this approach. In addition it was also necessary to pro- vide a way to set specific contract infor- FRONTEND APPLICATIONS mation for any particular EnergyBASE The frontend applications are imple- device and to integrate the dynamically mented using modern web-app technol- configured extensions into the systems ogies and are provided to allow end cus- management. mPRM provides an ap- tomers access to statistics and process propriate technology (called “control control via desktop and mobile brows- units”) which we used to monitor custom er. Besides its browser-based access extensions on the backed. there exists also hybride, HTML5-based mobile web applications.The set of func- >> 6 | Interrupt Inside Interrupt Inside |7 SMART HOME A COMPLETE TECHNOLOGY PARTNER Illustration 7: UI effects by changing contract for smarter embedded and IoT solutions DEVICE CHANGES As a part of the implementation of the EnergyBASE device software, we de- THE FIRST OEM CUSTOMER veloped a possibility to mark a bundle Let’s have a quick look on the requirements of our first real world OEM within its “Manifest.mf” configuration file customer and the resulting efforts in development. Data Respons is a full-service, independent technology company and a leading player as “ManagedByContract”. Such bundle will only be loaded when the currently 1. The EnergyBASE web app should not be available anymore after the in the industrial IoT and the embedded solutions market. We provide R&D services applicable contract calls for it. The con- installation is done. and embedded solutions to OEM companies, system integrators and vertical product suppliers tract information is managed by a soft- => Easy.