OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ocpp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Meeting Minutes OCA Car Sharing Call

Hi All,

Yesterday was the OCA Car Sharing call to which we also invited the OASIS OCPP TC and Drive Oregon.

Hereby the meeting minutes for who is interested.

Kind regards,
Robert de Leeuw

Hoge Ham 85
5104 JC Dongen

John F. Kennedylaan 3
5555 XC Valkenswaard

T: +31 6 2857 2123
E: robert.de.leeuw@ihomer.nl
Meeting Minutes
OCA Car Sharing Call

Conference Call:

  Ali Imran (Gridscape, OCA)
  Anders Darander (Chargestorm, OCA)
  Christian Lewandowski (KnGrid, OASIS)
  Brendan McMahon (ESB, OCA)
  Jonel Timbergen (Elaad, OCA)
  Jose Rodrigo (AT4 wireless, OCA)
  Lambert Muhlenberg (Alfen, OCA)
  Lonneke Driessen (ELaad, OCA)
  Michel Bayings (EV-Box, OCA)
  Patrick vd Meijs (ELaadNL, OCA)
  Pierre Sacre (Schneider, OCA)
  Reinier Lamers (TheNewMotion, OCA)
  Robert de Leeuw (IHomer, OCA)
  Rolf Bienert (OpenADR, OASIS)
  Sergiu Tcaciuc (Smartlab, OCA)
  Sibo Li (Chargelink, OASIS)
  Zach Henkin (Drive Oregon, guest)

  Current solutions:
  - Card in the Car
  - App on the mobile phone to start stop charging.


  Stay aware of eMI3 use cases on car sharing.
  There is a eMI3 meeting next week. 
  Michel will provide feedback.
  I see 2 types of car sharing: 
  - Renting
  - Sharing in a closed community: 
	- Group of known users (5 to 6 families), sometimes guest users. 
	- Supported with an app. 
	- Diffent 
  I see a 3th type: Company Cars

  2nd case can be solved with the existing ParentId in OCPP.

  Does car sharing have impact on billing?

  Is billing the responsibility of OCPP?

  Proposes to always authorize an RFID card at the server for scenario 1 (renting)
  This way the server can always check if somebody is allowed to start/stop any transsaction.

  This might be a solution, we need to add a field to the authorize.conf telling the charge point to stop/start a specific connector.
  How about off-line scenario's? Somebody rents a car, but cannot stop the transaction, Charge Point is off-line, driver wont be happy.

  Chargelink with a partner is doing tests in the car sharing market: 
  Proposes to Tunnel credentials through OCPP, no matter what the credentials are, the Charge Point should do nothing with them.
  Problem from the field: somebody parking the car but not starting the charging.
  They are testing with a sensor in the parking lot, combined with embedded system in the car and the charger to detect car parked but not charging.
  They have a SIM card in the car for for example location monitoring.

  CarToGo has some kind of check to see if car is parked and charging, if not you will get a penalty.
  App on the mobile phone to open/close car, start stop charging: using the RFID on the phone.

  Are looking into a blend between Company Car Sharing and Community Car Sharing.
  After business hours open for public. 
  Using Honda fit EV
  App to unlock the car. 
  Unlock the cable by unlocking the car.
  Car can charge always charge at a Charge Point, no credentials (RFID) required.

  Locker that detects if the key is back in the car 
  Try to get in contact with CarToGo
  Ask BMW for input
  Kor (Allego) is in contact with BMW. 
  They leave the RFID Card in the EV.

  Lives close to a company that makes most of the boxes used in car sharing projects.
  Has no direct connection to them.

  Rental company could require a vehicle to be returned to it home location.

  We should authenticate the car.

  With 15118 Plug-n-Charge that should be possible.

  Check eMI3: There are no use cases in eMI3, will ask next week.

  Could we create a Group of parentIDs?

  ParentId should be GroupId, more clear, this was proposed for OCPP 2.0
  Problem is that any RFID can only be part of 1 group. 

  By allowing multiple parentIds we can make OCPP more flexible. 

  Allowing a list of groupIds in every token will use up a lot more memory in a Charge Point.
  Think about the Cache and White-lists as well.
  Would this really be used, most likely you will get 1 RFID card for every group.
  Look at the current RFID and SmartCards, they all can be used for more then one service and 
  we still have 1 for every service.
  If you would be using 3 different Car Sharing services, they will all want to give you there own RFID card anyway.
  Group/ParentId is currently almost not used anyway.

  Group/ParentId will be used for Car Sharing.
  Rental Charge Points are not allowed to be used by other cars.
  For now we don't see reasons to extend OCPP for Car Sharing.
  For scenario 1 & 3 the current ParentId/GroupId will work.
  No need to allow more then 1 GroupId.
  Scenario 2: rental, these always need to be returned to rental location.
  Chargers at rental locations will probably not be allowed to be used be non-rental vehicles.
  They have to be available when a rental EV returns. 
  They will most-likely be behind a barrier and allow all EVs that can reach them to charge.
  15118 Plug-n-Charge could be used in the future to allow only certain vehicles to connect.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]