switchev/rise-v2g

The only fully-featured reference implementation of the Vehicle-2-Grid communication interface ISO 15118

rise-v2g's Issues

Handling in WaitForChargeParameterDiscoveryReq takes too long

Currently the handling in WaitForChargeParameterDiscoveryReq on SECC side takes too long on embedded devices and violate the timing constraint of 2 seconds.

I identified 2 reasons for this:

• an unconditional sleep of 1 second in processIncomingMessage()
• the private key of Mobility Operator Sub-CA 2 is unencrypted from the keystore also within processIncomingMessage()

The following changes fixed it for me (possibly not the right solution):

• reduce the unconditional sleep to 500 ms
• unencrypt and cache the private key within the DummyBackendInterface constructor

ChargeParameterDiscoveryRes for EIM contains XML signature

According to ISO 15118-2:2014 (Table 104) the ChargeParameterDiscoveryRes message for EIM shouldn't contain a signature in it's header. But SECC of RiseV2G sends the XML signature also for EIM case, which looks wrong to me.

Expected behavior: In EIM case the XML signature in ChargeParameterDiscoveryRes should be omitted.

Here is an example trace from version 1.1.1:

hex encode:
809802219004B7236030928A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E632373686132353642020FAF9EB9A163505B97B754E77CDD3A210366E4BD450CDCDD0D50939A4557FCB1281D40419EB8CB1E470F22984A52A9BD36B74ADCB15DE31259D255F75561833AED51E77F25E2D29B8F4D5A094282CBB4785613692BC0A9A88976FA93CFBA23A88F482801C148CD2DCD2E6D0CAC900000000140700C2805840152510C400400040094800000062073008186040000

XML encoded:
<?xml version="1.0" encoding="UTF-8"?><s3:V2G_Message xmlns:s3="urn:iso:15118:2:2013:MsgDef" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://www.w3.org/2000/09/xmldsig#" xmlns:s1="urn:iso:15118:2:2013:MsgBody" xmlns:s2="urn:iso:15118:2:2013:MsgDataTypes" xmlns:s4="urn:iso:15118:2:2013:MsgHeader">
  <s3:Header>
    <s4:SessionID>864012DC8D80C24A</s4:SessionID>
    <s0:Signature>
      <s0:SignedInfo>
        <s0:CanonicalizationMethod Algorithm="http://www.w3.org/TR/canonical-exi/"/>
        <s0:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
        <s0:Reference URI="#ID1">
          <s0:Transforms>
            <s0:Transform Algorithm="http://www.w3.org/TR/canonical-exi/"/>
          </s0:Transforms>
          <s0:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <s0:DigestValue>IPr565oWNQW5e3VOd83TohA2bkvUUM3N0NUJOaRVf8s=</s0:DigestValue>
        </s0:Reference>
      </s0:SignedInfo>
      <s0:SignatureValue>6gIM9cZY8jh5FMJSlU3ptbpW5YrvGJLOkq+6qwwZ12qPO/kvFpTcemrQShQWXaPCsJtJXgVNREu3
1J590R1Eeg==</s0:SignatureValue>
    </s0:Signature>
  </s3:Header>
  <s3:Body>
    <s1:ChargeParameterDiscoveryRes>
      <s1:ResponseCode>OK</s1:ResponseCode>
      <s1:EVSEProcessing>Finished</s1:EVSEProcessing>
      <s2:SAScheduleList>
        <s2:SAScheduleTuple>
          <s2:SAScheduleTupleID>1</s2:SAScheduleTupleID>
          <s2:PMaxSchedule>
            <s2:PMaxScheduleEntry>
              <s2:RelativeTimeInterval>
                <s2:start>0</s2:start>
                <s2:duration>7200</s2:duration>
              </s2:RelativeTimeInterval>
              <s2:PMax>
                <s2:Multiplier>3</s2:Multiplier>
                <s2:Unit>W</s2:Unit>
                <s2:Value>11</s2:Value>
              </s2:PMax>
            </s2:PMaxScheduleEntry>
          </s2:PMaxSchedule>
          <s2:SalesTariff s2:Id="ID1">
            <s2:SalesTariffID>1</s2:SalesTariffID>
            <s2:SalesTariffEntry>
              <s2:RelativeTimeInterval>
                <s2:start>0</s2:start>
              </s2:RelativeTimeInterval>
              <s2:EPriceLevel>1</s2:EPriceLevel>
            </s2:SalesTariffEntry>
          </s2:SalesTariff>
        </s2:SAScheduleTuple>
      </s2:SAScheduleList>
      <s2:AC_EVSEChargeParameter>
        <s2:AC_EVSEStatus>
          <s2:NotificationMaxDelay>0</s2:NotificationMaxDelay>
          <s2:EVSENotification>None</s2:EVSENotification>
          <s2:RCD>false</s2:RCD>
        </s2:AC_EVSEStatus>
        <s2:EVSENominalVoltage>
          <s2:Multiplier>0</s2:Multiplier>
          <s2:Unit>V</s2:Unit>
          <s2:Value>230</s2:Value>
        </s2:EVSENominalVoltage>
        <s2:EVSEMaxCurrent>
          <s2:Multiplier>0</s2:Multiplier>
          <s2:Unit>A</s2:Unit>
          <s2:Value>32</s2:Value>
        </s2:EVSEMaxCurrent>
      </s2:AC_EVSEChargeParameter>
    </s1:ChargeParameterDiscoveryRes>
  </s3:Body>
</s3:V2G_Message>

Build instructions

Hi!
Am I simply missing the build instructions, or are there none? After a lot of random tries and "find" I finally found out how to build it - maybe someone should write that down for new users?

Just put a simple line "call 'mvn package' in 'RISE-V2G-PARENT' into the README.md?

GenerateSharedSecret - invalid coordinate

Dear Marc,

Not sure if this is a bug and I know it is not of your responsibility but when I generate a new public/private EC key pair (using openSSL c++ API) to encrypt ContractCertPrivateKey I get the following exception on RISE-V2G (evcc):

Exception in thread "Thread-0" java.security.ProviderException: invalid coordinate at jdk.crypto.ec/sun.security.ec.ECDHKeyAgreement.validateCoordinate(ECDHKeyAgreement.java:118) at jdk.crypto.ec/sun.security.ec.ECDHKeyAgreement.validate(ECDHKeyAgreement.java:137) at jdk.crypto.ec/sun.security.ec.ECDHKeyAgreement.deriveKeyImpl(ECDHKeyAgreement.java:222) at jdk.crypto.ec/sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:169) at java.base/javax.crypto.KeyAgreement.generateSecret(KeyAgreement.java:598) at com.v2gclarity.risev2g.shared.utils.SecurityUtils.generateSharedSecret(SecurityUtils.java:1278) at com.v2gclarity.risev2g.shared.utils.SecurityUtils.decryptContractCertPrivateKey(SecurityUtils.java:1507) at com.v2gclarity.risev2g.evcc.states.WaitForCertificateInstallationRes.processIncomingMessage(WaitForCertificateInstallationRes.java:77) at com.v2gclarity.risev2g.evcc.session.V2GCommunicationSessionEVCC.update(V2GCommunicationSessionEVCC.java:183) at java.base/java.util.Observable.notifyObservers(Observable.java:173) at com.v2gclarity.risev2g.evcc.transportLayer.StatefulTransportLayerClient.processIncomingMessage(StatefulTransportLayerClient.java:124) at com.v2gclarity.risev2g.evcc.transportLayer.TLSClient.run(TLSClient.java:169) at java.base/java.lang.Thread.run(Thread.java:834)

Where:

private static void validateCoordinate(BigInteger c, BigInteger mod) { if (c.compareTo(BigInteger.ZERO) < 0) { throw new ProviderException("invalid coordinate"); } `` if (c.compareTo(mod) >= 0) { throw new ProviderException("invalid coordinate"); } }

The only way to avoid this exception is to force that the generated public key has both it's coordinates positive.

With this workaround CertificateInstallation always works, but I don't believe that such a workaround should be needed. Analysing the elliptic curve and its domain parameters it's seems reasonable that the coordinates could be lower than zero.

At the end of the day I don't know if this bug is on the generate key pair of openssl API or on the sun.security API side.

Would like to hear your opinion and for the sake of the security of PnC this possible issue should be clarified.

Out of memory exception

Hi, I am a first time user of this project and new to V2G. Thanks for giving access to such a useful project. I was having a play with the SECC server application and discovered a situation where memory allocation fails.

Line 125 of ConnectionHandler.java can try allocate a large memory block if the payload length is incorrect. You can simulate this by opening a raw TCP connection (eg netcat) to the server and send some random characters. I know this is not intended use but a possible scenario should the connection get out of sync or during development...

I have not looked at the protocol in detail yet to know if there are limitations on the length of a payload that could be checked earlier? [Edit] Table 9 of ISO15118-2 says payload length can be 0...4294967295.

The offending line:

getLogger().debug("Length of V2GTP payload in bytes according to V2GTP header: " + getPayloadLength());
setV2gTPPayload(new byte[getPayloadLength()]);

Example debug output:

2019-09-12T11:49:06,995 DEBUG [ConnectionThread fe80:0:0:0:e2d5:5eff:fe68:7a77%2] ConnectionHandler: Length of V2GTP payload in bytes according to V2GTP header: 1935959667
Exception in thread "ConnectionThread fe80:0:0:0:e2d5:5eff:fe68:7a77%2" java.lang.OutOfMemoryError: Java heap space

Regards

Ashley

Please add a contributor license agreement

As a possible contributor I would like to know how I could contribute...

Too big current in PreCharge

Hello.

I'm not sure if this is a bug or just some thoughts on this topic ;)

Based on IEC 61851-23 (CC6.1 or CC6.2) that I can assume is base for chargers, current in PreCharge phase shouldn't be bigger than 2A. In RV2G target current is set once for whole session. If you would like to implement changes, then RISEV2G/EVCC/WaitForCableCheckRes.java:59 should receive 2A PhysicalValue (maybe another method in controller, e.g. getPreChargeCurrent()?).

Or maybe I'm too detailed at ISO15118 level?

Igor

SignatureException is thrown at EVSE

Hello,

When setting DC_combo_core as requested energy transfer mode, the Charging Loop Counter is not considered (see here). The charging loop is instead stopped by a SignatureException thrown in the SECC-Code.
Apparently the signature of an MeteringReciptReq sent by the EVCC is invalid.

2018-01-10 11:42:26.447 [ConnectionThread fe80:0:0:0:6ce8:6864:8bd7:9744%2] ERROR SecurityUtils - SignatureException occurred while trying to verify signature value
java.security.SignatureException: Could not verify signature
	at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:325) ~[sunec.jar:1.8.0_151]
	at java.security.Signature$Delegate.engineVerify(Signature.java:1219) ~[?:1.8.0_144]
	at java.security.Signature.verify(Signature.java:652) ~[?:1.8.0_144]
	at com.v2gclarity.risev2g.shared.utils.SecurityUtils.verifySignature(SecurityUtils.java:1920) [classes/:?]
	at com.v2gclarity.risev2g.shared.utils.SecurityUtils.verifySignature(SecurityUtils.java:1826) [classes/:?]
	at com.v2gclarity.risev2g.secc.states.WaitForMeteringReceiptReq.isResponseCodeOK(WaitForMeteringReceiptReq.java:111) [classes/:?]
	at com.v2gclarity.risev2g.secc.states.WaitForMeteringReceiptReq.processIncomingMessage(WaitForMeteringReceiptReq.java:63) [classes/:?]
	at com.v2gclarity.risev2g.secc.session.V2GCommunicationSessionSECC.processIncomingMessage(V2GCommunicationSessionSECC.java:184) [classes/:?]
	at com.v2gclarity.risev2g.secc.session.V2GCommunicationSessionSECC.update(V2GCommunicationSessionSECC.java:162) [classes/:?]
	at java.util.Observable.notifyObservers(Observable.java:159) [?:1.8.0_144]
	at com.v2gclarity.risev2g.secc.transportLayer.ConnectionHandler.run(ConnectionHandler.java:135) [classes/:?]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
Caused by: java.security.SignatureException: Invalid encoding for signature
	at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:400) ~[sunec.jar:1.8.0_151]
	at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:322) ~[sunec.jar:1.8.0_151]
	... 11 more
Caused by: java.io.IOException: Invalid encoding: redundant leading 0s
	at sun.security.util.DerInputBuffer.getBigInteger(DerInputBuffer.java:162) ~[?:1.8.0_144]
	at sun.security.util.DerValue.getPositiveBigInteger(DerValue.java:552) ~[?:1.8.0_144]
	at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:385) ~[sunec.jar:1.8.0_151]
	at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:322) ~[sunec.jar:1.8.0_151]
	... 11 more

This is propably the late result of an exception thrown by the EVCC-Code:

2018-01-10 11:42:26.440 [Thread-1] WARN  SecurityUtils - ArrayIndexOutOfBoundsException occurred while trying to get raw signature from DER encoded signature
java.lang.ArrayIndexOutOfBoundsException: null
	at java.lang.System.arraycopy(Native Method) ~[?:1.8.0_144]
	at com.v2gclarity.risev2g.shared.utils.SecurityUtils.getRawSignatureFromDEREncoding(SecurityUtils.java:2009) [classes/:?]
	at com.v2gclarity.risev2g.shared.utils.SecurityUtils.signSignedInfoElement(SecurityUtils.java:1791) [classes/:?]
	at com.v2gclarity.risev2g.shared.messageHandling.MessageHandler.getHeader(MessageHandler.java:208) [classes/:?]
	at com.v2gclarity.risev2g.shared.messageHandling.MessageHandler.getV2GMessage(MessageHandler.java:188) [classes/:?]
	at com.v2gclarity.risev2g.shared.messageHandling.MessageHandler.getV2GMessage(MessageHandler.java:174) [classes/:?]
	at com.v2gclarity.risev2g.shared.misc.State.getSendMessage(State.java:97) [classes/:?]
	at com.v2gclarity.risev2g.shared.misc.State.getSendMessage(State.java:59) [classes/:?]
	at com.v2gclarity.risev2g.evcc.states.WaitForCurrentDemandRes.processIncomingMessage(WaitForCurrentDemandRes.java:81) [classes/:?]
	at com.v2gclarity.risev2g.evcc.session.V2GCommunicationSessionEVCC.update(V2GCommunicationSessionEVCC.java:178) [classes/:?]
	at java.util.Observable.notifyObservers(Observable.java:159) [?:1.8.0_144]
	at com.v2gclarity.risev2g.evcc.transportLayer.StatefulTransportLayerClient.processIncomingMessage(StatefulTransportLayerClient.java:119) [classes/:?]
	at com.v2gclarity.risev2g.evcc.transportLayer.TLSClient.run(TLSClient.java:169) [classes/:?]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]

It seems the length of R and S are not always 32 or 33 but sometimes 31 as well.
How should this case be handled?

Logfiles for this run are attached. If you need more details i will provide them ASAP.

Thank You for the Support!
EVCC.log

Best regards,
Jan

Config file not found on running StartSECC (Properties file location './SECCConfig.properties' not found (FileNotFoundException)

I clone the project from Github, set it up in IntelliJ as a project using the PARENT pom.xml. Get all the dependencies. That all runs fine.

But when I try to run StartSECC it tells me this
MiscUtils: Properties file location './SECCConfig.properties' not found (FileNotFoundException).

Then, apparently because it can't find the config file it says
MiscUtils: No entry found in the properties file for property 'network.interface'

I've previously gone through the instructions to make sure that IPv6 is configured on this machine.

Here's a screenshot of the error.

EXI decoding instruction missing

I'm playing with the EXI examples, using Exificient-Gui, but no matter what I try, I cannot convert it to XML. Either the resulting file is empty, or it throws an exception.

Can you provide the instructions on how to decode an EXI message, if possible for EXIficient-Gui?

I have been using the schema's, and I have converted the hex-encoded example to a binary using cat input.hex | xxd -r -p > output.bin. Then I selected 'EXI to XML' in the program, and played with the settings to match this source file. I am doing this to understand how EXI works in the context of 15118, and get a feeling for how it works.

.

trusted_ca_keys and ocsp support

Hello:

When establishing TLS connection, I got fatal error on the RISE-V2G(SECC) side. And I think this is because the TLS library of RISE-V2G(SECC) didn't support trusted_ca_keys and ocsp extensions in the client_hello message. Am I right?
RISE-V2G(SECC) has done the interoperability with verisco test. Is it mean it is not the necessary to support trusted_ca_keys and ocsp support on EVCC side?

open-plc-utils spi error

I am making use of the Qualcomm QCA7000 Serial-to-Powerline Bridge chip and trying to connect this chip to the host processor (RPi4 Buster) over SPI. I have developed all the necessary hardware and installed the qca7000 linux drivers on the host but continuously get the following errors when connecting to the SPI Slave port of the QCA7005: dmesg | grep qca produces the following:

qcaspi spi0.0: Invalid signature (0x0000)

qcaspi: probe of spi0.0 failed with error -14

I have added dtoverlay=qca7000 to config.txt and enabled the SPI on the RPi4.

I have tried different configurative pin strapping options as indicated in the datasheet but keep getting the same errors. Any advise on this? Or anyone been able to connect to this chip on Buster?

issue in getting started guide for a windows maschine

Section "Using TLS And Certificates for XML Signatures"
It is not possible so create any cert on a Windows maschine just by rename the "generateCertificates.sh" to "generateCertificates.bat".

the shellskript have to be changed as following:

• rename in .bat
• delete all comments
• delete the parameter "-p" in the lines where the folders will be created
• replace the parameter variables of the validity of the certs in the command lines into the values which are defined at the beginning of the script
• change all lines with the "cat" command to the MS-DOS equivalent "copy /b" and change the syntax of the folder structure from "/" to \

Example, before:
cat certs/cpoSubCA2.pem certs/cpoSubCA1.pem > certs/intermediateCPOCAs.pem

after:
copy /b certs\cpoSubCA2.pem + certs\cpoSubCA1.pem certs\intermediateCPOCAs.pem

Release on public maven repository

Hi, this is more of a feature request than an issue. Could your release rise-v2g on a public repository such as maven central repository?
Thanks.

Communicate Rise V2G with raspberry pi

Hello everyone,

I got the Rise V2G floders from this github (https://github.com/SwitchEV/RISE-V2G), I use them via Eclipse Titan.
Now I want to communicate them with raspberry pi by using IP address but I don't know how to do.

Any help would be appreciated. Thank you!

EV seems to not accept the SupportedAppProtocolRes

Hello,

I am currently testing on an EV, which seems to be closing its TCP-Socket after receiving my SupportedAppProtocolRes. I can see some differences in the response XML compared to the examples in din70121 and iso15118. Like the additional name spaces and the "standalone="yes"". Is there something I am overlooking or has this behavior been seen before?

Here is the receive and response :

Received EXI stream: 8000DBAB9371D3234B71D1B981899189D191818991D26B9B3A232B30020000040040

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <ns2:supportedAppProtocolReq xmlns:ns6="urn:iso:15118:2:2013:MsgDef"
     xmlns:ns5="http://www.w3.org/2000/09/xmldsig#"
     xmlns:ns7="urn:iso:15118:2:2013:MsgBody"
     xmlns:ns2="urn:iso:15118:2:2010:AppProtocol"
     xmlns:ns4="urn:iso:15118:2:2013:MsgDataTypes"
     xmlns:ns3="urn:iso:15118:2:2013:MsgHeader">
     <AppProtocol>
         <ProtocolNamespace>urn:din:70121:2012:MsgDef</ProtocolNamespace>
         <VersionNumberMajor>2</VersionNumberMajor>
         <VersionNumberMinor>0</VersionNumberMinor>
         <SchemaID>1</SchemaID>
         <Priority>1</Priority>
     </AppProtocol>
 </ns2:supportedAppProtocolReq>

EXI encoded SupportedAppProtocolRes: 80400040
Base64 encoded SupportedAppProtocolRes: gEAAQA==

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:supportedAppProtocolRes xmlns:ns6="urn:din:70121:2012:MsgDef"
    xmlns:ns5="http://www.w3.org/2000/09/xmldsig#"
    xmlns:ns7="urn:din:70121:2012:MsgBody"
    xmlns:ns2="urn:iso:15118:2:2010:AppProtocol"
    xmlns:ns4="urn:din:70121:2012:MsgDataTypes"
    xmlns:ns3="urn:din:70121:2012:MsgHeader">
    <ResponseCode>OK_SuccessfulNegotiation</ResponseCode>
    <SchemaID>1</SchemaID>
</ns2:supportedAppProtocolRes>

What is the platform to run this demo?

Hi Authors,

Thank you for your contribution on ISO 15118.
I have one simple question, what is the platform you run this demo? e.g. AM335x.
And what's more, run on which kind of OS?
Thanks in advance.

Charging Loop Counter not always considered

Hello,

Thanks for providing this great tool, it has been very helpful in getting a feel for the V2G communication.

As i have been "playing around" with RiseV2G, i noticed the isChargingLoopActive method and the chargingLoopCounter in the DummyEVController, which are used to control the number of charging loops and thus the amount of messages exchanged in between the EVSE and the EV.

When setting the energy transfer mode to DC_COMBO_CORE (via the EVCCConfig.properties or the getRequestedEnergyTransferMode method of the DummyEVController) the amount of exchanged messages increases significantly compared to other transfer modes. Often there are more than 100 CurrentDemandReq/Res and MeteringReceiptReq/Res pairs. Apparently the MeteringRecipt handling does inhibit the correct consideration of the charge loops.

The communication finally terminates when a Signature Exception is thrown at the EVSE side, which seems to be a different issue.

Could you please confirm this behaviour? - Thank you!

Wrong sequence when ReceiptRequired is true in last CurrentDemandRes

I have an issue with session termination when using plug and charge with RISE V2G as EV:

1. Charging session is in the charge loop
2. The EVSE sets the ReceiptRequired parameter in the last CurrentDemandRes message to true
3. The EV sends the MeteringReceiptReq message
4. The EVSE sends the MeteringReceiptRes message
5. The EV sends the PowerDeliveryReq with ChargeProgess = STOP_CHARGING
6. The EVSE sends OK response code in PowerDeliveryRes
7. The EV sends CurrentDemandReq message which is not correct. The EV should continue with WeldingDetection or SessionStop as described in [V2G2-590].

When the EVSE does not set the ReceiptRequired flag in the last CurrentDemandRes message everything works fine.

Log of the session end:
session_pnc.log

Lack of information on the Controller side

Hello,

During my work with RISE-V2G I've found a few situations where the Controller could use some more detail about the current progress than what is available now.

On the SECC side:

• details of the CurrentDemandReq like the remainding time or the EVRESSSOC could be useful for the customer
• current state (and change in the state) would be useful for various charge related processes: when to activate on isolation checking, when to turn on different PSU, etc.

I believe such situations would exist on the EVCC side as well.

I see two approaches here:

A) we could add more methods to IDCEVSEController and the respective interfaces. But there could be always cases that weren't thought of, and also this approach could make the interface cluttered

B) since V2GCommunicationSession is already Observable the controller could use this to subscribe events that expose a higher detail than available now. What I'm thinking of is that a notifyObserver would be called with the current state and the latest received and parsed message every time a message arrives.

I've opened this issue to discuss these possibilities. When there is a decision I'd be glad to send pull requests with the changes.

Invalid EXI when receiving one message in multiple TLS records.

I am currently using RiseV2G EV with our own EVSE. When sending data with maximum TLS record size of i.e. 3kb and the message is therefore split up in two records, the application reads only the first record and shows the rest of the EXI data as zeros:

2022-01-13T10:33:53,208 DEBUG [Thread-1] TLSClient: Message sent
2022-01-13T10:33:53,208 DEBUG [Thread-1] V2GCommunicationSessionEVCC: New state is WaitForCertificateInstallationRes
2022-01-13T10:33:53,881 DEBUG [Thread-1] TLSClient: Length of V2GTP payload in bytes according to V2GTP header: 4252
2022-01-13T10:33:53,882 DEBUG [Thread-1] TLSClient: Message received
2022-01-13T10:33:53,882 DEBUG [Thread-1] EXIficientCodec: Received EXI stream: 8098020B6D0B10D2CDFC5C4A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311B4B219012B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E6323736861323536420B4FF9BB803878F3BB82A16B7508900A0FD67943BAC8DDB1355CDFB76D083E12F040C46D2C86204AD0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5EA8A45EC6C2DCDEDCD2C6C2D85ACAF0D25E90A5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B195B98C8DCDA184C8D4D908121B6407CA9BBD25C144ED4D255C7841181A37907FCC4868742161699F9955BD010311B4B21A012B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E6323736861323536420DD2EDA401D6D190B71182FAE0996258ADCCB3EC539CD7554F3AC631AB61E9A0C040C46D2C86604AD0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5EA8A45EC6C2DCDEDCD2C6C2D85ACAF0D25E90A5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B195B98C8DCDA184C8D4D9083CC95EE6E24A59EA1A0EEDAA66BE5343C27A2568BB80126E5CDAA19A7B80EBF4C4A06484BD87E8950733237EB265A3FFF01E2359212A7D8D6867CAB181452BCD9C3DACC00045FC97B123708150B93644A6163EC361B8EE7DFCBAEA60A6566C66A4C4206002BB0430820237308201DCA003020102020819B94197210BA4A1300A06082A8648CE3D0403023073310B30090603550406130244453111300F06035504070C0848616E6E6F76657231173015060355040A0C0E536576656E7374617820476D624831143012060355040B0C0B446576656C6F706D656E743122302006035504030C195354582044656D6F20504B492043504F205375622043412032301E170D3232303130353134343531315A170D3232303530363134343531315A3073310B30090603550406130244453111300F06035504070C0848616E6E6F76657231173015060355040A0C0E536576656E7374617820476D624831143012060355040B0C0B446576656C6F706D656E74310D300B06035504030C044350494431133011060A0992268993F22C640119160343504F3059301306072A8648CE3D020106082A8648CE3D03010703420004CC29D4D4ED4EEB8039F262564E317AABDFE6C491AB831B6CA730E6D890A4FDBC619973DBEF613715CE142D977A3ACD8AF8FD7CF66F33EE9A9C780C3965C3A87FA35A305830090603551D1304023000300B0603551D0F040403020490301D0603551D0E04160414584E6BB0A0E0BF3023AC1B18FF0414A38B942088301F0603551D2304183016801467E7B87ADBAA47588BDBB23F5C02F6DB265AB845300A06082A8648CE3D0403020349003046022100DF14B14BFADD199DADA4C6C047114EC9017709E715F77D1C2AD653DC0127A865022100D7E0FCE0AE9560EB161A0E62AF415C2A98AAC0FD9F2B982CD973D3841E77BC3206A8218410128984100FB50018100810104807CE4D521339C4F1998050304154324671E8201811840C2188598048301AA820309812222988898078301AA820386042430B73737BB32B9188B980A8301AA8205060729B2BB32B739BA30BC1023B6B124188A18090301AA82058605A232BB32B637B836B2B73A188F180E0301AA8201860AA9AA2C102232B6B7902825A4902B1923902937B7BA18899808830504C91344C9F91632008C8B01AB1923980F0B8699191818981A989A1A1A98982D0B86991B1818981A189A1A1A98982D183A188598048301AA820309812222988898078301AA820386042430B73737BB32B9188B980A8301AA8205060729B2BB32B739BA30BC1023B6B124188A18090301AA82058605A232BB32B637B836B2B73A189198108301AA8201860D29AA2C102232B6B7902825A490283937BB1029BAB11021A09018982C98098303954324671E81008304154324671E81808381A1000258569D3D79CB1839D89AC6486F29CA80E800F9866E117D6996CDC42B3BDDD5282D251B4B5D79A251ADA6ED339DCF2EC45D1D1A4B120D434A54D8508A1786ED35D1B0182F18078301AA8E89820418030080FF81008098058301AA8E8782020181008B180E8301AA8E87020B020A27C9AE316FC69C8F0B506100F49842ED9C70DC55980F8301AA8E91820C180B400A5FECCD3CA4278E1FC11463238F8BA9C4CB0DC58818050304154324671E82018101A4801823011080402328CD1D05F3792F4F6556FF99BC9422A744F68FD0592788FCA728F691B73D81108074FB1E2ECA4DC9BA7C7FC35B18870400DC57C13707EE11DCA5074DC454A8DA010620218410120184100F2D00181008101048064F09628D850E40298050304154324671E820181183A188598048301AA820309812222988898078301AA820386042430B73737BB32B9188B980A8301AA8205060729B2BB32B739BA30BC1023B6B124188A18090301AA82058605A232BB32B637B836B2B73A189198108301AA8201860D29AA2C102232B6B7902825A490283937BB1029BAB11021A09018980F0B8699191818981A989A1A1A9898AD0B86991A1818981A989A1A1A9898AD183A188598048301AA820309812222988898078301AA820386042430B73737BB32B9188B980A8301AA8205060729B2BB32B739BA30BC1023B6B124188A18090301AA82058605A232BB32B637B836B2B73A189198108301AA8201860D29AA2C102232B6B7902825A490283937BB1029BAB11021A09019182C98098303954324671E81008304154324671E81808381A10002247DB9834CB9AB58FC62C5F0BC3B776C406981166A413BD6191D4F30E6A0D1E7C17470B0C56CFFD2F6BBD6DBB71C416FF8502FEDF133B8019B477043A35A8BA0D1B0182F18078301AA8E89820418030080FF81008018058301AA8E8782020181008B180E8301AA8E87020B020A017CC342837A06F59C64E05B48EB7838081DF981980F8301AA8E91820C180B400A27C9AE316FC69C8F0B506100F49842ED9C70DC5598050304154324671E82018101A48018230110806B5D99F3F18C00B5AED12ABBA023F5D0A145CC16F3B4B40CE05F82E302210C9801108067440FE529915AFF61BA3EA01F87F1619F83B92434DC7ADC7BD5F37E7A275B78900569643129C10C208088CC2080722800C080408082403132A687E785A8CA0C0281820AA192338F4100C08C1C8C42CC024180D5410184C091114C444C03C180D54101C30212185B9B9BDD995C8C45CC054180D54102830394D95D995B9CDD185E0811DB58920C450C048180D54102C302D1195D995B1BDC1B595B9D0C484C07C180D54100C30614D5160811195B5BC81412D2481353C814DD588810D0480C8C0785C34C8C8C0C4C4CCC0E0D4C8CCCD685C34C8D0C0C4C4CCC0E0D4C8CCCD68C17CC42CC024180D5410184C091114C444C03C180D54101C30212185B9B9BDD995C8C45CC054180D54102830394D95D995B9CDD185E0811DB58920C450C048180D54102C302D1195D995B1BDC1B595B9D0C438C030180D54100C30151535052510C164C04C181CAA192338F408041820AA192338F40C041C0D080010E0BD949C3212DA2DEB369134408E7FCB517A6CC16F1B186E5BBA3D2F12D3759A9252D1EBA17FC0ECED47F6714243CEE1552E26CA8EB82D8E81252E35789003328D68C160C024180D54744C1008C000C02C180D54743C10100C080FE0C074180D54743810581052018F455BDB9450C7D7647934A4B6FB9A544240C8C07C180D54748C1060C05A0051C208BF4FDC7DA5EE86E9E428B0F17649BE771CC8C0281820AA192338F4100C080D2400C1180884031D43CFC036038DC3C4011C4ADBF8FA8432BBDF7899B70213976E48A644FE3A440884038F8BC65609F2A3B115B76EC274A8790AD57D02C211E0FD7DFFA0E59A15C17C0017E0861040476610403C3400604020404101D0AD25D9436822260140C10550C919C7A08060460E262166000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
ERROR:  ''
2022-01-13T10:33:53,889 ERROR [Thread-1] EXIficientCodec: Error occurred while trying to decode (TransformerException)
javax.xml.transform.TransformerException: java.lang.NullPointerException

The application should wait for more data when it hasn't received the amount of data specified in the V2GTP header:

RISE-V2G/RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/transportLayer/StatefulTransportLayerClient.java

Line 110 in 9abd5ae

getInStream().read(getV2gTPPayload());

saveContractCertificateChain - Path to keystore

Dear Marc,

I come to one place in the code and the intention is not clear to me where to store the keystore after and updateing or installing certificates.

public static boolean saveContractCertificateChain(
		String keyStorePassword, 
		CertificateChainType contractCertChain,
		ECPrivateKey contractCertPrivateKey) {
		
KeyStore keyStore = getKeyStore(GlobalValues.EVCC_KEYSTORE_FILEPATH.toString(), keyStorePassword);

try {
	if (isPrivateKeyValid(contractCertPrivateKey, contractCertChain)) {
		keyStore.setKeyEntry(
				GlobalValues.ALIAS_CONTRACT_CERTIFICATE.toString(), 
				contractCertPrivateKey, 
				keyStorePassword.toCharArray(), 
				getCertificateChain(contractCertChain)); 
				
		// Save the keystore persistently
		try(FileOutputStream fos = new FileOutputStream("evccKeystore.jks")){
			keyStore.store(fos, 
                                  GlobalValues.PASSPHRASE_FOR_CERTIFICATES_AND_KEYS.toString().toCharArray());
		        }

Should the saved keystore be a different one or should update the exitsing one?

// Save the keystore persistently
try(FileOutputStream fos = new FileOutputStream(GlobalValues.EVCC_KEYSTORE_FILEPATH.toString())){
	keyStore.store(fos, 
        GlobalValues.PASSPHRASE_FOR_CERTIFICATES_AND_KEYS.toString().toCharArray());
}

Best regards,
Volker

15118-2/Ed2 support

Dear Marc,

Looking at the code, it seems to me that the second edition of the ISO 15118-2 is not supported yet. To be more specific, I couldn't find the implementation of the 2016 message namespace ("iso:15118:2:2016"), which I think is the equivalent to the 15118-2/Ed2 or "ISO2". Is my assumption correct? If yes, do you plan to implement this second edition in the near future or will you skip it and wait for a newer edition to be published?

This topic is critical to me, as I am using your SECC application as a test reference for my own V2G client implementation. It is very convenient not to need a dedicated PLC connection/implementation for testing. Therefore I would like to thank you for this open source project! It would be a shame if I could not continue using it for this purpose.

Optionally disable XML signatures

Hi, you did some great work with this project!

We have a V2G stack and want to use this server to test our implementation. I got it working but I had to disable the use of XML signatures because our stack in it's current version is missing the XML signature parsing support.

Is there a possibility that the use of XML signatures could be optionally disabled in the config file of the server?

Issues in getting started guide

The portable command to build RISE V2G with maven should be mvn package, not maven package like in the wiki entry under https://wiki.eclipse.org/RISE_V2G.

Btw: Since the repo https://github.com/eclipse/risev2g.git is obsolete, the clone instruction should be updated to the new github repository.

Time measurements based on system time

Rise V2G uses System.currentTimeMillis() to measure timings, which based on the current system time. This could leads to hard reproducible runtime issues, because e.g. NTP could change the system time and influence the result of System.currentTimeMillis().

In order to avoid this always use System.nanoTime() for time measuring, which is recommend by Oracle for this use case.

Crash when CurrentDemandRes does not contain optional ReceiptRequired element

Hi Marc,

I just stumbled upon this crash in EVCC side when ReceiptRequired element is not emitted by a SECC in CurrentDemandRes:

2018-11-11T23:04:56,170 DEBUG [Thread-1] V2GCommunicationSessionEVCC: New state is WaitForCurrentDemandRes
2018-11-11T23:04:56,175 DEBUG [Thread-1] TCPClient: Message received
2018-11-11T23:04:56,175 DEBUG [Thread-1] EXIficientCodec: Received EXI stream: 80980214CE3D7EC29385C0D0E00000002040C409003030C0080006143030313132323333343435353636373738380008
2018-11-11T23:04:56,177 DEBUG [Thread-1] EXIficientCodec: XML representation of CurrentDemandRes:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns6:V2G_Message xmlns:ns6="urn:iso:15118:2:2013:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:iso:15118:2:2013:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:iso:15118:2:2013:MsgDataTypes" xmlns:ns3="urn:iso:15118:2:2013:MsgHeader"><ns6:Header><ns3:SessionID>5338F5FB0A4E1703</ns3:SessionID></ns6:Header><ns6:Body><ns7:CurrentDemandRes><ns7:ResponseCode>OK</ns7:ResponseCode><ns7:DC_EVSEStatus><ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay><ns4:EVSENotification>None</ns4:EVSENotification><ns4:EVSEIsolationStatus>Valid</ns4:EVSEIsolationStatus><ns4:EVSEStatusCode>EVSE_Ready</ns4:EVSEStatusCode></ns7:DC_EVSEStatus><ns7:EVSEPresentVoltage><ns4:Multiplier>0</ns4:Multiplier><ns4:Unit>V</ns4:Unit><ns4:Value>400</ns4:Value></ns7:EVSEPresentVoltage><ns7:EVSEPresentCurrent><ns4:Multiplier>0</ns4:Multiplier><ns4:Unit>A</ns4:Unit><ns4:Value>2</ns4:Value></ns7:EVSEPresentCurrent><ns7:EVSECurrentLimitAchieved>false</ns7:EVSECurrentLimitAchieved><ns7:EVSEVoltageLimitAchieved>false</ns7:EVSEVoltageLimitAchieved><ns7:EVSEPowerLimitAchieved>false</ns7:EVSEPowerLimitAchieved><ns7:EVSEID>001122334455667788</ns7:EVSEID><ns7:SAScheduleTupleID>1</ns7:SAScheduleTupleID></ns7:CurrentDemandRes></ns6:Body></ns6:V2G_Message>
2018-11-11T23:04:56,177 DEBUG [Thread-1] WaitForCurrentDemandRes: CurrentDemandRes received
Exception in thread "Thread-1" java.lang.NullPointerException
	at com.v2gclarity.risev2g.evcc.states.WaitForCurrentDemandRes.processIncomingMessage(WaitForCurrentDemandRes.java:53)
	at com.v2gclarity.risev2g.evcc.session.V2GCommunicationSessionEVCC.update(V2GCommunicationSessionEVCC.java:178)
	at java.util.Observable.notifyObservers(Observable.java:159)
	at com.v2gclarity.risev2g.evcc.transportLayer.StatefulTransportLayerClient.processIncomingMessage(StatefulTransportLayerClient.java:122)
	at com.v2gclarity.risev2g.evcc.transportLayer.TCPClient.run(TCPClient.java:102)
	at java.lang.Thread.run(Thread.java:748)

If I modify the SECC by just adding this ReceiptRequired to False in the CurrentDemandRes, then it works.
Message sets conditions are: TCP, EIM, DC.

I checked in the standard, the only requirement relating to this condition is [V2G2-593]. It does says "The SECC sets “ReceiptRequired = FALSE" indicating that the Message Set MessageReceipt shall not be used by the EVCC.". But, to my interpretation which we can discuss openly ;), this does not actually impose the SECC to send it, as it does not use the word "shall" for it.

Like it does in [V2G2-788] for instance (but that only applies in PnC message sets, not EIM).

Because otherwise I don't see any other use case for having this element in CurrentDemandRes defined as optional. Unless I missed something, of course.

Cheers,
Axel

session pause on EVCC for Pmax = 0

Dear Marc,
I found that in 15118-4, there are a lot of test case about the session pause on EVCC if Pmax = 0, but I didn't find the process in RISE_V2G, I note RISE_V2G has already pass the verisco test, so is it(session pause on EVCC if Pmax = 0) not the necessary case?

for example:TC_EVCC_DC_VTB_PaymentServiceSelection_011
"Test System executes GoodCase procedure and waits for a paused V2G communication
session by receiving a SessionStopReq message with the current SessionID,
ChargingSession 'Pause' and all additional mandatory parameters (Test System has
sent a PmaxScheduleList with the first Pmax element = 0W (par_SECC_Pmax0W) within
ChargeParameterDiscoveryRes message before). After sending of a valid
SessionStopRes message, Test System waits for termination of the logical network by
the SUT, still detecting CP State B within the entire sleep mode. After
'par_SECC_Pmax0W' the SUT resumes the previously paused session by initiating a BCB
toggle. Furthermore Test System waits for successful link detection (old logical
network parameter) triggered by the SUT. Test System executes GoodCase procedure
and sends a ServiceDiscoveryRes message with the current SessionID, ResponseCode
'Ok', PaymentOption 'Contract' and 'ExternalPayment', valid
SupportedEnergyTransferMode and all additional mandatory parameters.
Test System then checks that the SUT sends a correct PaymentServiceSelectionReq
message with the current SessionID, the previous SelectedPaymentOption, valid
ServiceID and all additional mandatory parameters."

No IPv6 link-local address found

Hello Everyone,

I get the error

FATAL [main] MiscUtils: No IPv6 link-local address found on the network interface 'Software Loopback Interface 1' configured in the properties file

As I am on a windows machine, I have entered the command "route print", but none of the numbers in the interface list work for me. No matter which number (1, 5, 7, 13, 17, 19, 21) I choose, everytime the error above appeares. The interface list looks as followed:

===========================================================================
Schnittstellenliste
7...e8 d8 d1 aa 3c bb ......Intel(R) Ethernet Connection (6) I219-LM
17...4c 1d 96 1c 41 1c ......Microsoft Wi-Fi Direct Virtual Adapter
13...4e 1d 96 1c 41 1b ......Microsoft Wi-Fi Direct Virtual Adapter #2
21...4c e1 73 47 9e 43 ......Realtek USB GbE Family Controller
19...4c 1d 96 1c 41 1b ......Intel(R) Wi-Fi 6 AX200 160MHz
5...4c 1d 96 1c 41 1f ........Bluetooth Device (Personal Area Network)
1...............................................Software Loopback Interface 1
===========================================================================

Does anybody have an idea how I can solve this issue? Thank you very much in advance!

Greetings, Benedikt

Maven fails to build risev2g.evcc under Ubuntu 16.04.2 LTS (amd64)

If i try to build risev2g under Ubuntu 16.04 (amd64) i will always get a BUILD FAILURE:

Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.4.1:single (make-my-jar-with-dependencies) on project evcc: Error reading assemblies: Error locating assembly descriptor: file:/home/stefan/RISE-V2G/RISE-V2G-EVCC/src/assembly/bin.xml

Here some information about the environment:

stefan@Latitude-E4310:~/RISE-V2G$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

stefan@Latitude-E4310:~/risev2g$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

stefan@Latitude-E4310:~/risev2g$ mvn -v
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.10.9-041009-generic", arch: "amd64", family: "unix"

Finally the complete build output:

stefan@Latitude-E4310:~/RISE-V2G$ mvn package
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.eclipse.risev2g:evcc:jar:1.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-assembly-plugin @ org.eclipse.risev2g:evcc:[unknown-version], /home/stefan/RISE-V2G/RISE-V2G-EVCC/pom.xml, line 60, column 12
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.eclipse.risev2g:secc:jar:1.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-assembly-plugin @ org.eclipse.risev2g:secc:[unknown-version], /home/stefan/RISE-V2G/RISE-V2G-SECC/pom.xml, line 49, column 12
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] risev2g.parent
[INFO] risev2g.shared
[INFO] risev2g.evcc
[INFO] risev2g.secc
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building risev2g.parent 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building risev2g.shared 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for net.sourceforge.openexi:nagasena:jar:0000.0002.0052.0 is missing, no dependency information available
[WARNING] The POM for net.sourceforge.openexi:nagasena-rta:jar:0000.0002.0052.0 is missing, no dependency information available
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ shared ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 8 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ shared ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ shared ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/stefan/RISE-V2G/RISE-V2G-Shared/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ shared ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ shared ---
[INFO] No tests to run.
[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ shared ---
[INFO] 
[INFO] --- maven-shade-plugin:2.4.1:shade (default) @ shared ---
[INFO] Including com.siemens.ct.exi:exificient:jar:0.9.6 in the shaded jar.
[INFO] Including com.siemens.ct.exi:exificient-core:jar:0.9.6 in the shaded jar.
[INFO] Including com.siemens.ct.exi:exificient-grammars:jar:0.9.6 in the shaded jar.
[INFO] Including xerces:xercesImpl:jar:2.11.0 in the shaded jar.
[INFO] Including xml-apis:xml-apis:jar:1.4.01 in the shaded jar.
[INFO] Including org.apache.logging.log4j:log4j-api:jar:2.1 in the shaded jar.
[INFO] Including org.apache.logging.log4j:log4j-core:jar:2.1 in the shaded jar.
[INFO] Including net.sourceforge.openexi:nagasena:jar:0000.0002.0052.0 in the shaded jar.
[INFO] Including net.sourceforge.openexi:nagasena-rta:jar:0000.0002.0052.0 in the shaded jar.
[WARNING] shared-1.0.0-SNAPSHOT.jar, exificient-0.9.6.jar define 31 overlapping classes: 
[WARNING]   - com.siemens.ct.exi.api.sax.SAXDecoder$DocTypeTextLexicalHandler
[WARNING]   - com.siemens.ct.exi.util.SkipRootElementXMLReader
[WARNING]   - com.siemens.ct.exi.api.dom.SaxToDomHandler
[WARNING]   - com.siemens.ct.exi.api.stream.StAXDecoder
[WARNING]   - com.siemens.ct.exi.cmd.CmdOption
[WARNING]   - com.siemens.ct.exi.util.SimpleDocTypeParser
[WARNING]   - com.siemens.ct.exi.api.stream.StAXEncoder
[WARNING]   - com.siemens.ct.exi.api.stream.EmptyLocation
[WARNING]   - com.siemens.ct.exi.api.stream.StAXDecoder$1
[WARNING]   - com.siemens.ct.exi.api.stream.StAXEncoder$EncoderNamespaceContext
[WARNING]   - 21 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, log4j-core-2.1.jar define 554 overlapping classes: 
[WARNING]   - org.apache.logging.log4j.core.config.xml.XmlConfiguration$Status
[WARNING]   - org.apache.logging.log4j.core.appender.ConsoleAppender$ConsoleManagerFactory
[WARNING]   - org.apache.logging.log4j.core.appender.AbstractManager
[WARNING]   - org.apache.logging.log4j.core.net.server.UdpSocketServer
[WARNING]   - org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
[WARNING]   - org.apache.logging.log4j.core.config.plugins.visitors.PluginElementVisitor
[WARNING]   - org.apache.logging.log4j.core.appender.rolling.RollingFileManager$1
[WARNING]   - org.apache.logging.log4j.core.net.SslSocketManager$1
[WARNING]   - org.apache.logging.log4j.core.appender.db.jpa.JpaAppender
[WARNING]   - org.apache.logging.log4j.core.pattern.LineSeparatorPatternConverter
[WARNING]   - 544 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, exificient-core-0.9.6.jar define 208 overlapping classes: 
[WARNING]   - com.siemens.ct.exi.types.AbstractTypeCoder
[WARNING]   - com.siemens.ct.exi.grammars.event.StartElement
[WARNING]   - com.siemens.ct.exi.io.channel.BitEncoderChannel
[WARNING]   - com.siemens.ct.exi.grammars.event.DocType
[WARNING]   - com.siemens.ct.exi.core.EXIBodyDecoderReordered$EndElementEntry
[WARNING]   - com.siemens.ct.exi.attributes.AttributeFactory
[WARNING]   - com.siemens.ct.exi.grammars.event.StartDocument
[WARNING]   - com.siemens.ct.exi.core.AbstractEXIBodyEncoder$ProfileDisablingMechanism
[WARNING]   - com.siemens.ct.exi.values.ValueType
[WARNING]   - com.siemens.ct.exi.grammars.event.Comment
[WARNING]   - 198 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, xercesImpl-2.11.0.jar define 952 overlapping classes: 
[WARNING]   - org.apache.xerces.parsers.AbstractSAXParser
[WARNING]   - org.apache.xerces.xni.grammars.XMLGrammarDescription
[WARNING]   - org.apache.xml.serialize.SerializerFactoryImpl
[WARNING]   - org.apache.wml.WMLTdElement
[WARNING]   - org.apache.xerces.impl.io.Latin1Reader
[WARNING]   - org.apache.xerces.dom.DOMXSImplementationSourceImpl
[WARNING]   - org.apache.xerces.impl.dv.xs.Base64BinaryDV
[WARNING]   - org.apache.xerces.parsers.XIncludeAwareParserConfiguration
[WARNING]   - org.apache.xml.serialize.HTMLdtd
[WARNING]   - org.apache.xerces.dom.ElementDefinitionImpl
[WARNING]   - 942 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, xml-apis-1.4.01.jar define 346 overlapping classes: 
[WARNING]   - org.w3c.dom.css.CSSValueList
[WARNING]   - org.w3c.dom.ProcessingInstruction
[WARNING]   - org.w3c.dom.html.HTMLBodyElement
[WARNING]   - javax.xml.validation.SecuritySupport$6
[WARNING]   - javax.xml.transform.SecuritySupport$3
[WARNING]   - org.w3c.dom.Entity
[WARNING]   - org.w3c.dom.ls.LSParserFilter
[WARNING]   - org.w3c.dom.html.HTMLMetaElement
[WARNING]   - javax.xml.stream.events.ProcessingInstruction
[WARNING]   - javax.xml.transform.stax.StAXResult
[WARNING]   - 336 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, log4j-api-2.1.jar define 81 overlapping classes: 
[WARNING]   - org.apache.logging.log4j.message.LocalizedMessage
[WARNING]   - org.apache.logging.log4j.message.LocalizedMessageFactory
[WARNING]   - org.apache.logging.log4j.message.MessageFormatMessageFactory
[WARNING]   - org.apache.logging.log4j.ThreadContext$ContextStack
[WARNING]   - org.apache.logging.log4j.util.Strings
[WARNING]   - org.apache.logging.log4j.message.StructuredDataId
[WARNING]   - org.apache.logging.log4j.status.StatusData
[WARNING]   - org.apache.logging.log4j.message.LoggerNameAwareMessage
[WARNING]   - org.apache.logging.log4j.spi.LoggerContextFactory
[WARNING]   - org.apache.logging.log4j.simple.SimpleLoggerContext
[WARNING]   - 71 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, nagasena-rta-0000.0002.0052.0.jar define 66 overlapping classes: 
[WARNING]   - org.openexi.scomp.ProtoGrammar
[WARNING]   - org.openexi.scomp.EXISchemaFactory$GrammarLocation
[WARNING]   - org.openexi.scomp.EventTypeCache$4
[WARNING]   - org.openexi.scomp.EventWildcardNS
[WARNING]   - org.openexi.scomp.EXISchemaFactoryExceptionXMsg
[WARNING]   - org.openexi.scomp.EventTypeCache$1
[WARNING]   - org.openexi.scomp.EXISchemaFactory$ComparableAttributeUse
[WARNING]   - org.openexi.scomp.EXISchemaReader$SchemaScannerFacade
[WARNING]   - org.openexi.scomp.EventTypeCache$8
[WARNING]   - com.thaiopensource.exi.xsd.regex.jdk1_4.Translator$Subtraction
[WARNING]   - 56 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, nagasena-0000.0002.0052.0.jar define 203 overlapping classes: 
[WARNING]   - org.openexi.proc.EXIDecoder
[WARNING]   - org.openexi.proc.io.BitPackedScanner
[WARNING]   - org.openexi.proc.io.IntegerValueScriber$IntegerValue
[WARNING]   - org.openexi.proc.grammars.FragmentGrammar
[WARNING]   - org.openexi.proc.io.compression.ScannerChannelFactory
[WARNING]   - org.openexi.proc.grammars.BuiltinGrammar
[WARNING]   - org.openexi.proc.io.SimpleScanner$EXIEventSchemaMixedCharacters
[WARNING]   - org.openexi.proc.common.EventTypeList$1
[WARNING]   - org.openexi.proc.io.GYearValueScriber
[WARNING]   - org.openexi.proc.common.StringTable$1
[WARNING]   - 193 more...
[WARNING] shared-1.0.0-SNAPSHOT.jar, exificient-grammars-0.9.6.jar define 19 overlapping classes: 
[WARNING]   - com.siemens.ct.exi.grammars.persistency.GrammarsPreperation
[WARNING]   - com.siemens.ct.exi.grammars.EXIContentModelBuilder$XSAttributeUseSort
[WARNING]   - com.siemens.ct.exi.grammars.persistency.GrammarIdDispenser$1
[WARNING]   - com.siemens.ct.exi.grammars.persistency.GrammarIdDispenser
[WARNING]   - org.apache.xerces.impl.xpath.regex.EXIRegularExpression
[WARNING]   - com.siemens.ct.exi.grammars.persistency.Grammars2JSON$1
[WARNING]   - com.siemens.ct.exi.grammars.XSDGrammarsBuilder
[WARNING]   - com.siemens.ct.exi.grammars.EXIContentModelBuilder$XSAttributeDeclarationSort
[WARNING]   - com.siemens.ct.exi.grammars.persistency.Grammars2JSON
[WARNING]   - com.siemens.ct.exi.grammars.persistency.GrammarsPreperation$1
[WARNING]   - 9 more...
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin
[INFO] Replacing original artifact with shaded artifact.
[INFO] Replacing /home/stefan/RISE-V2G/RISE-V2G-Shared/target/shared-1.0.0-SNAPSHOT.jar with /home/stefan/RISE-V2G/RISE-V2G-Shared/target/shared-1.0.0-SNAPSHOT-shaded.jar
[INFO] Dependency-reduced POM written at: /home/stefan/RISE-V2G/RISE-V2G-Shared/dependency-reduced-pom.xml
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building risev2g.evcc 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ evcc ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ evcc ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ evcc ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/stefan/RISE-V2G/RISE-V2G-EVCC/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ evcc ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ evcc ---
[INFO] No tests to run.
[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ evcc ---
[INFO] 
[INFO] --- maven-assembly-plugin:2.4.1:single (make-my-jar-with-dependencies) @ evcc ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] risev2g.parent ..................................... SUCCESS [  0.185 s]
[INFO] risev2g.shared ..................................... SUCCESS [  2.798 s]
[INFO] risev2g.evcc ....................................... FAILURE [  0.489 s]
[INFO] risev2g.secc ....................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.733 s
[INFO] Finished at: 2017-07-22T11:41:26+02:00
[INFO] Final Memory: 16M/246M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.4.1:single (make-my-jar-with-dependencies) on project evcc: Error reading assemblies: Error locating assembly descriptor: file:/home/stefan/RISE-V2G/RISE-V2G-EVCC/src/assembly/bin.xml
[ERROR] 
[ERROR] [1] [INFO] Searching for file location: /home/stefan/RISE-V2G/RISE-V2G-EVCC/file:/home/stefan/RISE-V2G/RISE-V2G-EVCC/src/assembly/bin.xml
[ERROR] 
[ERROR] [2] [INFO] File: /home/stefan/RISE-V2G/RISE-V2G-EVCC/file:/home/stefan/RISE-V2G/RISE-V2G-EVCC/src/assembly/bin.xml does not exist.
[ERROR] 
[ERROR] [3] [INFO] File: /home/stefan/RISE-V2G/file:/home/stefan/RISE-V2G/RISE-V2G-EVCC/src/assembly/bin.xml does not exist.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :evcc

Build problem

Hi, your latest modification are missing a correct RISE-V2G-Shared version number update in PARENT, EVCC and SECC: actual Shared version is 1.2.5, but in the latter still reference 1.2.4, so it does not compile.

As a suggestion maybe you can modify Shared reference version number with:

<project.version>${project.version}</project.version>

Regards.

Payload length field of V2G-TP is interpreted as signed integer instead of unsigned

The payload length field of V2G-TP is interpreted as signed integer instead of unsigned, so test like:

if (getPayloadLength() > 10000 )

will not catch cases when the value is larger than 0x7FFFFFFF, this will result later in an exception trying to create an array with negative length.

Wrong Filename in generateCertificates.bat

Hello Dr. Mültin,

Thank you for all your hard work.
I found a little misstype in your Batch-File for generating the Keys and Certs.
The affectet File is located in
.\RISE-V2G\RISE-V2G-Certificates\generateCertificates.bat
Line 85 reads as follows:
openssl ecparam -genkey -name prime256v1 | openssl ec -aes-128-cbc -passout file:passphrase.txt -out privateKeys/v2gRootA.key

But the rest of the script expects a file in
privateKeys/v2gRootCA.key

It is just missing a "C".

So thanks again for supporting this marvelous project.

Take care,

Hermelinmaster

Signature verification fails

Latest update helped with SaleTarrif digest. But next step - verification - fails. It ends with exception thrown on EVCC side (with our SECC implementation).

Here are exception messages:
2017-09-28T09:49:01,669 ERROR [Thread-1] SecurityUtils: SignatureException occurred while trying to verify signature value java.security.SignatureException: Could not verify signature at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:325) ~[sunec.jar:1.8.0_151] at java.security.Signature$Delegate.engineVerify(Signature.java:1219) ~[?:1.8.0_144] at java.security.Signature.verify(Signature.java:652) ~[?:1.8.0_144] at org.v2gclarity.risev2g.shared.utils.SecurityUtils.verifySignature(SecurityUtils.java:1907) [classes/:?] at org.v2gclarity.risev2g.evcc.states.WaitForChargeParameterDiscoveryRes.verifySalesTariffs(WaitForChargeParameterDiscoveryRes.java:221) [classes/:?] at org.v2gclarity.risev2g.evcc.states.WaitForChargeParameterDiscoveryRes.processIncomingMessage(WaitForChargeParameterDiscoveryRes.java:124) [classes/:?] at org.v2gclarity.risev2g.evcc.session.V2GCommunicationSessionEVCC.update(V2GCommunicationSessionEVCC.java:178) [classes/:?] at java.util.Observable.notifyObservers(Observable.java:159) [?:1.8.0_144] at org.v2gclarity.risev2g.evcc.transportLayer.StatefulTransportLayerClient.processIncomingMessage(StatefulTransportLayerClient.java:119) [classes/:?] at org.v2gclarity.risev2g.evcc.transportLayer.TLSClient.run(TLSClient.java:169) [classes/:?] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144] Caused by: java.security.SignatureException: Invalid encoding for signature at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:400) ~[sunec.jar:1.8.0_151] at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:322) ~[sunec.jar:1.8.0_151] ... 10 more Caused by: java.io.IOException: insufficient data at sun.security.util.DerInputBuffer.truncate(DerInputBuffer.java:135) ~[?:1.8.0_144] at sun.security.util.DerInputStream.subStream(DerInputStream.java:160) ~[?:1.8.0_144] at sun.security.util.DerInputStream.readVector(DerInputStream.java:415) ~[?:1.8.0_144] at sun.security.util.DerInputStream.getSequence(DerInputStream.java:331) ~[?:1.8.0_144] at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:376) ~[sunec.jar:1.8.0_151] at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:322) ~[sunec.jar:1.8.0_151] ... 10 more

Here are data used to sign and verify signature:

ChargeParameterDiscoveryReq (EXI HEXDUMP): 8098020000000016732A5B0A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E632373686132353642023A03052A4032C755CAC2D05E2680EA107627EE06274A84317B20A438204A81212811548BB71F178C8BBF6DB9FCC5B01BDE29E312E47D88FAEA2DBB2BD2CC4F522697F189F37F0BF74EB8AB69ED4D27175C36D58EB6620ED5FE51A42F69466071F9E825329001901861900223102400C23182209C80
Private key (HEXDUMP): D4A439D114963031781D4331842784F6F4AE2B0AFDE9C0BBF8F60E310B9A7AFD
Public key (HEXDUMP): 0435A395084F19933A226E7D54E8784461AA9D7C9CBB68F76F28A87B8389EE6C3433A7AE0BE73615F1905D88BE65A7FEA9DF5B6C7D7FFBE64F6C0EC4ECE3F0B7BF
SignedInfo element (EXI HEXDUMP): 808112B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A1AB43A3A381D1797BBBBBB973B999737B933979918181897981A17BC36B63239B4B396B6B7B93291B2B1B239B096B9B430991A9B22042332025687474703A2F2F7777772E77332E6F72672F54522F63616E6F6E6963616C2D6578692F4852D0E8E8E0745E5EEEEEEE5CEE665CDEE4CE5E646060625E60685EF0DAD8CADCC646E6D0C2646A6C84018913DFC3DBDA4DAC7D64DC7CFEEAB57CE527B7ECB75BC4B46C94EA7F678A3BA370
SignedInfo element (HASH HEXDUMP): D42212AC1B75F9272C7FE35222202514CBFD1A14C01EA7360559E7903609517E
Calculated signature (HEXDUMP): 30450220502A11EA532DB9D4A224037182C7C3B4669242E54659F7C3328593FDFE855B13022100D340682C86947C21CCC472EEE5E552654E9E0739C6801D3C244859D953CDB5FF
ECC curve: secp256r1
Hash algorithm: SHA256

Message is correctly decoded on EVCC side and generated hash for SignedInfo element is equal to above one. Also public key used to verify signature on EVCC side is equal to above one.

This signature validates in this tool. You only have to change sig.updateString(msg1); to sig.updateHex(msg1); to insert SignedInfo EXI HEXDUMP into "Message string to be signed" field.

I also tried to verify signature between RISEV2G SECC and EVCC, but SECC can't load moSubCA2.pkcs8.der (even if it is generated through included script), so verification fails.

Can you confirm this behavior nad check if there is problem in RV2G?

"generateCertificates.sh" does not work.

When I run "generateCertificates.sh", the following error occurs.
It seems that the recently committed content contains typo.
There is a difference between "generateCertificates.bat" file and "generateCertificates.sh".
I will upload the modified file.

rm: cannot remove ‘keystores’: No such file or directory
read EC key
writing EC key
Error opening Private Key privateKeys/v2gRootCA.key
140192919066256:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('privateKeys/v2gRootCA.key','r')
140192919066256:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load Private Key
csrs/v2gRootCA.csr: No such file or directory
read EC key
writing EC key
Signature ok
subject=/CN=CPOSubCA1/O=RISE V2G Project/C=DE/DC=V2G
Error opening CA Certificate certs/v2gRootCACert.pem
140387296798352:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('certs/v2gRootCACert.pem','r')
140387296798352:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load certificate

How to use RISE-V2G for DIN 70121?

Hello!

I am trying to run this project and use it for DIN 70121 instead of ISO 15118, I would appreciate to get some advice on how to change the code accordingly and what could be the possible steps for it.

Thanks!

2K dependency errors

Hello
I'm new on java and Electric Charging programs

I have problem on running up RiseV2G 1.2.6 ,
It shows 2000 error and i can not run this awsome project.
Most of errors are xxxx cannot be resolved.
I tried maven dependecies update , but nothing chaged!
I tried command mvn dependency:resolve and agin nothing chaged
Please guide me how to solve this problem
Regard.

How to set network interface?

Hi,
I'm a beginner of this project.
I'm trying to run SECC and EVCC, but it makes fatal error below

2021-01-11T10:18:28,364 FATAL [main] MiscUtils: No network interface for configured network interface index 'eth0' found
2021-01-11T10:18:28,366 FATAL [main] StartSECC: Unable to start SECC because UDP, TCP or TLS server could not be initialized

help me.

Make EXI codec selectable via properties file

The EXI codec has a big impact on the startup time of RiseV2G on embedded devices (OpenEXIcodec is faster than EXIficient). So it would be nice to have a property to select between them.

openjdk11 JAXB

Java 11 has JAXB removed. Therefore compiling with maven throws an error: package javax.xml.bind does not exist.
Adding

<dependency>
  <groupId>javax.xml.bind</groupId>
  <artifactId>jaxb-api</artifactId>
  <version>2.3.1</version>
</dependency>

in <dependencies> solved the issue.
More information can be found here:
https://www.jesperdj.com/2018/09/30/jaxb-on-java-9-10-11-and-beyond/

I did not test for downgrade compatibility

generateCertificates.sh uses a absolute path to openssl

The usage of an absolute path ( /usr/local/Cellar/openssl/1.0.2h_1/bin/ ) to openssl in generateCertificates.sh isn't very portable. It would be better to call openssl directly and let PATH do its job.

'risev2g' Build Failure, while running 'mvn package' command in Raspberrypi Terminal

Hi,
The following error has occurred while running 'mvn package' command:

"Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single (make-my-jar-with-dependencies) on project evcc: Failed to create assembly: Failed to resolve dependencies for project: org.eclipse.risev2g:evcc:jar:1.0.0-SNAPSHOT: Missing:"

Could someone help me regarding this?

Thanks in advace

ChargingForFree property doesn't have any effect

The property ChargingForFree in the file SECCConfig.properties doesn't have any effect. If i set this property to true there is no effect to the ServiceDiscoveryResponse from the SECC.

Error in starting EVCC

As I do not intend to change the source code and do not otherwise use Eclipse or IntelliJ idea, I tried to configure, build and run the project from Linux command line.

Inside RISE-V2G-PARENT, I called mvn compile. When maven complained about missing xml bind modules (I am using openjdk-11), I added the following dependencies in the pom.xml of RISE-V2G-Shared:

  <dependency>
   <groupId>jakarta.xml.bind</groupId>
   <artifactId>jakarta.xml.bind-api</artifactId>
   <version>2.3.2</version>
  </dependency>

  <dependency>
   <groupId>org.glassfish.jaxb</groupId>
   <artifactId>jaxb-runtime</artifactId>
   <version>2.3.2</version>
  </dependency>

This made the compilation go through. I also did mvn package.

Inside RISE-V2G-EVCC, I then did the following:

java -jar rise-v2g-evcc-1.2.6.jar

I get the following error:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/logging/log4j/util/StackLocator$FqcnCallerLocator
 at org.apache.logging.log4j.util.StackLocator.<clinit>(StackLocator.java:37)
 at org.apache.logging.log4j.util.StackLocatorUtil.<clinit>(StackLocatorUtil.java:33)
 at org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:133)
 at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:228)
 at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
 at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
 at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:669)
 at com.v2gclarity.risev2g.shared.utils.ByteUtils.<clinit>(ByteUtils.java:40)
 at com.v2gclarity.risev2g.shared.enumerations.GlobalValues.<clinit>(GlobalValues.java:75)
 at com.v2gclarity.risev2g.evcc.main.StartEVCC.main(StartEVCC.java:33)
Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.util.StackLocator$FqcnCallerLocator
 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
 at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)

I am using Ubuntu 21.04.

Any help/suggestion would be deeply appreciated.

Different EXI streams for message fragments

Hello.

I don't know if this is a problem or maybe I don't understand EXI encoding, but when I try to verify signature for SalesTariffs it fails on two different codecs (e.g. SECC -> Exificient, EVCC -> Open EXI). It also fails when I try to connect RiseV2G_EVCC implementation with own implementation based on OpenV2G. It is also interesting that signature verification works between different codecs, when whole message is signed (e.g. AuthorizationReq). Do you know something about this issue? Thanks for help and for your efforts into 15118 ;)

Isolationlevel should not be set by the session

Hello,

At WaitForCableCheckReq:68 (see: https://github.com/V2GClarity/RISE-V2G/blob/master/RISE-V2G-SECC/src/main/java/com/v2gclarity/risev2g/secc/states/WaitForCableCheckReq.java#L64 ) I believe calling the setIsolationlevel is not correct.

As far as I understand isolation checking should be a subsystem that continuously monitors the isolation state from the CableCheck until the end of the charge process.

I believe calling something like activateIsolationMonitoring() / deactivateIsolationMonitoring() would be more correct. Using this the DummyDCEVSEController count change the isolation level to whatever suits most the simulation.

This would also solve the TODO there: the session should read the current isolation level, and reply a EVSEProcessing = ONGOING as long as it is not VALID.

Also this issie could be solved by notifying the controller about state changes like I proposed in issue #31

NullPointerException in WaitForServiceDiscoveryReq

Using latest RiseV2G as EVSE and a different ISO 15118 implementation as EV i'm able to trigger a NullPointerException in WaitForServiceDiscoveryReq:

2017-07-27T17:02:52,893 DEBUG [ConnectionThread fe80:0:0:0:595e:5080:49ac:ab38%2] V2GCommunicationSessionSECC: New state is WaitForServiceDiscoveryReq
2017-07-27T17:02:52,893 DEBUG [ConnectionThread fe80:0:0:0:595e:5080:49ac:ab38%2] ConnectionHandler: Message received
2017-07-27T17:02:52,910 DEBUG [ConnectionThread fe80:0:0:0:595e:5080:49ac:ab38%2] OpenEXICodec: XML representation of ServiceDiscoveryReq:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns6:V2G_Message xmlns:ns6="urn:iso:15118:2:2013:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:iso:15118:2:2013:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:iso:15118:2:2013:MsgDataTypes" xmlns:ns3="urn:iso:15118:2:2013:MsgHeader"><ns6:Header><ns3:SessionID>E75C624A5F7A76C4</ns3:SessionID></ns6:Header><ns6:Body><ns7:ServiceDiscoveryReq><ns7:ServiceCategory>EVCharging</ns7:ServiceCategory></ns7:ServiceDiscoveryReq></ns6:Body></ns6:V2G_Message>
2017-07-27T17:02:52,911 DEBUG [ConnectionThread fe80:0:0:0:595e:5080:49ac:ab38%2] WaitForServiceDiscoveryReq: ServiceDiscoveryReq received
Exception in thread "ConnectionThread fe80:0:0:0:595e:5080:49ac:ab38%2" java.lang.NullPointerException
	at org.eclipse.risev2g.secc.states.WaitForServiceDiscoveryReq.getServiceList(WaitForServiceDiscoveryReq.java:119)
	at org.eclipse.risev2g.secc.states.WaitForServiceDiscoveryReq.processIncomingMessage(WaitForServiceDiscoveryReq.java:52)
	at org.eclipse.risev2g.secc.session.V2GCommunicationSessionSECC.processIncomingMessage(V2GCommunicationSessionSECC.java:183)
	at org.eclipse.risev2g.secc.session.V2GCommunicationSessionSECC.update(V2GCommunicationSessionSECC.java:161)
	at java.util.Observable.notifyObservers(Observable.java:159)
	at org.eclipse.risev2g.secc.transportLayer.ConnectionHandler.run(ConnectionHandler.java:134)
	at java.lang.Thread.run(Thread.java:748)

According to the code at that place it looks like a mix-up of serviceCategoryFilter and serviceScopeFilter:

if (serviceCategoryFilter != null)
			getLogger().debug("EVCC filters offered services by category: " + serviceScopeFilter.toString());

Since i'm not absolutely sure about the right fix, i created this issue rather than a pull request.

S2755: XML parsers should not be vulnerable to XXE attacks

Hi,

for the fun of it I analyzed the repo with SonarLint and found two interesting blocker issues:
XML parsers should not be vulnerable to XXE attacks (java:S2755)

OpenEXICodec#96
setSaxParserFactory(SAXParserFactory.newInstance());
EXIficientCodec#137
XMLReader xmlReader = XMLReaderFactory.createXMLReader();

I dont understand that much about xml parsing, but it looks like it maybe possible to inject entitys through the parsed xmls. Dont know if that is a use cases which is relevant though.

See https://rules.sonarsource.com/java/RSPEC-2755

SECC replies FAILED_ChargingProfileInvalid in PowerDeliveryRes when there are no ChargingProfile in the request

Hi Marc,

Another issue I found by integrating rise-v2g in my unit test suite ;).
This time it is in the direction where rise-v2g is a SECC, and the EVCC is my own. Still in TCP, EIM and DC mode.

So, for my EVCC that sends a PowerDeliveryReq with ChargeProgress == 'Start' and no ChargingProfile, the SECC replies FAILED_ChargingProfileInvalid, despite ChargingProfile being optional.

This seems to come either from https://github.com/V2GClarity/RISE-V2G/blob/25f3207f36416d9c1726efd254cce6371756b4c6/RISE-V2G-SECC/src/main/java/com/v2gclarity/risev2g/secc/states/WaitForPowerDeliveryReq.java#L136-L137 or https://github.com/V2GClarity/RISE-V2G/blob/25f3207f36416d9c1726efd254cce6371756b4c6/RISE-V2G-SECC/src/main/java/com/v2gclarity/risev2g/secc/states/WaitForPowerDeliveryReq.java#L221.

Cheers,
Axel