Difference between revisions of "RISE V2G"

Revision as of 09:59, 29 May 2015

Getting Started

As the ISO/IEC 15118 defines a client-/server-based protocol, you can use RISE V2G's code to test the client representing the electric vehicle communication controller (EVCC) against the server representing a supply equipment communication controller (SECC, aka a charging station) or just use either client or server against your counterpart implementation. Start the EVCC instance by running StartEVCC.java in the main package of the org.eclipse.risev2g.evcc project. The SECC instance can be started by running StartSECC.java in the main package of the org.eclipse.risev2g.secc project.

The server must be started before the client tries to connect to the server running in the same network. The third of the three provided projects, namely org.eclipse.risev2g.shared, is a required project on the build path of both the EVCC and the SECC side as it holds common classes and libraries used by both entities.

Note that this project relies on a Java 8 runtime environment.

Configuring the Setup - Properties Files

Both the EVCC and the SECC have a properties file called EVCCConfig.properties and SECCConfig.properties respectively, residing in the root of each project. Take a look at these files to set the needed properties before starting the client and server instance. You can e.g. set the network interface on which the messages are to be exchanged, decide whether the EVCC wants to use TCP or TLS on the transport layer, and other parameters which are explained.

Using TLS And Certificates for XML Signatures

If the EVCC wants to communicate with the SECC via the secure TLS protocol (see setting in EVCCConfig.properties), then you need certain certificates and keys in order to make this communication work. The ISO/IEC 15118 protocol defines a set of certificates and cryptographic parameters which shall apply in case of a secure communciation. To make things as easy for you as possible, you will find a generateCertificates.sh Shell script in the 'RISE V2G Certfiicates' folder (not part of the three projects, but residing on the same level) which automatically generates all necessary certificates, private and public keys as well as Java keystores in the respective folders for you.

You should have OpenSSL 1.0.2 (or above) installed to comply with all security requirements imposed by ISO/IEC 15118. For example, OpenSSL 0.9.8 does not come with SHA-2 for SHA-256 signature algorithms. All OpenSSL commands listed in the generateCertificates.sh file are explained for a better understanding. If you are on a Windows machine, just rename the file ending from .sh to .bat.

Hint: If you run the genereateCertificates.sh script, make sure that the keystores folder which holds already generated Java keystores (.jks file ending) is empty.

After you executed the generateCertificates.sh script, you need to do the following:

1. Copy the files evccKeystore.jks and evccTruststore.jks from the keystores folder into the root of the org.eclipse.risev2g.evcc project (on the same level as EVCCConfig.properties).
2. Copy the files seccKeystore.jks and seccTruststore.jks from the keystores folder and the files contractCert.p12 and provServiceCert.p12 from the certs folder into the root of the org.eclipse.risev2g.secc project (on the same level as SECCConfig.properties).

Now you are ready to go.

Hint: If you already have the Java keystore files in the respective project roots but the TLS communication fails, you might need to generated the certificates and thus keystores again because of an expired contract certificate due to the limited validity period set in generateCertificates.sh file.

Communication Sessions and Interfaces

All session parameters and state information is hold in V2GCommunicationSessionEVCC.java (for the client) and V2GCommunicationSessionSECC.java (for the server) respectively.

There are several interfaces available through which an actual EVCC or SECC instance can be realised:

1. An interface for the information exchange between the EVCC and the internal communication bus of the EV (e.g. CAN) in order to request the relevant charging parameters from the EV as well as to communicate e.g. charging profiles to the EV (see package evController)
2. An interface for the information exchange between the SECC and the internal controller of the EVSE (Electric Vehicle Supply Equipment = charging station) in order to request status information (e.g. about the RDC and smart meter values) or open/close the contactors (see package evseController)
3. An interface for the communication with a backend (e.g. for further communication via e.g. the Open Charge Point Protocol (OCPP)) to request a charging profile for the respective EV (see package backend)

Each interface has a Dummy implementation for testing purposes. You can configure which interface implementation to use in the constructors of the aforementioned V2GCommunicationSessionEVCC.java and V2GCommunicationSessionSECC.java files.

EXI Codec

The default codec for the enconding and decoding of EXI (Efficient XML Interchange) messages is OpenEXI (see package exiCodec in the org.eclipse.risev2g.shared project). You could as well use the EXIficient library if you include the EXIficient library in this project and change the codec setting in the constructor of the MessageHandler.java file (see package messageHandling of org.eclipse.risev2g.shared).

The EXIficient library can currently not be distributed because of a license incompatibility between this project's Eclipse Public License and EXIficient's GPL v3 license. However, you may include it on your system and you will find an EXIficientCodec.java file in the exiCode package which is ready to work with the EXIficient library.

Logging

Extensive logging through log4j is available and can be adjusted from debugging level to error level with the respective log4j2.xml file.