Talk at IoTCon / MobileTechCon 2016 in Berlin

1. Achim Friedland | GraphDefiend GmbH
Can the e-Mobility Charging Infrastructure
be a Blueprint for other IoT Projects?

2. 1. Motivation
2. Bits, Bytes and Protocols
3. Improving the service via Blockchains?

3. e-Mobility is the future…
…and a real pleasure!

4. Charging your car…
…still a real pain!

5. Finding a parking spot…
…still a real pain!

6. Real time navigation…
…still a real pain!

7. Open Data is coming!
And will be more than just „free“ data.

9. Maybe more a bug pattern than
a success story!

10. Can‘t we do e-mobility somehow smarter?

11. 1. Motivation
2. Bits, Bytes and Protocols
3. Improving the service via Blockchains?

12. Internet of e-Mobility Things

13. Charging via Local Authentication

14. Charging via Local Authentication
Flat RFID Card Ids for User Authentication
→ Flooding, High Latency, Bad Scaling, Privacy?
Problem:

15. Charging via Remote Start
DE*GEF*E12345678*1
DE*GEF*E12345678*2
EVSE Id = Power Socket Id

16. Communication Patterns
CS
• Reservations & Remote Start/Stop
• Firmware Updates
• Local Authentication (RFID, NFC, …)
• Current Status, Events, Sensor Data

17. Internet of e-Mobility Things
Challenged Networking
• High latency & error rate, low throughput
• NAT instead of global routable IPv4 Addressing (no IPv6)
• Operational expensive workarounds (Private APNs, VPNs, …)

18. OCPP’s 1st Approach
CS
• HTTPS/SOAP Server
• Requires public IP Addresses or Private APN
in mobile networks (~VPN)
– Expensive in operations
• HTTPS/SOAP Client
• Often no reuse of TCP/TLS sessions
– High latency
Open Charge Point Protocol - http://www.openchargealliance.org

19. OCPP’s 2nd Approach
CS
• HTTPS/WebSockets Client
• Symmetric Remote Procedure Calls (WAMP)
• JSON data representation
• Solves a lot of problems of the 1st approach
• Slow and redundant HTTP/WebSockets
connection setup
• Still no state-machines defined
Open Charge Point Protocol - http://www.openchargealliance.org

20. When not to use HTTP in IoT?
• Bidirectional communication via a single
connection and single data representation
esp. when using SOAP (as it has its own reliable transport features!)
• Multiple replies for a single request or server-
sent-(priority)-events
• Neither CoAP, nor HTTP/2 are better
• ~for any M2M communication (ex. discoverability)

21. When to use HTTP in IoT?
• Real client-2-server communication over
multiple (virtual) connections
• Multiple data representations (HTML, XML,
JSON, CSV, …), encodings…
• Multiple human languages
• Data caching
• ~for any H2M communication

22. Lessons learned
• No matter what, build your protocol bottom up
• Do not try to work around HTTP issues!
• On wireless: Overall Air time matters much
more than plain packet size
• Steal context idea from JSON-LD for
versioning and protocol diversity/dialects
(Maybe a talk for next year…)

23. 1. Motivation
2. Bits, Bytes and Protocols
3. Improving the service via Blockchains?

24. e-Mobility Characteristics
• Selling energy is still highly regulated
• Selling energy is close to micro payments
• Digitalization benefits are mostly unattended
“Horses 3.0”
• Highly data-driven, but unclear how to
incentivize data providers and data quality

25. Charge my electric vehicle (now)
Route me from A to B* with (electric)
constraints
vs.
e-Mobility Mission Statement

26. • Data (access) marketplaces do not work
and do not solve data quality issues
• (Government) Open Data is already
payed and maintained
• What are business models for data-
driven companies in the new Open Data
Age?

27. Blockchains and Open Data
• Both are open
• Both try hard to
respect privacy
• Smart Contracts
define rules which
are enforced by the
system

28. Open e-Mobility Data on
Blockchains

29. Smart Contracts define…
• Data quality (e.g. correct static data, fast dynamic
data updates)
• Service-Level-Agreements of your backend
• Which protocol features do you support?
• Reservations and Remote Start/Stop
• Construction sites and traffic jams
• Taxes, Tolls and charges

30. Routing Example (1)
• EV driver starts a routing process from A to B*
• Companies use Open Data to calculate
possible routes and publish the results and
which data they used encrypted for the driver
on the Blockchain
• EV driver chooses a route and publishes the
data used on the Blockchain
( Maybe delayed for higher privacy )

31. Routing Example (2)
• Possible reservations are made
• Competitors can verify wether the provided
information on the used data for the routing
process make sense or not
→ They accept the transaction or not
• Data providers and the routing service are
refunded

32. Open Data on Blockchains
• Recording any data coming from billions of
data providers (everyone is a prosumer) on
blockchains
• Incentivize high data quality and services
• Refund only data that is actually useful:
“IoT Rank” ;)

33. 1. Motivation
2. Bits, Bytes and Protocols
3. Improving the service via Blockchains?

34. achim.friedland@graphdefined.com
https://open.charging.cloud
http://m6jonkyse2xyk7nd.onion
Q&A