Content uploaded by Martin Sachenbacher
Author content
All content in this area was uploaded by Martin Sachenbacher on Feb 02, 2015
Content may be subject to copyright.
CeLiM: Centralized Runtime Monitoring of Lithium-Ion Battery Packs
Martin Sachenbacher1and Martin Blankenburg2and Martin Leucker2
1LION Smart GmbH, 85748 Garching, Germany
e-mail: martin.sachenbacher@lionsmart.com
2Universität Lübeck, 23562 Lübeck, Germany
e-mail: {martin.blankenburg, leucker}@isp.uni-luebeck.de
Abstract
The increasing proliferation of electrochemical
energy storage systems, for example in self-
sustaining buildings and emission-free vehicles,
is an important step towards a more sustainable
economy, but also creates new challenges to en-
sure safe and efficient operation of these sys-
tems. In this paper, we present CeLiM, a tool for
server-based monitoring and control of lithium-
ion battery packs in stationary and mobile applica-
tions. CeLiM allows to log large volumes of data
from local battery management systems (BMS),
and includes mechanisms for automated on-line
monitoring of batteries, using runtime verifica-
tion techniques from software engineering. We
demonstrate how CeLiM’s monitoring capability
can be coupled with existing model-based diag-
nosis frameworks, in order to automatically inter-
pret violated safety rules and identify likely root
causes of failures. We present preliminary results
using real data from a stationary energy storage
system in a sustainable residential home applica-
tion.
1 Introduction
The transition towards clean and renewable energies – in-
cluding the shift to wind and solar power, the development
of self-sustaining residential homes, and locally emission-
free electric mobility – critically depends on technologies to
temporally store electrical energy. Lithium-ion batteries [1]
are currently amongst the most advanced and efficient tech-
nologies for electrochemical energy storage. However, this
type of battery requires close monitoring of the cells’ volt-
age, current and temperature values in order to ensure safe
and efficient operation. A lithium-ion battery pack therefore
consists of several individual cells and an electronic bat-
tery management system (BMS) to control charging and dis-
charging, and protect the cells from operating outside safe
operating regions.
Methods for estimating the precise state of charge of cells,
or analyzing long-term aging effects [2], can be too complex
for the battery management system itself, due to its lim-
ited computational power and available data storage. At the
same time, the growing number of installed battery packs
creates an increasing need for automated, centralized mon-
itoring and control capabilities for power storage manufac-
turers, utility companies, and fleet managers, for example to
predict the remaining life-time, shift peak demand, or create
virtual power plants.
In this paper, we present CeLiM, a tool for centralized,
server-based data collection, run-time monitoring, and con-
trol of lithium-ion battery packs in both stationary and mo-
bile applications. CeLiM allows to gather large amounts of
data from different BMS simultaneously, and is designed to
shift much of the computational burden from the local BMS
to a more powerful, central computing facility (cloud). It in-
cludes mechanisms for automated on-line monitoring of bat-
teries, using runtime verification techniques. Runtime ver-
ification [3; 4]is a lightweight verification technique from
software engineering that aims to detect behaviors satisfying
or violating certain (safety) properties, which are specified
as a finite state machine or linear temporal logic expression.
This runtime monitoring capability can be coupled with ex-
isting hybrid model-based diagnosis frameworks, such as
Lydia-NG [5], in order to automatically interpret violated
properties and identify the likely root causes of such con-
tingencies. We demonstrate this coupling for a real-world
example using data and a detailed hybrid model of a station-
ary energy storage system in a sustainable residential home
application.
The remainder of the paper is organized as follows. In
the next section, we describe the problem background and
our example of a stationary energy storage system in the
Effizienzhaus Plus in Berlin, Germany. We then present
our solution and the architecture of the CeLiM monitoring
system, including a capability for runtime verification. We
describe how CeLiM’s runtime verification can be coupled
with existing diagnosis algorithms, in our case Lydia-NG
[5]. We present some preliminary results based on an exam-
ple scenario from the Effizienzhaus Plus, and finally outline
important directions for future work.
2 Related Work
Smart Grid [6]is a network of interconnected components
using the common power grid. Its main purpose is to sta-
bilize the power supply. Sensors and actuators are spread
across the network to efficiently and reliably ensure sys-
tem operation and monitor the system status. CeLiM on the
other hand focusses on the network’s endpoints, the energy
storage devices. While Smart Grid allows for monitoring
and optimization of the interconnected components, CeLiM
emphasizes on an efficient and intelligent network balancing
and energy management from the storage devices into the
grid and vice versa. One major disadvantage of Smart Grid
is the absence of data privacy protection regarding customer
data. Encrypted communication and a privacy protecting
user management is one of the core development goals of
the CeLiM system.
Smart Metering [7]utilizes measurement devices to de-
termine energy consumption over a period of time. This al-
lows to overview the supply and demand of energy through-
out the power grid. The collected data can be passed to a
third party for further analysis. Smart Metering also suffers
from the absence of customer data privacy protection, since
there is no guaranteed protection.
The SchwarmDirigent system [8]follows the same ba-
sic concepts as our CeLiM system. It holds comprehensive
monitoring features for energy storage devices and is also
able to combine multiple devices to virtual power plants.
Like our CeLiM system the SchwarmDirigent offers data
analysis and error prediction algorithms. It manages local
energy production with regards to energy prices on the stock
market, while CeLiM stabilizes and balances the power grid
by delivering excess energy to under-supplied locations.
Both systems feature the creation of energy storage clusters.
3 Background and Problem Description
Large-capacity lithium-ion batteries are nowadays mostly
viable in premium products like electric and hybrid vehi-
cles, but are increasingly used also for lower-intensity sta-
tionary energy storage, in particular as a second-life appli-
cation [9]. Typically, battery packs that are used in auto-
motive or stationary storage applications consist of several
hundreds or thousands of such individual cells, which are
connected in series and/or parallel to achieve the required
current and voltage output level. This complexity of battery
packs puts high demands on battery management systems
(BMS), which are embedded systems connected to the pack
to monitor the cells’ voltage, current and temperature val-
ues, and safely and effciently manage the charging and dis-
charging process of the cells. Sophisticated algorithms that
require more computational resources and rely on a history
of data, for example to more accurately estimate the state
of charge or the remaining life-time of cells, are often out-
side the scope of such BMS. At the same time, upcoming
applications that stretch across several power units, like the
formation of virtual power plants [10]in smart grids, or e-
mobility fleet management, require some form of global su-
pervision and control of the battery packs. Given a commu-
nication channel with sufficient reliability and bandwidth, it
is therefore desirable that sensor values are transmitted to
and logged by a central sever, which evaluates the data to
estimate the state of charge and state of health of the en-
ergy storage system. The results, for instance in the form
of adapted cell parameters or susceptible components, can
then be communicated back to the BMS of the battery pack,
or presented to a human operator.
3.1 Self-Sustaining Home Application
We briefly describe a prototypic application that uses
aged lithium-ion batteries for stationary storage of solar-
generated electrical power in a self-sustaining residential
home called Effizienzhaus Plus in Berlin, Germany (Fig. 1).
The project started 2011 and is funded by the German Fed-
eral Ministry of Transport, Building and Urban Develop-
ment. A stationary storage pack (see Fig. 2) was built that
consists of 70 battery modules, which have operated for 3-
4 years in battery-powered electric vehicles and were used
for about 50,000 miles of driving, together with a custom-
built BMS with internet connectivity. Each module in the
pack consists of 106 single lithium-ion standard 18650 cells,
adding up to 7.420 cells in total. The system has a nominal
voltage of 51.8V and a nominal capacity of 43,2 KWh. The
BMS senses in each module the temperature and two volt-
age values for two parallel strings (each consisting of 53
cells), thus in total 140 voltage values and 70 temperature
values are measured at a rate of 0.1–10 Hz. Since the start of
operation in June 2012, about 0.5GB of measurement data
has been recorded and the system will be in operation un-
til 2015 in order to collect data about the performance in
various operating and seasonal conditions.
Figure 1: View of the self-sustaining Effizienzhaus Plus res-
idential home in Berlin, Germany
Figure 2: Second-life lithium-ion battery pack for storing
renewable energy in the Effizienzhaus Plus
4 Centralized Runtime Monitoring for
Battery Packs
There are existing solutions for remote monitoring and an-
alytics of embedded systems, often referred to as machine-
to-machine communication, embedded cloud computing, or
internet-of-things [11]. One commercial instance is Ex-
osite [12], which offers such services through their cloud
implementation “One Platform” and collaborates with main
embedded systems manufacturers, including Microchip and
Texas Instruments. The system offers both a web interface
and APIs, allowing to send data packages to the cloud and
messages to devices and users. Moreover, the data can be vi-
sualized in a web portal using pre-defined widgets, and own
code snippets for processing the data can be executed on the
cloud’s server using the data-driven scripting language Lua.
However, we found such solutions insufficient to meet
the requirements of our lithium-ion monitoring application.
One reason is that sampling rates of up to 20 Hz and data
rates of up to 200 Kbit are necessary for single battery
packs, while Exosite, for example, is limited to 1 Hz data
resolution and does not support binary data protocols, caus-
ing inherently high overhead for the server communication.
Another reason is a focus on safety that motivates the devel-
opment of a more elaborate runtime monitoring and diagno-
sis capability, further described in section 5.
4.1 CeLiM System Architecture and Components
As part of a cooperation project with a battery manufacturer,
a client-server software framework for run-time monitor-
ing of electrical storage systems has been developed. The
system called CeLiM has the salient characteristics that it
allows simultaneous logging of high-volume data streams
with high temporal resolution (1.000 Hz precision), is de-
signed to be modular and independent of specific BMS, and
incorporates sophisticated analysis, verification, and event
generation options.
The overall system architecture is shown in Figure 3. The
client modules (left side of the diagram) are linked to the
local BMS and transform the data they receive into the for-
mat of the CeLiM network. These modules can either run
on the BMS itself, or on a separate piece of hardware that
is connected to the BMS (in our experiments, a Raspberry
Pi single-board computer). The data on the client side is
subjected to predefined filters and runtime verification rules.
The client modules automatically sign up with the server
part of CeLiM (right side of the diagram) and the time-
stamped data and notifications about possible violations of
verification rules are continuously transmitted to the server’s
high-performance logging database. Also the configuration
data for the registered BMS, the runtime verification rules,
and the user access privileges are managed by the server
modules. The data can be inspected and visualized by a
web application, and events can be defined to automatically
trigger alarms or issue commands to the clients.
In the following, we describe the modules and their tech-
nical realization in more detail:
•Network communication. Data transport services in
the network are done via Apache Thrift; initially de-
veloped by Facebook, it is an interface definition lan-
guage and binary communication protocol that can be
used with numerous languages. Due to compact byte-
stream-serialization, it requires little communication
overhead for the battery data.
•Entry points. The modules in the network do not com-
municate directly with each other, but each use a local
proxy module called entry point (EP), which forwards
the data to the correct destination address. The EPs are
automatically configured and updated in the network
using the distributed key-value store etcd [13]and au-
tomated service discovery. This decentralized solution
avoids single point of failures, and increases robustness
and modularity of the network.
•Configuration database (Config DB). New battery
packs to be monitored have to be registered in the
configuration database first, which holds configuration
data for the packs and runtime verification rules. It is
realized as a simple relational MySQL database.
•Logging database (Log DB). The time-stamped battery
data, together with information about runtime verifica-
tion checks, is logged using TokuMX, which is a vari-
ant of the distributed NoSQL-database system Mon-
goDB. TokuMX is specifically designed for high per-
formance on write-intensive workloads, and achieves
significant performance improvements over MongoDB
using Fractal Tree indexing. Load balancing and high
availability is achieved through data replication and
sharding, thus multiple logging database instances can
coexist throughout the CeLiM system.
•Controller, filter and middleware. Raw battery data
from the BMS is translated into CeLiM’s format by
the middleware, and potentially scaled down using de-
fined filters. The filter module then sends the data to the
logging database and to the runtime verification guard
for examination. Failed verification checks are also
communicated to the BMS controller, which can issue
commands to the other local modules (for example, to
drive the energy storage system towards a safe state, or
gather additional observations). A runtime verification
overseer monitors all attached battery packs globally
and reports failures like non-reachability of individual
BMS to the server controller and the power plant (PP)
controller, which manages the aggregation of individ-
ual battery packs into virtual power plants.
•Web application, web server and web client. The data
stored in the logging database can be queried and visu-
alized via a web interface. The web server is realized
using the Node.js platform, and the web client has been
implemented in AngularJS and uses the Highcharts JS
library for data visualization. Figure 4 shows an ex-
cerpt of the current web application prototype.
•Analyzer and runtime verification rules. The web in-
terface also allows to specify sets of rules for runtime
verification (RV) of the data, which are internally trans-
lated to scripts in the data-driven language Lua. The
analyzer module handles more complex analyses of the
data in the logging database, for example to identify
aging phenomena of cells.
Figure 4: Screenshot of CeLiM web interface for data in-
spection and visualization
Figure 3: Overview of CeLiM system architecture and modules
Furthermore, all communication from EP to EP features
techniques for public key encryption and service certifica-
tion to ensure a high level of security for both the data and
user communication. The CeLiM system has been imple-
mented using open source software tools and will be made
available under a suitable license.
5 Runtime Verification and Diagnosis
CeLiM includes a capability for life analysis of data using
runtime verification techniques. Runtime verification [3;
4]is a lightweight formal analysis approach that uses in-
formation from a running system to check if observed be-
haviors satisfy or violate certain specified (safety) proper-
ties. It establishes a middle ground between model checking
and testing and complements these techniques. Properties
are defined in the form of trace predicate formalisms like
finite state machines or linear temporal logic, from which
runtime monitors are generated to automatically instrument
the system and report violations of the properties. In Ce-
LiM, the properties are represented as rules in the data-
driven Lua scripting language. For instance, one may spec-
ify rules to check if cell voltage is outside its operating
region [vmin, vmax ], or if temperature is above a defined
threshold Tmax for more than a specified duration tlimit.
While runtime verification is an effective technique for
on-line detection of critical system failures, in general a
subsequent fault localization and identification step, termed
runtime reflection in [4], is necessary to find the root cause
of failures. This raises the interesting question whether and
how runtime verification can be coupled with model-based
diagnosis approaches. One straightforward idea is to use the
outcome of the runtime monitors, i.e. whether the respec-
tive property is violated or not at this point in the system, as
observations in an abstract diagnostic model that uses only
ok and faulty values to represent the signals and component
structure of the system [14]. However, a typical obstacle
is that the underlying formalism (such as linear temporal
logic) is defined for infinite traces, whereas in real systems
only finite behaviors can occur, leading to a 3-valued seman-
tics (’true’, ’false’, ’inconclusive’) for the outcome of run-
time monitors [15]. The successful verification of a property
by a runtime monitor (’true’) then in general does not imply
the absence of faults in the respective part of the system,
since other properties could still be violated. For diagnosis,
this means that only the outcome ’false’ can be faithfully
used as observation that there is a deviation from nominal
behavior in this part of the system.
5.1 Experimental Results
We describe our experiments to couple CeLiM’s runtime
verification with model-based diagnosis tools. All experi-
ments were performed on a Xeon 3.3 GHz Linux PC with
16 GB, running Ubuntu 12.04. In the Effizienzhaus Plus,
several contingencies have occurred since its start of oper-
ation, including deep discharge of battery cells (up to the
point of damage and necessary replacement) due to acciden-
tal mishandling of the system by residents. While this can
be caught through relatively simple rules and appropriate
alarms (which are now consequently in place), more sub-
tle incidents involved occasional disconnection of sensing
wires due to bad soldering joints in some of the battery mod-
ules. Since this sensing wire sits in-between two strings of
lithium-ion cells in the module, this failure actually causes
erroneous readings for both the two adjacent voltage sensors
in the module. Thus, if runtime verification rules are defined
to check if the voltage of each cell stays inside its nominal
operating region, two such rules are simultaneously violated
by this failure.
We built a hybrid model of the Effizienzhaus Plus battery
pack in the model-based diagnostic framework Lydia-NG
[5], which uses the numerical software SPICE for electri-
cal circuit simulation. The hybrid model has 211 health
variables and 1128 variables in total. Given the observed
voltage values, the sensing wire fault was successfully diag-
nosed by Lydia-NG, requiring 212 simulations and about 30
minutes runtime.
Similar to [14], we then built a more abstract model of the
battery pack that has the same number of variables but uses
only ok/faulty values instead of numerical values, and whose
component behavior models (resistors, voltage sources, and
wires) only state that ok values are propagated if the compo-
nent is correct. We then specified faulty value observations
for the respective signals where two runtime monitors re-
ported their property violated in this scenario. Lydia-NG in
this case yielded 6 single fault hypotheses (the sensing wire
and all components upstream of the triggered monitors) in
about 10 seconds runtime.
Finally, we used this set of fault hypotheses from the ab-
stract runtime verification model as a filter for the detailed
hybrid model, by excluding all the remaining components
from diagnostic search. Again the sensing wire fault was
successfully diagnosed by Lydia-NG, but requiring only 7
simulations and less than 1 minute runtime. This demon-
strates that qualitative information from runtime verification
can successfully be exploited to obtain significant speed-ups
by focusing diagnosis of a more detailed hybrid model.
6 Conclusion
In the application domain of lithium-based electrochemical
energy storage, close monitoring is required due to safety
and performance reasons. We presented our software tool
CeLiM, which has been designed for logging, analyzing,
and visualizing battery-related data, and includes a moni-
toring capability using runtime verification techniques. To
complement this detection mechanism by a diagnosis step,
we outlined and experimentally tested a possible coupling
with an existing model-based hybrid diagnosis framework.
This combination of runtime verification with an abstract
alarm propagation model and detailed numerical model al-
lowed effective diagnosis of incidents that might otherwise
be computationally infeasible or too subtle for a single
model. We are currently working on a general theory for
coupling runtime verification and diagnosis, and extending
our hybrid approach to cover also other situations in the ap-
plication, for instance insufficient cell balancing of the BMS
(leading, after some time, to unbalanced cells and a perfor-
mance degradation of the battery pack).
References
[1]Masaki Yoshio, Ralph J. Brodd, and Akiya Kozawa.
Lithium-Ion Batteries – Science and Technologies.
Springer, New York, 2009.
[2]M. Broussely et al. Main aging mechanisms in li-ion
batteries. Journal of Power Sources, 146(1–2), 2005.
[3]Moonjoo Kim, Mahesh Viswanathan, Insup Lee,
Hanene Ben-Abdellah, Sampath Kannan, and Oleg
Sokolsky. Formally specified monitoring of temporal
properties. In Proceedings of the European Confer-
ence on Real-Time Systems, 1999.
[4]Martin Leucker and Christian Schallhart. A brief ac-
count of runtime verification. Journal of Logic and
Algebraic Programming, 78(5), 2009.
[5]Alexander Feldman. The Lydia-NG diagnostic frame-
work. Technical Report LNG-2012-1, Delft University
of Technology, 2012.
[6]EurA Consult AG. SmartGrids intelligente Strom-
netze. http://www.smartgrids-net.de/,
2014. Accessed: 2014-08-02.
[7]RheinEnergie AG. Intelligente Zählertechnik und
neue Services. http://www.rheinenergie.
com/de/unternehmensportal/technik_
zukunft/smartmetering/index.php, 2014.
Accessed: 2014-08-02.
[8]Lichtblick. Schwarm-Intelligenz für Ihre An-
lagen. http://www.lichtblick.de/
schwarm-strom/schwarm-produkte/
schwarmoptimierung/, 2014. Accessed:
2014-08-02.
[9]Martin Sachenbacher, Tobias Mayer, Martin Leucker,
Martin Brand, and Andreas Jossen. Towards 2nd-life
application of lithium-ion batteries for stationary en-
ergy storage in photovoltaic systems. In Proceedings
of the International Conference on Solar Energy for
the MENA region (INCOSOL), Amman, Jordan, 2012.
[10]D. Pudjianto, C. Ramsay, and G. Strbac. Virtual power
plant and system integration of distributed energy re-
sources. IET Renewable Power Generation, 1, 2007.
[11]Jayavardhana Gubbi, Rajkumar Buyya, Slaven Maru-
sic, and Marimuthu Palaniswami. Internet of things
(IoT): A vision, architectural elements, and future di-
rections. Future Generation Computer Systems, 29,
2013.
[12]Exosite One Platform. http://www.exosite.
com. Accessed: 2014-06-10.
[13]Inc CoreOS. Etcd. https://github.com/
coreos/etcd. Accessed: 2014-08-02.
[14]Andreas Bauer, Martin Leucker, and Christian Schall-
hart. Model-based runtime analysis of distributed re-
active systems. In Proceedings of the Australian Soft-
ware Engineering Conference, 2006.
[15]Andreas Bauer, Martin Leucker, and Christian Schall-
hart. Monitoring of real-time properties. In Proceed-
ings of the 26th Conference on Foundations of Soft-
ware Technology and Theoretical Computer Science.
Springer, 2006.
