Distributed Data Validation for a Key-value Store in a Decentralized

Electric Vehicle Charging Network

Benedikt Kirpes

1 a

, Micha Roon

and Christopher Burgahn

University of Mannheim, Germany

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 efﬁcient 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 insufﬁcient 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 efﬁciently.

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-

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

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

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

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 ﬁrst

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 identiﬁed problem

and the speciﬁc motivation in section 2.1. We deﬁne

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 classiﬁcation 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, efﬁciency, 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 efﬁciency, 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

inefﬁcient (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 veriﬁcation of the data, and consequently

trust in the data, devices and actors. For data veriﬁca-

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 veriﬁcation of the signature is a simple process

which can be performed by any client, even an IoT

device. Besides the veriﬁcation of the signature, more

complex validation and veriﬁcation 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 fulﬁll the following functional requirements:

1. Deﬁne validation rules

The artifact must provide a structured methodol-

ogy to describe the data structure and deﬁne val-

idation rules. This should be implemented based

on a (standardized) general purpose or domain-

speciﬁc 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

deﬁned 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 speciﬁc 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 deﬁnition of the data

structure and the speciﬁcation of a schema. Each

data element must comply with the respective schema

deﬁnition of its namespace. A schema language

can be modelled on RelaxNG (ISO/IEC 19757-2,

2003) which has many implementations. LIVR

is a

project more focused on validation rules. The Valiktor

project

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).

https://github.com/koorchik/LIVR

https://github.com/valiktor/valiktor

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

358

The Holochain

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 deﬁnition 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

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 ﬁelds

(e.g. ocn cli sig and user sig) which must contain a

signed version of the hash ﬁeld. When the informa-

tion is stored by a DHT node it has to ﬁnd 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 identiﬁed 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.

https://github.com/holochain/

https://bitbucket.org/shareandcharge/ocn-client

3.1 Data Structure Deﬁnition and Rule

Deﬁnition Language

Prior to deﬁning 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 speciﬁed and deﬁned 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 speciﬁcations. To the best of

our knowledge, no suitable language to describe both,

data structure and validation logic, exists. Therefore,

we create a speciﬁc XML-based grammar in order

to provide a complete and specialized language. It

will be a subset of an existing Data Deﬁnition Lan-

guage (DDL), similar to those provided by relational

database management systems. In its ﬁrst iteration,

the deﬁnition 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 speciﬁc 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 Deﬁnition and One

Instance. In order to illustrate a potential syntax for

the data structure deﬁnition, we provide a simpliﬁed

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 =”UTF−8” ?>

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>

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>

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>

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 deﬁnition (xsd ﬁle format).

Deﬁnition (XSD). The ﬁnal 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

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 deﬁnition

language and replaces it with a much simpler API

deﬁnition. By using an interface-based programming

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

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-

deﬁned number of DHT nodes has veriﬁed 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 ﬁrst 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

https://www.energyweb.org/technology/energy-web-

chain/

assets. A concrete example for that is the state

of the charge points. According to the speciﬁca-

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 deﬁnes 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 Deﬁnition, Rule Deﬁni-

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. Deﬁning 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 identiﬁed 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 Deﬁnition

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., Khofﬁ, I., Cappos, J., and Ford,

B. (2017). CHAINIAC: Proactive Software-Update

Transparency via Collectively Signed Skipchains and

Veriﬁed 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.,

Khofﬁ, 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=” gps−c 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 [ a−fA−F0 −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 −to−b 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 deﬁnition example (xml ﬁle format)

Distributed Data Validation for a Key-value Store in a Decentralized Electric Vehicle Charging Network

363