Smart Charging OCPP1.6

[KDesai13]

Hello,

We have to implement smart charging using OCPP1.6 for the Delta charger we are going to use. Charger and OCPP1.6 both support smart charging profile. Also have gone through OCPP1.6 manual.

Can anyone guide me whether it is possible to implement and the right direction to go forward?

Does it anything to do with grid connection?

Appreciating your support in this regard.

Thank you.
K Desai

[csamsel]

@JavaIsJavaScript is working on the smart charging part of OCPP. But keep in mind that the interface itself is not smart, adding something smart requires a lot of buisness logic for the specific use case. That is beyond the scope of the SteVe project.

[goekay]

hello, thanks for your interest. the reason why smart charging profile was not implemented can be found in the discussion of #44. but the building blocks are already there. a short summary:

• station -> backend: all OCPP 1.6 operations that can be triggered by the station are implemented. as a matter of fact, there is nothing special regarding smart charging here.
• backend -> station: there are 3 OCPP 1.6 operations left out in the implementation (Get Composite Schedule, Set Charging Profile, Clear Charging Profile). these can be found in the code base here.

i want to illustrate the basic flow of one exemplary operation Trigger Message in codebase, such that you can implement these missing 3 operations in a similar way.

1. the user fills in the web form to trigger the operation. the form is modeled as the class TriggerMessageParams. the call is routed to the controller, which invokes the client.
2. the client reads the values in the TriggerMessageParams model and constructs a TriggerMessageTask. TriggerMessageTask is the place where OCPP request construction and handler logic of the response is implemented (the response handling is async).
3. the client calls the invoker, which depending on the communication configuration of the station (SOAP or JSON over WebSockets) actually invokes the station by executing the next steps in the pipeline.

[chuck-h]

@KDesai13 I also have a Delta charging station (AC Mini) and have tried some Smart Charging tests with @JavaIsJavaScript 's fork. I believe the messages are correct but my GetCompositeSchedule query always gets a "rejected" response from the charging station. I would be happy to cooperate with you on making Delta smart charging work with Steve framework.

[KDesai13]

@KDesai13 I also have a Delta charging station (AC Mini) and have tried some Smart Charging tests with @JavaIsJavaScript 's fork. I believe the messages are correct but my GetCompositeSchedule query always gets a "rejected" response from the charging station. I would be happy to cooperate with you on making Delta smart charging work with Steve framework.

Thank you so much for your details explanation and interest to support.

I have been going through the OCPP1.6 protocol for all the operations and trying to understand GetCompositeSchedule operation initiated by Central System. One of the statement says, "IEC 15118 limits might be taken into account." Have you considered the standard IEC 15118 in account while implementing Smart Charging (GetCompositeSchedule)?

Also need to understand,

1. How exactly the IEC 15118 interact with OCPP in implementing smart charging?
2. Do we really need to implement IEC 15118 for Smart Charging?
3. There are three kinds of smart charging profile purposes:
   a. ChargePointMaxProfile, b. TxDefaultProfile, c. TxProfile
   What I have understood is above profile can be implemented individually without IEC 15118 but if to combine two of them at a time using GetCompositeSchedule needs IEC 15118 to be followed.

Please clarify and explain your point of view.
Thanks.

Sorry by mistake, I closed the issue. Consider it's Open. Thank you.

[chuck-h]

My suggestion is to ignore IEC 15118 unless supporting it is specifically defined as part of your use case.

OCPP1.6 smart charging does not rely on the existence of 15118 communications. A charging station like mine (Delta AC Mini) does not include 15118 power line communication hardware, so it would not even be aware when a 15118-capable vehicle plugs in.

Regarding your point 3., you are mistaken. All three profile purposes may be set in a charge point simultaneously, and section 3.13.3 of the OCPP spec (occp-1.6_edition_2.pdf, 2017-09-28) describes how they interact. There is no role for 15118 required.

My own use case is for "Local Smart Charging" with about 15 stations (in the future). TxDefaultProfile and TxProfile messages will be used before and during charging (sec 5.16.3) in order to ensure that the total load being drawn by the stations is within the available electrical service capacity.

By using OCPP1.6 standard we are hoping to be compatible with a variety of vendors but so far we have only the one Delta AC Mini for testing, and we have not succeeded with the smart charging function yet.

[chuck-h]

I have forked the current Steve and merged in the initial smart charge effort from @JavaIsJavaScript ; repo is at https://github.com/chuck-h/steve. I would be happy to add collaborators or merge pull requests to help this along.

I propose that the Central System (CS), i.e. Steve, will maintain a model of the Charge Point (CP)'s charge profiles/schedules as a transient data structure. This model can be rebuilt from a history of SetChargingProfile and ClearChargingProfile messages. A journal of set/clear profile message data will be retained in the database (somewhat like we retain meter values).

It seems to me that a robust smart charging management program will need to routinely clear the CP schedule and rebuild it, as it is impossible for the CS to read back the full CP profile configuration -- the only readback tool is GetCompositeSchedule.

[csamsel]

Sounds good.
But the interesting part is how to get/create/generate/whatever a "smart" profile. I guess a first step could be either a simple REST API which just receives it (a use case could be receiving it from a home automation system like OpenHAB) or a plain web form.

[goekay]

I propose that the Central System (CS), i.e. Steve, will maintain a model of the Charge Point (CP)'s charge profiles/schedules as a transient data structure. This model can be rebuilt from a history of SetChargingProfile and ClearChargingProfile messages. A journal of set/clear profile message data will be retained in the database (somewhat like we retain meter values).

this is what i was talking about in the other issue.

does anyone have a requirement or use case to integrate the ocpp smart charging with other energy/building/smarthome management systems? or do you simply want to define some profiles and communicate these with stations? if it is the former, i cannot help you. such a tight integration would be domain or use-case specific. if it is the latter, i can look into implementing it. but as i said, it would not be that smart.

[chuck-h]

I just learned about another OCPP smart charging code base, we might find some useful ideas there:
http://files.mgrid-bcit.ca/download/evid.php
This comes from British Columbia Institute of Technology (BCIT) and they call it OpenOCPP ver 1.0.1

[chuck-h]

Comparing Steve's database with BCIT OpenOCPP, I think BCIT's style prefers tables & stored processes to conventional procedural coding. Also they have more detailed business logic.

mysql> show tables;
+-----------------------+
| Tables_in_stevedb     |
+-----------------------+
| address               |
| charge_box            |
| connector             |
| connector_meter_value |
| connector_status      |
| ocpp_tag              |
| reservation           |
| schema_version        |
| settings              |
| transaction           |
| user                  |
+-----------------------+
11 rows in set (0.00 sec)

mysql> show tables;
+----------------------------+
| Tables_in_ocpp             |
+----------------------------+
| affinityGroup              |
| affinityMember             |
| affinityPriceChargepoint   |
| affinityPricePort          |
| authorizationDataList      |
| authorizationLog           |
| authorizationStatus        |
| availabilityStatus         |
| availabilityType           |
| batchJob                   |
| bootNotificationLog        |
| bootStatus                 |
| chargepoint                |
| chargepointAvailability    |
| chargepointConfig          |
| chargepointErrorCode       |
| chargepointMessage         |
| chargepointStatus          |
| chargingProfile            |
| chargingProfileAssigned    |
| chargingProfileKindType    |
| chargingProfilePurposeType |
| chargingRateUnit           |
| chargingSchedulePeriod     |
| compositeSchedule          |
| compositeSchedulePeriod    |
| cookieJar                  |
| country                    |
| cpo                        |
| cpoAccount                 |
| cpoAdmin                   |
| currency                   |
| customer                   |
| customerSupport            |
| emailTemplate              |
| exchangeRate               |
| heartbeatLog               |
| hmiConfig                  |
| idtag                      |
| lastIPAddress              |
| location                   |
| logLevelBit                |
| measurand                  |
| messageTrigger             |
| meterMeterValue            |
| meterReading               |
| ocppServerLog              |
| ocppVersion                |
| outboundRequest            |
| outboundRequestList        |
| outboundResponseLog        |
| payment                    |
| phase                      |
| plugshareAccess            |
| plugshareParking           |
| plugsharePortType          |
| port                       |
| province                   |
| readingContext             |
| recurrencyKindType         |
| registration               |
| requestType                |
| reservation                |
| resetType                  |
| sampleLocation             |
| sampleUnit                 |
| sampledValue               |
| statement                  |
| statementDetail            |
| statusNotificationLog      |
| tcpConnection              |
| terminateReason            |
| ticketDetail               |
| ticketStatus               |
| transactionLog             |
| uidCard                    |
| updateType                 |
| validated                  |
| valueFormat                |
| vehicle                    |
| vehicleType                |
+----------------------------+
81 rows in set (0.00 sec)

[chuck-h]

Tossing out an idea for an energy management system (EMS) app to work thru Steve to perform load management ...

1. EMS is able to read & write stevedb
2. Extend stevedb schema to include smart charging message data (e.g. chargingProfile ... compositeSchedulePeriod tables like OpenOCPP).
3. Extend stevedb schema to represent electrical feeder structure (ref. OCPP 2.0 data types)
4. EMS can read connector_meter_value table to monitor charge point current usage in real time
5. EMS can use electrical feeder structure data to evaluate electrical feeder loads
6. EMS can fill in fresh charging profile data in database when needed to limit feeder loads to managed values
7. Steve transmits updated charging profiles to charge points

[csamsel]

Directly interacting with a database of a different piece of software is a super bad idea. Every communication would have to go through specified API, e.g. as REST interface as i suggested.

[chuck-h]

@csamsel Let's say the EMS communicates with Steve over http in some RESTful fashion. Regarding setChargingProfile, the most minimal implementation would have Steve simply acting as a proxy which relays OCPP charging profile messages from the EMS to the charging stations; Steve would need almost no smartcharging intelligence or database support.

Regarding the database handling, am I right there there are two architectural alternatives --

1. Steve maintains the full database, and the EMS API interactions result in reading and writing it, or
2. The EMS maintains its own operational database, and it replicates information from Steve into it (possibly using some of the same table schema)

[csamsel]

Not sure why you focus on the database aspect. Steve would continue to keep all relevant data locally.

How an external software system like the EMS handles its persistence doesnt really matter for steve.

[chuck-h]

My fork's wiki here:
https://github.com/chuck-h/steve/wiki

All are welcome to comment, especially for issues that stray outside the scope of Steve itself, here:
chuck-h#2

[goekay]

smart charging is not outside the scope of steve. since the use cases were not known to me, i did not implement it until now. and still, no one answered my question above. nevertheless, i will start implementing this feature as follows:

• extend the database schema to store charging profiles and their assignments to connectors (using connector 0 will indicate that the assignment is for the whole station). i do not plan to store a history of all profile assignments (as in connector status values), but only the current one.
• extend the data management section to add/edit/delete profiles (similar to charging station management).
• implement Set and Clear Charging Profile operations by selecting the profile id from the database.
• render the response to Get Charging Profile the same way as in data management section (i.e. detailed view of a charging profile)
• later: expose the CRUD functionalities of profile management as a REST api for integration with smart energy management systems

[chuck-h]

@goekay , I am glad to hear that you are intending to implement some smart charging support features in Steve.

I understand your frustration at finding clear definitions of OCPP smart charging use cases. I would speculate that, as a consensus industry standard, OCPP tries to implement a general capability to satisfy a disparate group of commercial needs; meanwhile the commercial service providers are not completely forthcoming about their specific business plans so the actual use cases they anticipate are not public. Your best bet at getting a broad view of OCPP smart charging use cases might be to contact the Technical Working Group chair at OCPP; I believe that is currently Robert De Leeuw of iHomer.

Meanwhile I am happy to share my very specific local smart charging use case, which is a load manager, and I am developing documentation for that at https://github.com/chuck-h/steve/wiki . Any way we can productively work together on the two software components (Steve and Load Manager) would be great!

I cannot speak for the use cases of @KDesai13 or @V2G-UK, but perhaps they will chime in.

[csamsel]

Thanks for your input @chuck-h

I would think that SteVe is more prevalent in smaller (in number of charging stations) enviroments. Or even in a DIY/home scenario. Therefore i think it would be a good idea to start thinking about smaller use cases like your load manager and less about needs of big companies.

[goekay]

an initial implementation can be found in ocpp-1.6-smart-charging branch. it is not refined at the moment and might be rough around the edges. in this regard, any feedback is welcome.

p.s.: current implementation of GetCompositeSchedule prints only the response status and not the schedule. this is a TODO for the next days.

[chuck-h]

A useful option in the Clear Charging Profile UI would be to send the unfiltered (clear everything) message, which has all fields empty.

[goekay]

ok. implemented in commit d288621.

[chuck-h]

I think the logic enforcing start of validity and start of schedule to be in the future may be undesirable. Did you see this requirement in the OCPP spec? (If so, I missed it.)

[goekay]

Did you see this requirement in the OCPP spec?

no, but i thought that it was implied and made sense. why would it be undesirable? why would you need schedules starting in the past?

[chuck-h]

For starters, it surprised me when I specified start "now" (from date/time interface) and it was rejected because by the time the validation was done that time had passed.
However another use case is a standard daily midnight-based schedule. If you want to update the schedule (e.g. change current setting) during the day, it's convenient to be able to say "here's the new scheduled values, the timing is still based on last midnight".
For schedule validity ranges, I think the implied logic at the charge point is "are we between the start and end values?" so specifying an early start of validity is one way to ensure that the schedule values will become active as soon as received.

[chuck-h]

It looks like you may be overloading the chargingProfileId with the autoincrementing primary key. Not sure this is a great idea as it precludes the end user from assigning profile id's based on some meaningful pattern.

[goekay]

regarding the schedule times: ok. i can remove the 'future' checks of validFrom and startSchedule, but i want to leave it for validTo. i want to prevent that the whole thing is in the past.

regarding the chargingProfileId: i guess there are multiple angles to this. you see it as a preclusion. i wanted to take the burden away from the user to come up with some new value that was not used before. to prevent the confusion i added description, which should be used to add the meaning back (which is your main criticism).

[chuck-h]

Agreed that schedules entirely in the past are almost certainly user errors and should be flagged.

No strong feelings here about the id/pk overloading, it doesn't matter in my own use case. I'll point out that there is no global uniqueness requirement on chargingProfileId so they are semantically a bit different.

[goekay]

No strong feelings here about the id/pk overloading, it doesn't matter in my own use case. I'll point out that there is no global uniqueness requirement on chargingProfileId so they are semantically a bit different.

hmm... if i allow the user to define the chargingProfileId, he/she might reuse the same id for different schedules over time (practically overwriting existing profiles -- tbh, i don't know whether the spec allows this) and after a while it might be problematic to identify what the schedule is or was.

[goekay]

p.s.: current implementation of GetCompositeSchedule prints only the response status and not the schedule. this is a TODO for the next days.

this is done. after commit 8608888 the schedule in the response can be accessed as well.

[chuck-h]

BTW a key element of the load management use case I am working on involves regular updates on current consumption from each charge point. What do you recommend for the mechanism? Should the load manager poll SteVe or can SteVe be configured to post the measured values to the load manager as they arrive from charge points?

[goekay]

well... the solution where steve pushes the information is better. for this, you should extend the methods where we process 1) start transaction, 2) meter values and 3) stop transaction messages. in these messages, we get absolute meter read values with their timestamps. you can calculate meter value deltas between the timestamps for the actual consumption within a time interval.

[goekay]

has anyone found any problems or issues with the basic smart charging implementation? if there is none, i want to merge it with master.

i would admit that it's not the optimal way to implement smart charging without any integration with 3rd party systems (grid operator, energy management system, etc. to react to forecasts, etc.), but it should function as a baseline to implement your specific logic on top.

[zachwang1992]

I have forked the current Steve and merged in the initial smart charge effort from @JavaIsJavaScript ; repo is at https://github.com/chuck-h/steve. I would be happy to add collaborators or merge pull requests to help this along.

I propose that the Central System (CS), i.e. Steve, will maintain a model of the Charge Point (CP)'s charge profiles/schedules as a transient data structure. This model can be rebuilt from a history of SetChargingProfile and ClearChargingProfile messages. A journal of set/clear profile message data will be retained in the database (somewhat like we retain meter values).

It seems to me that a robust smart charging management program will need to routinely clear the CP schedule and rebuild it, as it is impossible for the CS to read back the full CP profile configuration -- the only readback tool is GetCompositeSchedule.

Hello. Thanks for your contribution on this topic. I am studying your code and trying to run it. But when I use the command "mvn package" there are some errors and I cant get the jar file. Have you met a similar problem?

[csamsel]

@zachwang1992 This is not a support thread. Create an issue with a meaningful error description instead.

[chuck-h]

@zachwang1992 , you are probably talking about my fork, which is more error prone than the main i5 project here as I am an amateur at this. If this project (here at https://github.com/RWTH-i5-IDSG/steve) builds for you, but not the fork, you should start an issue on the fork site (which I am migrating to https://github.com/chuck-h/SteVe-SC as a multi-module maven project). @goekay and @csamsel won't be able to help you with fork support, and won't want to hear about it either.

[goekay]

i merged the branch ocpp-1.6-smart-charging into master and therefore consider this issue resolved.

[garima8]

Actually, I had some doubts regarding OCPP 1.6.
I am working on building a CSMS for a charging point/charging station and I want to get some of the energy values(electric current, power, time left to 100% charging, and stateofCharge) from the charging point about the electric vehicle.
In OCPP 2.0 I found a parameter namely, NotifyEVChargingNeeds, which satisfies all my needs from OCPP1.6.
Is there any way I could get these values by using OCPP 1.6?
If yes then what can it be?

[LydiaBenaida]

Hello everyone, thank you for this great work ,
I'm trying to add smart chrging automatic functionnality based on calculated charging profile ,
It doen't work properly , i will be grateful if we can discuss my code

public StartTransactionResponse startTransaction(StartTransactionRequest parameters, String chargeBoxIdentity) {

         IdTagInfo info = ocppTagService.getIdTagInfo(
                 parameters.getIdTag(),
                 true,
                 () -> new IdTagInfo().withStatus(AuthorizationStatus.INVALID) // IdTagInfo is required
         );

         InsertTransactionParams params =
                 InsertTransactionParams.builder()
                         .chargeBoxId(chargeBoxIdentity)
                         .connectorId(parameters.getConnectorId())
                         .idTag(parameters.getIdTag())
                         .startTimestamp(parameters.getTimestamp())
                         .startMeterValue(Integer.toString(parameters.getMeterStart()))
                         .reservationId(parameters.getReservationId())
                         .eventTimestamp(DateTime.now())
                         .build();

         int transactionId = ocppServerRepository.insertTransaction(params);

         applicationEventPublisher.publishEvent(new OcppTransactionStarted(transactionId, params));
         //------- set the  profiles-------
         startSetProfiles(chargeBoxIdentity);
         //--------------------------------
         return new StartTransactionResponse()
                 .withIdTagInfo(info)
                 .withTransactionId(transactionId);

 }

 public void startSetProfiles(String chargeBoxIdentity) {
     int count = smartCharging.countActiveChargeBoxOnPhase(chargeBoxIdentity);
     int profileCode = smartCharging.getProfileOfPdl(chargeBoxIdentity,count);
     int chargingProfilePk = smartCharging.getChargingProfilePK(profileCode, "TRANSACTION");
     List<ChargeBoxInfo> chargeBoxInfo = smartCharging.getChargeBoxInfoList();
     // --------- clear old profiles --------------
    stopSetProfiles(chargeBoxIdentity);
     //---------------------------------------------
     for (ChargeBoxInfo chargeBox : chargeBoxInfo) {
         // --------------- Params -----------------
         List<ChargePointSelect> chargePointSelectList = new ArrayList<>();
         ChargePointSelect chargePointSelect = new ChargePointSelect(OcppTransport.JSON, chargeBox.getChargeBoxId());
         chargePointSelectList.add(chargePointSelect);
         // ------------- Set Params ---------------
         SetChargingProfileParams setParams = new SetChargingProfileParams();
         setParams.setChargingProfilePk(chargingProfilePk);
         setParams.setConnectorId(Integer.valueOf(chargeBox.getConnector_id()));
         setParams.setChargePointSelectList(chargePointSelectList);
         //---------------Set Profile---------------
         client16.setChargingProfile(setParams);
     }
 }
 private void stopSetProfiles(String chargeBoxIdentity) {
     smartCharging.countActiveChargeBoxOnPhase(chargeBoxIdentity);
     List<ChargeBoxInfo> chargeBoxInfo = smartCharging.getChargeBoxInfoList();
     //-------------- clear the old profiles-------
     for (ChargeBoxInfo chargeBox : chargeBoxInfo) {

         int chargingProfilePK = chargingProfileImpl.getCurrentFromChargeBoxInfo(chargeBox,"TxProfile");
         // --------------- Params -----------------
         if(chargingProfilePK>0) {
             List<ChargePointSelect> chargePointSelectList = new ArrayList<>();
             ChargePointSelect chargePointSelect = new ChargePointSelect(OcppTransport.JSON, chargeBox.getChargeBoxId());
             chargePointSelectList.add(chargePointSelect);
             // ------------- Set Params ---------------
             ClearChargingProfileParams clearParams = new ClearChargingProfileParams();
             clearParams.setChargingProfilePk(chargingProfilePK);
             clearParams.setConnectorId(Integer.valueOf(chargeBox.getConnector_id()));
             clearParams.setChargePointSelectList(chargePointSelectList);
             clearParams.setChargingProfilePurpose(ChargingProfilePurposeType.TX_PROFILE);
             //---------------Set Profile---------------
             client16.clearChargingProfile(clearParams);
         }
     }
 }
 public StopTransactionResponse stopTransaction(StopTransactionRequest parameters, String chargeBoxIdentity) {
     //--------clear all profile on the station and phase of our charge box stopped
    stopSetProfiles(chargeBoxIdentity);
     //-------------------------------------------
     int transactionId = parameters.getTransactionId();
     String stopReason = parameters.isSetReason() ? parameters.getReason().value() : null;

     // Get the authorization info of the user, before making tx changes (will affectAuthorizationStatus)
     IdTagInfo idTagInfo = ocppTagService.getIdTagInfo(
             parameters.getIdTag(),
             false,
             () -> null
     );

     UpdateTransactionParams params =
             UpdateTransactionParams.builder()
                     .chargeBoxId(chargeBoxIdentity)
                     .transactionId(transactionId)
                     .stopTimestamp(parameters.getTimestamp())
                     .stopMeterValue(Integer.toString(parameters.getMeterStop()))
                     .stopReason(stopReason)
                     .eventTimestamp(DateTime.now())
                     .eventActor(TransactionStopEventActor.station)
                     .build();

     ocppServerRepository.updateTransaction(params);

     ocppServerRepository.insertMeterValues(chargeBoxIdentity, parameters.getTransactionData(), transactionId);

     applicationEventPublisher.publishEvent(new OcppTransactionEnded(params));
     //------Re-start the new profiles
    startSetProfiles(chargeBoxIdentity);
     //--------------------------------
     return new StopTransactionResponse().withIdTagInfo(idTagInfo);
 }