How OSGi drives cross-sector energy management - Jörn Tümmler (SMA Solar Technology)

How OSGi drives cross
sector energy management
SMA Solar Technology AG

WHO IS SMA?
> SMA is an energy equipment supplier founded in 1981 and headquartered
near Kassel in the middle of Germany
> Main products are solar inverters for photovoltaics systems
> These products are complemented by components for energy management,
system monitoring and data analysis and the world’s largest PV monitoring
portal
> More than 3,000 employees, thereof 500 in technology
> Since 2018 SMA is a contributing associate of the OSGi alliance
16.11.2018 2How OSGi drives cross sector energy management, Jörn Tümmler
STP 6.0 with integrated MLPE-communication CORE1, 50 kW Sunny Boy Storage 6.0 ennexOS energy management platform

AGENDA
1
2
3
4
What is cross sector energy management?
Searching for a solution
Getting started with OSGi
Getting lost
5 Starting over

WHAT DOES CROSS SECTOR ENERGY MANAGEMENT MEAN?
5
The connectivity of all energy
sectors is crucial for the new energy
world. All different systems need to
be continually optimized to make the
most efficient use of energy.
The Internet of Things (IoT)
is the technical basis for
connecting and managing
different devices. In the energy
market, IoT is a driving force to
create the future of energy.

MAIN GOALS AND REQUIREMENTS
> Provide a platform for advanced energy management:
> Extendable by new protocols for easy integration
> Extendable data-processing facilities to combine different control and energy management strategies
> High throughput of data for monitoring and control commands
> Portable solution to run on different ARM- and X86 based systems
> Consolidate the portfolio of existing data-loggers and management devices:
> Improve our software-architecture and bring it to next level of modularity:
> Although we had already a software library with modules we had dependency issues and inadequate life-cycle
mechanisms
Multigate Webconnect Home Manager WebBox RS485 WebBox BT Cluster Controller SC30COMPower Plant Controller

AGENDA
1
2
3
4
Getting lost
5 Starting over

EXAMPLE ARCHITECTURE
Investigations showed a typical blueprint for IoT
gateways:
> Component-based development
> Central data-cache or data-bus
> Pluggable extensions
> Several OSGi based solutions available
> We’ve evaluated four OSGi based solutions:
> Two commercial solutions
> Two open source solutions
> The open source solutions allowed us to test the new
technology regarding performance and usability
> … and also to got in touch with OSGi

OSGI LOOKS PROMISING, BUT HOW TO START?
> The first plan was to use one of the open source solutions as basis
> This was discarded because of technical limitations and high efforts to adapt it to our needs
> To benefit from the advantages of a component based development, it was decided to develop an own framework based on
OSGi, but tailored to the needs of SMA
> It was clear that there would be a “learning curve” to establish this new technology:
11
Source: http://enroute.osgi.org/book/100-introduction.html
How to lower the entry barrier and benefit from OSGi?

AGENDA
1
2
3
4
Getting lost
5 Starting over

INITIAL SITUATION
> We had a team of experienced developers with some knowledge of Java, but no OSGi experience
> We knew how to develop communication gateways and energy managers …
> … but chances were high that the new system would not taking real advantage of OSGi
> Because of this, we had the following “master-plan”:
> Train the team in Java and OSGi
> Get support from external OSGi experts –
at least one expert should be on-site
> Develop an initial design together with the OSGi experts
> OSGi experts should also accompany the team when developing the system

INITIAL DESIGN
> In several workshops we developed the initial design
> The input of the OSGi experts resulted in a more fine grained service-architecture
> Finally we combined the best of both worlds:
OSGi concepts
> Eclipse with BndTools as development environment
> OSGi R6 with Java 8:
> enRoute (classic) as Basis
> Apache Felix runtime
> Declarative Services
> Configuration Admin
> Use WhiteBoard pattern for notifications, aggregations
> Felix WebConsole and Gogo Shell for debugging
SMA concepts
> Central data-cache to store runtime information
> Convert all incoming data into a “normalized” meta-data-
model
> Use “duck-typing” to identify data which needs to be
processed
> Matlab for control algorithms
> Swagger/OpenAPI to define REST APIs for ui and portal
communication

USE A META DATA MODEL TO UNIFY DATA
16.11.2018
17
How OSGi drives cross sector energy management, Jörn Tümmler
Name Type Unit
Metering.GridMs.TotWIn Scalar W
Metering.GridMs.TotWOut Scalar W
… … …
Protocol Identifier Scaling Destination
Reg500088 0,1 Metering.GridMs.TotWIn
Reg500089 0,1 Metering.GridMs.TotWOut
Protocol Identifier Scaling Destination
Id-6100-423AD 0,01 Metering.GridMs.TotWIn
Id-6100-423AF 0,01 Metering.GridMs.TotWOut
Protocol Identifier Scalin
g
Destination
0x346330 0,001 Metering.GridMs.TotWIn
0x346331 0,001 Metering.GridMs.TotWOut
Protocol A
Protocol B
Protocol C
> The SMA Meta Model defines about 2000 data-points
> Each data-point has a fixed meaning, type, unit, etc.
> It therefore defines the ‘semantics’ of data
> A communication driver needs to map its information into
the meta-model and vice versa
> Using the meta-model has the following advantages:
> The data-processing applications can rely on the
protocol independent definition of data-points
> Information can be mapped between protocols
SMA Meta Model

COMMUNICATION LAYER
> Integrating different devices is crucial for an energy management system
> Different aspects of a communication driver are modeled by dedicated services:
Detects devices, creates and removes them
One service for each device
Enumerates all drivers and visible devices
Provided, if a device needs to be polled
Provided, if a device can process parameters

DATA PROCESSING LAYER
> Data processing is offered at different layers of abstraction:
Get notified about any change
Get notified about some changes
Get notified if schemas change
Perform automatic data transformations
on update:
• Direct mapping
• Aggregation
• Mapping
• Merging
• Filtering
• Fallback

DATA PROCESSING – VIEW EXAMPLE
20
@Component
public class PowerViewExample {
interface MyView extends DeviceSchema {
@DataMember(id = DataMembers.Measurement.METERING_GRIDMS_TOTWIN_STRING)
Double getTotWIn();
@DataMember(id = DataMembers.Measurement.METERING_GRIDMS_TOTWOUT_STRING)
Optional<Double> getTotWOut();
}
@Reference DataViewAdmin dataViewAdmin;
DataView<MyView> dataView;
@Activate void activate() {
dataView = dataViewAdmin.createView(MyView.class);
dataView.onUpdate(this::handleUpdate);
}
@Deactivate void deactivate() {
dataView.close();
}
void handleUpdate(DataViewEvent<MyView> event) {
System.out.println("TotWin :" + event.instance.getTotWIn());
event.instance.getTotWOut().ifPresent(d -> System.out.println("TotWOut:" + d));
}
}

AGENDA
1
2
3
4
Getting lost
5 Starting over

FIRST DEVELOPMENT STARTED PROMISING …

… but then we got more and more problems …

TOP 5 OSGI PROBLEMS – AND HOW WE DEAL WITH THEM
> API design
> Dynamics
> Whiteboard pattern and lifecycle of listeners which can
come and go at any time
> Dealing with concurrency issues
> Cyclic dependencies
> Start order / groups of loosely coupled services
( diagnosis subsystem)
> “Service jojos” with optional configurations
> Strange resolving errors
> Cohesion (“glue bundles”)
> Complex configurations
> Make APIs as small as possible
> Avoid cyclic dependencies; consider WhiteBoard pattern
> Avoid own life-cycle methods
> Provide a library as dispatcher that handles life-cycle issues
> Use immutable data, concurrent data-structures with queues
> Combine mandatory w. optional references; register manually
> Use the “aggregate state” to configure groups
> Only use mandatory configurations
> Revise im- and exports
> Check the contents of bundles and split them
> Split configurations; use JSON as “last resort”

DEALING WITH DYNAMICS - EVENT-DISPATCHER UTILITY CLASS
@Component
public class WhiteBoardDispatcherImpl {
final EventDispatcher<Listener> eventDispatcher =
new BackgroundEventDispatcher<>();
@Reference(cardinality =
ReferenceCardinality.MULTIPLE, //
policy = ReferencePolicy.DYNAMIC)
void addPublisher(Publisher publisher) {
eventDispatcher.addListener(publisher);
}
void removePublisher(Publisher publisher) {
eventDispatcher.removeListener(publisher);
}
public void notifyListeners(Event event) {
eventDispatcher.dispatch(l -> l.notify(event));
}
}
@Component
public class SimpleWhiteBoardDispatcherImpl {
@Reference
volatile List<Listener> listeners;
public void notifyListeners(Event event) {
listeners.foreach(l -> l.notify(event));
}
}
Problematic Whiteboard Dispatcher Whiteboard Dispatcher with helper class

DEALING WITH DYNAMICS – AGGREGATE STATE
More details on http://aqute.biz/2017/04/24/aggregate-state.html
@Component(property={"aggregate.state=diagGroup", "diagGroup=conditions" })
@Component(property={"aggregate.state=diagGroup", "diagGroup=logger" })
@Reference(target = "(&(diagGroup=logger)(diagGroup=slf4j)(diagGroup=conditions))“)

AGENDA
1
2
3
4
Getting lost
5 Starting over

WHERE ARE WE NOW?
> We now have prepared the ground for an extendible system
> The first product based on OSGi technology was released in December 2017
> We are currently derive the next products from our framework
> Thanks to OSGi deriving new products is now only a matter of configuration

HAS OSGI KEPT ITS PROMISE?
After working with technology for three years now the key benefits of OSGi are:
> It defines a clean deployment model and versioning scheme for modules
> It also defines a life-cycle for modules and components
> It enforces API first design
> It relies on Java and is therefore hardware independent
> It is fast enough to be used on embedded devices
> It supports dynamic updates and reconfiguration (although this is a sharp knife)
OSGi does not lead automatically better maintainable software – but OSGi helps you to make these issues visible.
It requires you to change some of your approaches when designing software. If you are willing to accept this,
OSGi is definitely a good choice and can keep its promise!

How OSGi drives cross-sector energy management - Jörn Tümmler (SMA Solar Technology)

How OSGi drives cross-sector energy management - Jörn Tümmler (SMA Solar Technology)

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a How OSGi drives cross-sector energy management - Jörn Tümmler (SMA Solar Technology)

Semelhante a How OSGi drives cross-sector energy management - Jörn Tümmler (SMA Solar Technology) (20)

Mais de mfrancis

Mais de mfrancis (20)

Último

Último (20)

How OSGi drives cross-sector energy management - Jörn Tümmler (SMA Solar Technology)