Proposal to add a model for a EV charger - and - EV Charging Station/Hub

[WesVerhagen]

Is it a possibility to add EV Charger and EV Charging Station/Hub models to the ontology?

I think we need three models:

• Model 1
  Electric Vechical Charger - or - EV Charger (that is a an extention of a "Equipment" model)

properties
Power Rating: Specify the power rating of the charging equipment, which indicates the maximum power it can deliver to charge an electric vehicle. This property helps users understand the charging speed and compatibility with different vehicle types.

Connector Type: Define the type of connector used by the charging equipment, such as Type 1 (SAE J1772), Type 2 (IEC 62196), CHAdeMO, CCS (Combined Charging System), Tesla Supercharger, etc. This property helps identify the physical connection required between the vehicle and the charging equipment.

Communication Protocol: Specify the communication protocol used by the charging equipment to exchange information with the electric vehicle, such as OCPP (Open Charge Point Protocol). This property helps enable interoperability and integration with EV management systems.

Supported Charging Methods: This property specifies the different charging methods supported by the equipment. In addition to AC and DC charging, there are various charging methods that can be considered. Some examples include:
Fast Charging: This refers to high-power charging methods that enable faster charging times compared to regular charging. It typically involves higher voltage and current levels to deliver a significant amount of energy to the electric vehicle in a shorter duration. options are Slow Charging, Smart Charging, Bidirectional Charging and Wireless Charging.

• Model 2
  Electric Vechical Charger Status - or - EV Charger Status (that is a an extention of a "Status" model)

• Model 3
  Electric Vechical Charging Hub - or - EV Charger Hub - or - Electric Vechical Charging Station - or - EV Charger Station (that is a an extention of a "Collection" model)

[epaulson]

Yeah, I think we are certainly interested in having EV Chargers in the ontology.

For the hub, is that something more like a parking lot full of charging stations, or a single charging station that might have multiple cables coming off of it?

[WesVerhagen]

Hi Erik,
Thanks for the response! First off, I forgot to add that I asked this question in the Gitter room for REC and was talking to Gabe Fierro about our problem.

To come back to your comment:
Some of our customers can measure separate ports, but most of our customers have one submeter for all the chargers in the parking lot. So the usual data we collect is the total power and energy consumption for all the chargers, but sometimes we can collect data per port. Nevertheless, I think there needs to be an option to specify if there is a charger with multiple ports.

I have talked to my team about it, and we think that there needs to be an extra model. So the new situation is:

• Hub: This is a parking lot full of chargers (similar to a collection like the PV array).
• Charging Pedestal: This is a station that can have multiple ports.
• Charging Port: Referring to individual ports on the charging pedestal.
• Status of Charging Ports: This describes the status of the individual charging ports.

I hope this helps! Let me know if you have any further questions.

[gtfierro]

Hi @WesVerhagen -- thanks for taking the time to file an issue!

Would a possible model for composition be as follows?:

• Hub would be a collection; might be located in a parking lot
• Hub can has part instances of Charging Pedestal (would a Pedestal also be considered a "charging station", or the latter less specific?)
• Charging Pedestal would has part instances of Charging Port
• Charging Port would has point different classes. What kinds of data streams do you typically have on chargers? I think Brick may already have some 'battery charging' point classes, so I would take a peek there

[epaulson]

The Haystack folks have a start on some EV work too. I'm certainly not wedded to their choice of names but if we can keep a simple translation between things that'd be ideal - https://project-haystack.org/doc/docHaystack/EVSE

[WesVerhagen]

Hi @gtfierro,

I hope you had a nice weekend! I appreciate your explanation, and I think it is a good approach.

After considering your input, I agree that using the term Charging station instead of Charging pedestal is more appropriate. This broader term allows for the inclusion of different types of charging infrastructure, such as charging boxes or other variations.

Regarding the data points for the charging port, I believe most of them are already covered in the existing ontology. However, one data point that seems to be missing is the battery percentage of the electric vehicle. I believe this can be represented as a sensor reading that indicates the current charge level of the vehicle's battery. Please correct me if I'm wrong or if there's a more suitable way to represent this data point.

Thank you again for your explanation, and I look forward to your further guidance.

[WesVerhagen]

Hi @epaulson,

I've taken a look at the Haystack documentation, and I appreciate the insights they provide regarding measuring the state of the battery. However, I must agree with you that their choice of naming doesn't quite align with my preferences. The term "assembly" doesn't seem to be the most suitable name for the concept we are trying to represent.

Additionally, I have a concern about their approach to multiple cables connected to a single port. While it is true that a charging station can support simultaneous or sequential charging, I believe that distinction should be associated with the port rather than the cable. In most cases, the cable is either part of the car or part of the charger, and the values associated with the port remain the same regardless.

Considering this, I'm unsure if including the concept of a cable in the model would be necessary or beneficial. It may be more appropriate to focus on accurately representing the port and its associated properties.

Thank you for bringing the Haystack documentation to my attention, and I value your insights on this matter.

[WesVerhagen]

Hi @gtfierro,

I hope you're doing well. I just wanted to follow up on my previous message regarding the EV charging equipment model. I'm not sure if you had a chance to read it, and I wanted to check if you had any additional thoughts or feedback on the proposed approach.

To recap, we discussed the usage of the term "Charging station" instead of "Charging pedestal" to encompass various types of charging infrastructure. I found that suggestion to be more suitable, considering the diverse range of charging options available.

We also touched upon the data points for the charging port, with the exception of the battery percentage of the electric vehicle. I proposed representing this as a sensor reading indicating the current charge level of the vehicle's battery. If there's a better or more appropriate way to represent this information, I would greatly appreciate your insights.

Please let me know if there's anything else you'd like to discuss or if you require any further assistance. I value your expertise and guidance in refining the EV charging equipment model.

Thank you for your time, and I look forward to hearing from you.

Best regards,
Wes Verhagen

[gtfierro]

Hi @WesVerhagen thanks for following up! I've been busy with travel all of June (currently in the airport again as I'm writing this) so I've been behind on everything. I can get to this next week, if that works for you? Maybe I can turn it out earlier amidst some late-night hacking too

[gtfierro]

Thanks for your patience! I had some time to draft up a PR: #529 . Let me know what you think is missing/wrong. In particular, let me know what the enumerated values should be on the chargers / ports, and if those properties are on the right kind of equipment

[WesVerhagen]

Hi @gtfierro,

Thank you so much for your effort in drafting up PR #529. I really appreciate your dedication and contributions to the project. I'll make sure to review it thoroughly and provide feedback as needed.

Regarding the enumerated values for the chargers/ports properties, I'll ensure that we select appropriate values that align with the equipment's specifications. If anything is missing or needs adjustment, I'll be sure to address it in the feedback.

I'll be taking a few days to carefully go through the changes you've made and compare them with the project's requirements. This way, I can provide you with a comprehensive and detailed response.

Once again, thank you for your valuable input, and I'll get back to you soon with my review. Your dedication to the project is truly commendable!

[WesVerhagen]

Hi @gtfierro ,

I have left a comment on the PR regarding some of the improvements, but I have an additional challenge that I'd like to discuss. I'm not entirely sure if this is the right location to bring it up, but it's an essential aspect that I've encountered.

The challenge I'm facing is related to the use of DTDL (Digital Twin Definition Language). Specifically, the REC and REC equipment models don't seem to have the following properties:

https://brickschema.org/schema/Brick#currentFlowType
https://brickschema.org/schema/Brick#powerFlow
https://brickschema.org/schema/Brick#electricalPhaseCount

Without these properties, I'm unable to add crucial information such as AC/DC charging, electrical phase count, and power flow direction. These details are vital for properly representing and utilizing electric vehicle charging equipment in the model.

Moreover, having the "powerFlow" property would not only benefit EV charging scenarios but could also be useful for various other applications.

I'm seeking guidance on how to proceed in such a situation. Should I propose an extension to the REC model or explore other alternatives? Your insights and suggestions would be greatly appreciated.

Thank you for your time and support in resolving this matter.

Best regards,
Wes Verhagen