Distributed Data Validation for a Key-value Store in a Decentralized
Electric Vehicle Charging Network
Benedikt Kirpes
1 a
, Micha Roon
2
and Christopher Burgahn
2
1
University of Mannheim, Germany
2
Share&Charge Foundation, Zug, Switzerland
Keywords:
E-Mobility Systems, Smart Charging Infrastructure, Information Systems, Distributed Systems, Distributed
Data Storage, Distributed Hash Table, Key-value Store, Data Validation, Consensus Mechanism.
Abstract:
The mobility sector experiences a fundamental shift to more connected, autonomous, shared and electric
means of transportation. For an electric mobility system to function, an efficient and reliable electric vehicle
charging network is required. The Open Charging Network, which is built and curated by the Share&Charge
Foundation is a digital, open and decentralized infrastructure for operating and connecting assets of the e-
mobility ecosystem like charge points and electric vehicles. In such a network validity and consistency of data
are crucial. Since the underlying information system is designed based on distributed ledger technologies and
distributed hash tables, also the validation of data for the respective key-value store should be implemented and
executed in a distributed manner. In this paper, we contribute to the body of research by analyzing the current
situation in distributed systems and presenting the design and development of a mechanism for a distributed
data validation. We provide an outlook into the future implementation within the Open Charging Network,
where the solution will be demonstrated in a suitable context. Further it will be evaluated regarding the primary
requirement of data validity and secondary requirements such as availability, reliability and scalability.
1 MOTIVATION
Still many barriers for the widespread adoption of
Electric Vehicles (EVs) exist, one of them being
the insufficient charging infrastructure (Egbue and
Long, 2012). If customer incentives can be set ade-
quately and adoption-hindering barriers are removed,
EV sales may increase dramatically, as the example of
Norway has shown (Mersky et al., 2016). For a mobil-
ity sector that increasingly relies on EVs, the available
charging infrastructure constitutes a critical system
that must be built, operated and maintained efficiently.
This is not only the case for the utilized hardware
components, every charging infrastructure also con-
sists of multiple software components. Provision of a
software infrastructure for a smart EV charging net-
work with highest availability and security standards
is still a big challenge. The information systems re-
search community draws similar conclusions, consid-
ering e-mobility as sub-discipline of energy informat-
ics and as a major building block for a sustainable and
smart energy future (Kossahl et al., 2012). The devel-
a
https://orcid.org/0000-0002-6583-444X
opment of the necessary infrastructure for the Inter-
net has shown that Information and Communication
Technologies (ICT) developed, operated and main-
tained in a distributed and open source manner can
be considered as the appropriate way for engineering
system-critical infrastructures. Following this vision,
the Share&Charge
1
Foundation is building and cu-
rating the Open Charging Network (OCN) based on
distributed technologies. For use cases like charge
point (CP) availability status, reservation, smart rout-
ing, roaming and smart charging, such a system re-
quires a shared state of the relevant data, e.g. from
smart meters, CPs and EVs. Validating the correct-
ness of data in such a network is very challenging
and currently done either on the application layer or
based on centralized and non-transparent ruling. Cur-
rent technologies and systems moreover fail to fully
achieve this common shared state based on distributed
validation.
Therefore, in this paper we tackle the following
research question: How can the data stored in a dis-
tributed key-value store be validated in a distributed
1
https://shareandcharge.com/
356
Kirpes, B., Roon, M. and Burgahn, C.
Distributed Data Validation for a Key-value Store in a Decentralized Electric Vehicle Charging Network.
DOI: 10.5220/0008363703560363
In Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2019), pages 356-363
ISBN: 978-989-758-382-7
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
manner in order to establish a common shared state
in a decentralized network for EV charging?
To answer this research question, we apply the
structured design science research (DSR) methodol-
ogy as proposed by (Peffers et al., 2008). The first
phases are carried out and presented in this paper,
while demonstration, evaluation and further iterations
are part of future research work. The remainder of
this paper is structured according to the DSR process
as follows. After providing an introduction to our re-
search in the context of EV charging networks (sec-
tion 1), we further elaborate on the identified problem
and the specific motivation in section 2.1. We define
the objectives and requirements for a solution artifact
(section 2.2) and give an overview about related work
and the state-of-the-art (section 2.3). In section 3 we
propose the design for the artifact, give some insights
into its development and present an example in the
context of the OCN. We conclude the paper in section
4 by discussing our approach, practical implications
and its limitations. Further, we provide an outlook
into future research activities in this context.
2 DATA VALIDATION IN
DISTRIBUTED SYSTEMS
Although the terms distributed and decentralized are
often used synonymously, we distinguish them ac-
cording to the degree of decentralization into three
levels: centralized, decentralized and distributed (Fig-
ure 1).
Figure 1: Centralized, Decentralized and Distributed Sys-
tems (Raval, 2016).
This classification and terminology apply to tech-
nologies, networks and systems alike. Nevertheless,
not only distributed, but also decentralized or even
centralized systems can be built on top of a distributed
technology. Many distributed technologies are avail-
able for building a decentralized network, such as dis-
tributed ledger technologies (DLT) like blockchains
and directed acyclic graphs (DAG), or distributed
hash tables (DHT).
In a distributed or decentralized ICT system, also
storage and validation of the respective data should
be designed in such a way. To the best of our knowl-
edge, such a distributed validation mechanism has not
been proposed or implemented yet. It is not a straight-
forward task, as data storage itself poses many chal-
lenges, e.g. consistency, validity, availability, reliabil-
ity, scalability, efficiency, integrity, resilience, fault-
tolerance, persistence, performance, trust of data and
databases; ACID properties (atomicity, consistency,
isolation, and durability) for transactions (Decandia
et al., 2007).
The implementation and utilization of blockchain
technologies to store data in a distributed system only
makes sense, if there is a need for trusted public time
stamps or a need to prove that the reader always re-
ceives the latest state and that there is only one state
(Wuest and Gervais, 2018). This is a rather rare case.
For all other systems a DHT is a better way (regard-
ing efficiency, performance, scalability) to store data
in a distributed way. In a DHT the data gets hashed
and stored within a distributed key-value store (KVS),
e.g. implemented in Amazon’s Dynamo (Decandia
et al., 2007) or Apache Cassandra (Lakshman and
Malik, 2010). The four initial DHT protocols and al-
gorithms are Chord, CAN, Tapestry, and Pastry. In a
DHT, each node in the network holds a portion of the
data, unlike for many blockchain technologies where
all nodes store the same data. Additionally, all data
are stored multiple times for reliability purposes. If
one node fails, the data stored in it can be retrieved
from one of its peers and the network can recover. The
participating nodes coordinate themselves in order to
balance and store the data in the distributed network
without any central instance.
2.1 Challenges of Distributed Data
Validation
In the Open Charging Network by the Share&Charge
Foundation, both distributed technologies, blockchain
and DHT are utilized, serving different purposes. The
blockchain is used as a reference for trusted time
stamps. The distributed KVS of the hash table is in-
tended to hold the current state of the system includ-
ing the state of each CP (e.g. free, occupied) and EV
(e.g. plugged-in, charging), the communication infor-
mation and the ownership details of the assets. Us-
ing the integrated blockchain technology for storing
this data would have multiple downsides: it would be
Distributed Data Validation for a Key-value Store in a Decentralized Electric Vehicle Charging Network
357
inefficient (performance, scalability), overly expen-
sive and modifying the data impossible due to the im-
mutability by design of blockchain technologies. Fur-
ther, certain personal data would become public, lead-
ing to General Data Protection Regulation (GDPR) is-
sues. Hence, the OCN network relies on a distributed
KVS which allows for parallel data operations and
does not require a network-wide consensus on every
transaction. In order to build service applications on
top of the system’s data the content of the distributed
KVS needs to be trusted, also when storing informa-
tion off-chain.
Major challenges for a distributed KVS are vali-
dation and verification of the data, and consequently
trust in the data, devices and actors. For data verifica-
tion, it has to be checked and ensured that the data en-
tered into the system is actually the same as the origi-
nal data, accurate and as intended, e.g. by double en-
try check. By data validation, the data is checked to
be reasonable for the system’s requirements accord-
ing to certain rules, e.g. by data format, range or
structure check.
In order to make sure that the data stored on each
node is valid, the owner of the data element has to
sign it. When the reader of the data is an IoT device,
it might not have the means to perform validation and
might rely on a trusted source to provide it with data.
The verification of the signature is a simple process
which can be performed by any client, even an IoT
device. Besides the verification of the signature, more
complex validation and verification of data might be
required, which can not be performed by every IoT
device, e.g. validations that include complex calcu-
lations or access to remote data sources. These kind
of validations are very common in database systems
where data integrity and other checks are required. In
a DHT, data validation rules are typically issued, en-
forced and maintained by a central authority and not
by the distributed network itself.
2.2 Artifact Requirements
In this paper we propose a structured methodology for
distributed data validation in a DHT. This would en-
able decentralized applications (dApps) to store data
with complex validation rules in a DHT (as opposed
to a blockchain smart contract). Application of such
a concept would include several phases. Our result-
ing artifact will provide means to address these phases
and fulfill the following functional requirements:
1. Define validation rules
The artifact must provide a structured methodol-
ogy to describe the data structure and define val-
idation rules. This should be implemented based
on a (standardized) general purpose or domain-
specific language with suitable syntax and nota-
tion.
2. Publish validation rules
The artifact must provide a way to enable the cre-
ator of the data structure to create and publish the
defined validation rules to the network.
3. Agree on validation rules
The artifact must provide a mechanism to achieve
a distributed agreement or consensus within the
network about the published validation rules.
4. Enforce validation rules
The artifact must provide means to enforce the
validation rules and enable all nodes to read and
interpret data considering the validation rules.
The generic objectives for data storage as intro-
duced in the beginning of section 2 are extensive and
challenging. In our research and for the artifact eval-
uation, we focus on a relevant and specific sub-set
for distributed data validation. This includes the fol-
lowing non-functional requirements: data validity as
primary objective; consistency and availability of the
data, plus reliability and scalability of the solution
as secondary requirements. Validity of the data en-
sures trust in the network. Invalid data of any type
may harm the whole system. Consistency of data
refers to application consistency, transaction consis-
tency and point-in-time consistency (for recovery pur-
pose). Availability and reliability of the data are crit-
ical issues for the smooth operation of the charging
network. Scalability of the solution is important in
order to support a large amount of IoT devices (EVs,
CPs, etc).
2.3 State-of-the-Art in Distributed Data
Validation
Data validation starts with the definition of the data
structure and the specification of a schema. Each
data element must comply with the respective schema
definition of its namespace. A schema language
can be modelled on RelaxNG (ISO/IEC 19757-2,
2003) which has many implementations. LIVR
2
is a
project more focused on validation rules. The Valiktor
project
3
proposes methods to validate Kotlin objects
which could be used to describe the data. Another
idea is the use of a content-hash key by a front-end
to verify integrity of data received from the network
(Sit, 2008). CHAINIAC is a promising approach for
publishing of validation rules (Nikitin et al., 2017).
2
https://github.com/koorchik/LIVR
3
https://github.com/valiktor/valiktor
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
358
The Holochain
4
DHT embeds the validation rules as
a condition for the propagation of data.
Most of the existing approaches focus only on
static validation or centralized definition and deploy-
ment of validation rules. We will take these concepts
one step further and contribute to the body of research
by making the validation i) more dynamic and ii) de-
pendent on both the user who submits the data and the
content of the data (which Valiktor already is able to
do). For example, when an IoT device (in our case an
EV or CP) connects to an OCN client
5
in the network,
this information is stored in the global address book
which is stored in the DHT. The address book entry
must be signed by both the user and a message bro-
ker. This means that there will be two signature fields
(e.g. ocn cli sig and user sig) which must contain a
signed version of the hash field. When the informa-
tion is stored by a DHT node it has to find the correct
validation rules and only accept data which yields a
positive valid result.
3 DESIGN AND DEVELOPMENT
OF THE DATA VALIDATION
MECHANISM
The artifact to be designed and developed is a concept
and mechanism for distributed data validation, appli-
cable for the Open Charging Network and other de-
centralized networks based on DHTs with a key-value
store. Figure 2 visualizes the requirements and the ar-
tifact design of our distributed data validation mech-
anism. The four major components (solution space)
cover the four phases of the distributed data valida-
tion process (problem space) as stated in section 2.2
to meet the identified functional requirements. Design
and implementation of the these artifact components
are described in the following section.
Requirements (Problem Space)
Artifact Design (Solution Space)
Define
Validation
Rules
Publish
Validation
Rules
Agree on
Validation
Rules
Execute
Validation
Rules
Rule Definition
Language
Rule Execution
Engine
Consensus
Mechanism
Data Structure
Definition
Define
Validation
Rules
Publish
Validation
Rules
Agree on
Validation
Rules
Execute
Validation
Rules
Rule Definition
Language
Rule Execution
Engine
Consensus
Mechanism
Data Structure
Definition
Figure 2: Distributed data validation mechanism.
4
https://github.com/holochain/
5
https://bitbucket.org/shareandcharge/ocn-client
3.1 Data Structure Definition and Rule
Definition Language
Prior to defining validation rules, certain assumptions
have to be made regarding structure and encoding of
the data. Since a DHT is a store of bytes, an encod-
ing standard has to be specified and defined to allow
any participant to read and understand the data. A
concise language is required for the data structure de-
scription, for which inspiration can be drawn from
many existing syntax specifications. To the best of
our knowledge, no suitable language to describe both,
data structure and validation logic, exists. Therefore,
we create a specific XML-based grammar in order
to provide a complete and specialized language. It
will be a subset of an existing Data Definition Lan-
guage (DDL), similar to those provided by relational
database management systems. In its first iteration,
the definition of the rules will be done by linking the
source code of the rule to the structure described in
the DDL. Separating structure and logic will simplify
the design.
Namespaces and Domains. A DHT does not have
concepts with tables or collections, it only uses keys
for referencing data. The data must be attached to a
description and this description should not be attached
to every key-value pair. A suitable solution is the def-
inition of a namespace schema akin to Java’s package
naming system. The top-level domain is controlled
by the organization, in this case the Share&Charge
foundation and is always .dht, while the actual do-
main name is chosen by the user and can be any string
conforming to the java package naming conventions.
Each domain must be registered with the distributed
KVS naming service which records the public keys
associated with a specific domain. All namespaces
belonging to a domain (namely the sub-domains) are
controlled by the top-level public key. In order to
guarantee data retention in a distributed KVS, data
must be stored multiple times. As not all servers are
controlled centrally, there is no way to ensure that a
server will stay up and running or that data will not
be deleted. The replication ratio will therefore be de-
cided on a namespace level. Some data being more
important to the network than others, not all data will
be replicated with the same ratio.
Example of a Data Structure Definition and One
Instance. In order to illustrate a potential syntax for
the data structure definition, we provide a simplified
example for charge point data (see above and Ap-
pendix). It has been created in eXtensible Markup
Language (XML) and the respective XML Schema
Distributed Data Validation for a Key-value Store in a Decentralized Electric Vehicle Charging Network
359
1 <? xml v e r s i on = 1 . 0 e n c o d i n g =UTF8 ?>
2 <x s : s c h e m a x m l n s : x s = h t t p : / /www. w3 . org / 2 0 0 1 / XMLSchema>
3 < x s : e l e m e n t name=” D a t a D e f i n i t i o n ”>
4 <x s : co m p l ex T y p e>
5 < x s : s e q u e n c e>
6 < x s : e l e m e n t name= n ames pace t y p e = NameSpace ” />
7 <x s : a n y />
8 < x s : e l e m e n t name=” v a l i d a t i o n ” t y p e =” V a l i d a t i o n R u l e ” m inOc cur s =
0 maxOccurs = unbo unded ” />
9 < x s : e l e m e n t name=” s i g n a t u r e ” t y p e =” x s : s t r i n g ” />
10 < / x s : s e q u e n c e>
11 < / x s : co m p l ex T y p e>
12 < / x s : e l e m e n t>
13
14 <x s : s i m p l e T y p e name= NameSpace >
15 < x s : r e s t r i c t i o n b a s e =” x s : s t r i n g >
16 < x s : p a t t e r n v a l u e =” ( ? : ˆ \w+ |\w+ \ . \w+) +$ ” />
17 < / x s : r e s t r i c t i o n>
18 < / x s : s i m p l e T y p e>
19
20 <x s : co m p l ex T y p e name=” D a t a S t r u c t u r e ”>
21 < / x s : co m p l ex T y p e>
22
23 <x s : co m p l ex T y p e name=” V a l i d a t i o n R u l e ”>
24 < x s : s e q u e n c e>
25 < x s : e l e m e n t name=” s o u r c e U r l ” t y p e = x s : s t r i n g ” />
26 < x s : e l e m e n t name= s o u r c e H a s h t y p e = x s : s t r i n g ” />
27 < x s : e l e m e n t name=” b i n a r y U r l ” t y p e = x s : s t r i n g ” />
28 < x s : e l e m e n t name=” bi n a r y H a s h t y p e = x s : s t r i n g ” />
29 < / x s : s e q u e n c e>
30 < / x s : co m p l ex T y p e>
31 < / x s : s c h e m a>
Listing 1: Data structure definition (xsd file format).
Definition (XSD). The final implementation will use
a different format to be more concise.
3.2 Rule Execution Engine
For the purpose of simplicity, Java is used to create the
validation rules. The advantages of Java are its wide-
spread usage with a large amount of capable develop-
ers. It can run on almost any hardware and Java byte-
code can be transpiled into Webassembly
6
for native
performance on many platforms. Further, many lan-
guages compile to Java Virtual Machine (JVM) byte-
code and can be used as drop-in replacements, e.g.
Jython as a Java implementation for Python. Writing
and publishing the validation rules is enabled by an
API.
Using the JVM to create validation rules allows
usage of the associated execution environment for the
actual execution of the validations. Further, it elim-
inates the need to create a dedicated rules definition
language and replaces it with a much simpler API
definition. By using an interface-based programming
6
https://webassembly.org/
style (Steimann and Mayer, 2005) we can ensure that
provided bytecode can be executed correctly. The
process of retrieving the validation rules would be as
follows:
1. connect to a blockchain node
2. read the URL for the validation rules’ binary re-
quired by the namespace
3. fetch the validation rules’ binary from the URL
4. verify the binary’s hash against the hash stored in
the blockchain
5. execute the rules for each data element
3.3 Consensus Mechanism
As mentioned earlier, validation rules have the re-
quirement of completeness. Network participants
want to have certainty that they always get the lat-
est version of the validation rule and that a mali-
cious node can not serve outdated rules. Therefore
we propose to use a smart contract on the Energy
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
360
Web Chain
7
to reach consensus on validation rules.
The consensus mechanism in a distributed system al-
lows to create rules which everyone agrees on and
makes it impossible to change the rules without ev-
eryone agreeing, or at the very least being informed
about a change. The consensus mechanism will be
implemented as an Ethereum smart contract which
will contain the rules (or an immutable link to them)
and allow to reach consensus. The method to proof
that the source code associated with a particular vali-
dation rule is correct is the following:
1. push the source code for the validation rule to a
git repository
2. push the binary bundle to the same repository
3. publish a transaction to the rules smart contract
with:
the namespace for which the rule applies to (the
sender must be the owner of the namespace)
the URL to the git repository (must be publicly
reachable)
the commit hash of the published version of the
code
the URL to the binary bundle
the hash of the binary bundle
The validation rules are only accepted, once a pre-
defined number of DHT nodes has verified that the
published source code yields the published binary.
The verifying nodes are selected by using Scalable
Bias-Resistant Distributed Randomness (Syta et al.,
2017) to ensure that a malicious actor can not validate
its own code.
The validation mechanism is based on a standard-
ized build mechanism which is easy to implement in
most JVM languages. In order to make the build pro-
cess tamper-proof, the Maven or Gradle scripts for
building rules will not be provided by the validation
rule developer but by the DHT node verifying the
code. It is the developer’s responsibility to make sure
the build process works. Maven and Gradle scripts for
Java, Kotlin and Scala will be provided in the first ver-
sion. The proposed mechanism with its four compo-
nents is in development and as a next step will be fully
implemented, demonstrated and evaluated within the
Share&Charge solution.
3.4 Demonstration Example in the
Open Charging Network
In the OCN developed by Share&Charge the KVS
will be used to record the state of the available
7
https://www.energyweb.org/technology/energy-web-
chain/
assets. A concrete example for that is the state
of the charge points. According to the specifica-
tion of the widely used peer-to-peer Open Charge
Point Interface (OCPI) (NKL, 2019), a charge point
can be in one of 9 possible states: AVAILABLE,
BLOCKED, CHARGING, INOPERATIVE, OUTO-
FORDER, PLANNED, REMOVED, RESERVED,
UNKNOWN (see Appendix).
When an EV driver is looking for a charge point
to recharge the battery the AVAILABLE status of the
charge point is a necessity. This information about
the state of the charge point is with the Charge Point
Operator (CPO). The driver typically gets informa-
tion from an e-mobility service provider, which ag-
gregates charge points from many CPOs. Thus, the
easiest way to ensure that the driver gets accurate in-
formation about charge points from any CPO in the
network is to store it in a shared data-store. Creating
a dedicated KVS for charge point status data would
save the e-mobility service providers many queries for
the state of the charge points.
Validation of Charge Point States. It is impor-
tant to ensure that the provided information originates
from the correct source and valid. Else the system
could be harmed, e.g. if a malicious CPO would be
able to set the state of all competitor charge points
to BLOCKED in order to hurt their business. The
namespace com.shareandcharge.ocpi.location (which
contains all the charge points) must be owned by the
independent Share&Charge Foundation in order to al-
low all CPOs to contribute and provide a single source
for location data. This means that certain validation
rules would need to be enforced:
Each location defines its owner
The owner must sign each entry (creation and up-
date) with its private key
The ID of each location must be unique through-
out the entire network
This ensures that once a CPO has published a lo-
cation (charge point) it is the only one being able to
update its state.
4 CONCLUSION AND OUTLOOK
A resilient EV charging infrastructure based on dis-
tributed technologies requires a DHT to share infor-
mation about assets and their state. A trustworthy
distributed data validation is a key element for such
a system being able to rely on the data input that is
provided by the actors of it. Today, static and central-
ized data validation in a DHT already exist. However,
Distributed Data Validation for a Key-value Store in a Decentralized Electric Vehicle Charging Network
361
as an open EV charging network requires highly dy-
namic data input like real-time availability of CPs, a
more dynamic and distributed data validation mech-
anism is required. Linked to the functional require-
ments of a distributed data validation process, we
outlined the design and development of four artifact
components: Data Structure Definition, Rule Defini-
tion Language, Rule Execution Engine and Consen-
sus Mechanisms.
Limitations, Future Research and Practical Impli-
cations. One of the major challenges in building a
decentralized charging network including a DHT is to
gain the necessary adoption. The business decisions
that would drive such an adoption are linked to an
agreement on the rules that a data validation process
should follow. Defining the right rules that all users
in a certain application market can agree upon can be
a very complex task to do, which was not discussed
further in this paper. However, the research conducted
can be used for providing the technical means to im-
plement such rules. The Share&Charge Foundation is
focused on facilitating this decision making process
in the EV charging industry and will conduct further
research into the outcomes of this process. For future
research, we plan to extend on this research activity
by demonstrating the usefulness of the implemented
mechanisms in an appropriate system context. The
concept will be applied for the Open Charging Net-
work. The developed and implemented artifact will
be evaluated against the identified requirements from
this paper.
ACKNOWLEDGEMENTS
We thank Dietrich S
¨
ummermann, Adam Staveley and
all other employees of the Share&Charge Foundation
for their valuable input and discussions. Part of this
research was funded by the European Union’s Hori-
zon 2020 research and innovation programme under
grant agreement No. 713864.
REFERENCES
Decandia, G., Hastorun, D., Jampani, M., Kakulapati,
G., Lakshman, A., Pilchin, A., Sivasubramanian, S.,
Vosshall, P., and Vogels, W. (2007). Dynamo: Ama-
zon’s Highly Available Key-value Store. In SOSP’07.
Egbue, O. and Long, S. (2012). Barriers to widespread
adoption of electric vehicles: An analysis of con-
sumer attitudes and perceptions. Energy Policy,
48(2012):717–729.
ISO/IEC 19757-2 (2003). Document Schema Definition
Language (DSDL) Part 2: Regular-grammar-based
validation (RELAX NG).
Kossahl, J., Busse, S., and Kolbe, L. (2012). The Evolve-
ment of Energy Informatics in the Information Sys-
tems Community - A Literature Analysis and Re-
search Agenda. In 20th ECIS Proceedings.
Lakshman, A. and Malik, P. (2010). Cassandra. ACM
SIGOPS Operating Systems Review, 44(2):35.
Mersky, A. C., Sprei, F., Samaras, C., and Qian, Z. S.
(2016). Effectiveness of incentives on electric vehicle
adoption in Norway. Transportation Research Part D:
Transport and Environment, 46:56–68.
Nikitin, K., Kokoris-Kogias, E., Jovanovic, P., Gasser,
L., Gailly, N., Khoffi, I., Cappos, J., and Ford,
B. (2017). CHAINIAC: Proactive Software-Update
Transparency via Collectively Signed Skipchains and
Verified Builds. In 26th USENIX Security Symposium,
pages 1271–1287.
NKL (2019). Open Charge Point Interface (OCPI) 2.2.
Technical report, Netherlands Knowledge Platform
for Public Charging Infrastructure (NKL).
Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-
terjee, S. (2008). A Design Science Research Method-
ology for Information Systems Research. Journal of
Management Information Systems, 24(3):45–77.
Raval, S. (2016). Decentralized Applications - Harness-
ing Bitcoin’s Blockchain Technology. O’Reilly Media,
Inc.
Sit, E. (2008). Storing and Managing Data in a Distributed
Hash Table. PhD thesis, Massachusetts Institute of
Technology.
Steimann, F. and Mayer, P. (2005). Patterns of interface-
based programming. Journal of Object Technology,
4(5):75–94.
Syta, E., Jovanovic, P., Kogias, E. K., Gailly, N., Gasser, L.,
Khoffi, I., Fischer, M. J., and Ford, B. (2017). Scal-
able Bias-Resistant Distributed Randomness. In Pro-
ceedings - IEEE Symposium on Security and Privacy,
pages 444–460.
Wuest, K. and Gervais, A. (2018). Do you need a
blockchain? In Crypto Valley Conference on
Blockchain Technology, CVCBT 2018, pages 45–54.
KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems
362
APPENDIX
1 < s c : D a t a D e f i n i t i o n x m l n s : s c = f i l e : / / d a t a d e f . x s d xmlns=” h t t p : / /www. w3 . o r g / 2 0 0 1 / XMLSchema>
2 <s c : n a m e s p a c e>name</ s c : n a m e s p a c e>
3 <s c : s t r u c t u r e x m l n s : d s = ” h t t p : / / www . w3 . o r g / 2 0 0 1 / XMLSchema>
4 <d s : e l e m e n t name=” L o c a t i o n ”>
5 <ds:c o m p l e x T y p e>
6 <s e q u e n c e>
7 <d s : e l e m e n t name=” i d ” t y p e = ” d s : s t r i n g ” />
8 <d s : e l e m e n t name= name t y p e = ” d s : s t r i n g ” />
9 <d s : e l e m e n t name= s t a t e ”>
10 <ds:c o m p l e x T y p e>
11 <c h o i c e>
12 <d s : e l e m e n t name=AVAILABLE” />
13 <d s : e l e m e n t name=”BLOCKED” />
14 <d s : e l e m e n t name=CHARGING” />
15 <d s : e l e m e n t name=INOPERATIVE” />
16 <d s : e l e m e n t name=”OUTOFORDER” />
17 <d s : e l e m e n t name=PLANNED” />
18 <d s : e l e m e n t name=”REMOVED” />
19 <d s : e l e m e n t name=RESERVED” />
20 <d s : e l e m e n t name=”UNKNOWN” />
21 </ c h o i c e>
22 </ d s : c o m p l e x T y p e>
23 </ d s : e l e m e n t>
24 <d s : e l e m e n t name= gpsc o o r d i n a t e s ”>
25 <d s : s i m p l e T y p e>
26 <d s : a n n o t a t i o n>
27 <d s : d o c u m e n t a t i o n>
28 V a l i d GPS c o o r d i n a t e s i n t h e for m o f l a t / l o n g
29 </ d s : d o c u m e n t a t i o n>
30 </ d s : a n n o t a t i o n>
31 < d s : r e s t r i c t i o n b a s e = ” d s : s t r i n g >
32 <d s : p a t t e r n v a l u e =” ˆ( [ + ] ? ) ( [ \ d ]{ 1 , 2 } ) ( ( ( \ . ) ( \ d + ) ( , ) ) ) ( \ s ) ( ( [ + ] ? ) ( [ \ d ]{ 1 , 3 } ) ( ( \ . ) ( \
d + ) ) ? ) $ ” />
33 </ d s : r e s t r i c t i o n>
34 </ d s : s i m p l e T y p e>
35 </ d s : e l e m e n t>
36 <d s : e l e m e n t name= owner >
37 <d s : s i m p l e T y p e>
38 <d s : a n n o t a t i o n>
39 <d s : d o c u m e n t a t i o n>
40 CPO who owns t h e c h a r g i n g l o c a t i o n . Must be a v a l i d Ether e um a d d r e s s .
41 </ d s : d o c u m e n t a t i o n>
42 </ d s : a n n o t a t i o n>
43 < d s : r e s t r i c t i o n b a s e = ” d s : s t r i n g >
44 <d s : p a t t e r n v a l u e = ˆ 0 x [ afAF0 9]{40}$ ” />
45 </ d s : r e s t r i c t i o n>
46 </ d s : s i m p l e T y p e>
47 </ d s : e l e m e n t>
48 </ s e q u e n c e>
49 </ d s : c o m p l e x T y p e>
50 </ d s : e l e m e n t>
51 </ s c : s t r u c t u r e>
52 <s c : v a l i d a t i o n>
53 <s c : s o u r c e U r l> h t t p s : / / g i t h u b . com / p a t h t o s o u r c e b u n d l e . z i p</ s c : s o u r c e U r l>
54 <s c : s o u r c e H a s h>b1 2 c 5 a 4 1 a c005664dc 9 4 c 0 6 5 8 148eb99</ s c : s o u r c e H a s h>
55 <s c : b i n a r y U r l> h t t p s : / / g i t h u b . com / path tob i n a r y b u n d l e . z i p</ s c : b i n a r y U r l>
56 <s c : b i n a r y H a s h>8 e c 1 0 e91a9731c3 3 7 5 8 2 c 7 9 a69506132</ s c : b i n a r y H a s h>
57 </ s c : v a l i d a t i o n>
58 <s c : s i g n a t u r e>4 d 63 4 8 8 6 5 f 1 71 3 f 3 16 c c a b 4 f 9 41 b d b f 0 f 9 3 b c 6 6 b2 5 f 3 9 e 1 f 6 b 5 e 2 f8 5 1 0 c 2 c d 51 4 d 6 34 8 865
f 1 7 1 3 f 3 1 6 c c a b4 f 9 4 1 b d b f 0 f 9 3 b c 6 6 b 2 5 f3 9 e 1 f 6 b 5 e 2 f 8 5 1 0 c 2 c d 5 1A 0</ s c : s i g n a t u r e>
59 </ s c : D a t a D e f i n i t i o n>
Data definition example (xml file format)
Distributed Data Validation for a Key-value Store in a Decentralized Electric Vehicle Charging Network
363