Documentation icon indicating copy to clipboard operation
Documentation copied to clipboard

Question : Support for DLMS/COSEM Protocol

Open SAM200086 opened this issue 1 year ago • 2 comments

Question: Does GXF currently support the full DLMS/COSEM protocol, or is it limited to only IEC 62056-21, as indicated by the use of the OpenMUC jDLMS library? Specifically, what features of DLMS/COSEM are supported beyond IEC 62056-21 in GXF platform?

background: I noticed that the GXF documentation mentions support for DLMS/COSEM using the OpenMUC jDLMS library. However, according to the OpenMUC documentation, this library primarily supports IEC 62056-21. I am interested in understanding the extent of DLMS/COSEM functionality currently supported by GXF.

Thank you for your assistance!

SAM200086 avatar Aug 30 '24 09:08 SAM200086

Hello Sam,

Thank you for your question.

The jDLMS library also supports DLMS/COSEM communication via TCP/IP. This is also supported by GXF. GXF doesn't support IEC62056-21.

I hope this answers your question. Please let us know if you have more questions.

Best regards, Stefan.

stefanermens avatar Aug 30 '24 11:08 stefanermens

Dear Stefan,

Thank you for your prompt response and for clarifying the support for DLMS/COSEM via TCP/IP in GXF. Your insights have been very helpful.

I am currently in the process of developing an Advanced Metering Infrastructure (AMI) remote metering system, targeting various application scenarios including energy, power systems, smart cities, and water management. I am very interested in the GXF open-source project and would like to learn more about its practical applications:

  1. Has GXF been deployed in many real AMI smart meter projects? and can you tell me related AMI projects' informations?
  2. How many smart meters are connected in the largest of the AMI projects using GXF?

In the first phase of my AMI remote metering system, I plan to integrate DLMS/COSEM smart meters and require the following features. Could you please let me know if GXF supports these functionalities:

  1. Multi-tenant management
  2. Multi-level user management
  3. A flexible device management architecture that supports grouping and hierarchical management of current and future multi-level IoT devices
  4. DLMS/COSEM smart meters proactively push data and events
  5. Role and permission management
  6. Real-time monitoring dashboards
  7. Logging 7.1 Monitoring communication information and recording it 7.2 Count the consumption data traffic for each device 7.3 Daily monitoring information reports
  8. Containerized deployment using Docker for easy deployment and scalability. It should allow quick deployment to other cloud servers.
  9. Ability to run the core code on a Raspberry Pi, which could serve as an edge gateway
  10. Performance requirements 10.1 The cloud server can achieve second-level real-time performance

Lastly, I plan to deploy GXF on a cloud server to understand it. While I understand that Ubuntu is the recommended operating system, I have already rented a CentOS 9 cloud server. Could you please advise if I can deploy GXF on CentOS 9, or would you recommend switching to Ubuntu?

Thank you again for your assistance. I look forward to your guidance on these questions.

Best regards, Sam

On Fri, Aug 30, 2024 at 7:38 PM Stefan Ermens @.***> wrote:

Hello Sam,

Thank you for your question.

The jDLMS library also supports DLMS/COSEM communication via TCP/IP. This is also supported by GXF. GXF doesn't support IEC62056-21.

I hope this answers your question. Please let us know if you have more questions.

Best regards, Stefan.

— Reply to this email directly, view it on GitHub https://github.com/OSGP/Documentation/issues/292#issuecomment-2320948852, or unsubscribe https://github.com/notifications/unsubscribe-auth/BEJFCQPDMQDUGKRVCDYDPTLZUBKSDAVCNFSM6AAAAABNMEGYYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRQHE2DQOBVGI . You are receiving this because you authored the thread.Message ID: @.***>

SAM200086 avatar Aug 31 '24 09:08 SAM200086

Dear Sam,

Sorry that the answers to your questions took a little bit longer, but here they are!

Before answering the underlying questions is detail, it’s important to explain a little about the architecture of GXF and our Smart Meter Head-End (SMHE) application. Where GXF is the Open Source project, the SMHE application is a Closed Source project. Where GXF is a generic communication platform for several use-cases for several domains, is SMHE the application that enables the Smart Metering functionality within GXF. SMHE in addition has specific Smart Metering functionality that is not part of GXF as it is to specific this purpose.

First the answers to the practical questions:

  1. Currently GXF has been deployed only for the real AMI smart meter project of Alliander, but we are in the discussion with the other DSO’s in the Netherlands to promote GXF as Platform for all Smart Meters in the Netherlands for all Smart Meters currently deployed.
  2. For Alliander there are currently 6.000.000 Smart meters connected and this will lead up to 15 million meter reads per 24 hours.

The answer of the questions about specific functionality:

  1. Multi-tenant management – Yes, based on organization based separation. There needs to be some rework in order to reinstate the functionality
  2. Multi-level user management – Yes, based on organization based separation and role based security. User and role management should be handled inside the application on top of GXF.
  3. A flexible device management architecture that supports grouping and hierarchical management of current and future multi-level IoT devices – Yes, but not part of GXF. This is part of the SMHE functionality. This is part of the gateway functionality.
  4. DLMS/COSEM smart meters proactively push data and events – This is supported, but we only use this in the Netherlands for alarms.
  5. Role and permission management – Yes, but currently only 3 roles are available within GXF (read-only, user and administrator). Within SMHE this is a lot more flexible and this can be configured.
  6. Real-time monitoring dashboards – Yes, but not part of GXF. This is available as part of the SMHE deployments and infrastructure
  7. Logging – Yes, lots of logging available. a. Monitoring communication information and recording it – GXF can record debug information from and to the device. b. Count the consumption data traffic for each device – No, not implemented in GXF c. Daily monitoring information reports – Monitoring dashboards in infrastructure. Not part of GXF.
  8. Containerized deployment using Docker for easy deployment and scalability. It should allow quick deployment to other cloud servers – Yes, everything is deployed using OpenShift. The scripts to do this are currently not available for the Open Source implementation.
  9. Ability to run the core code on a Raspberry Pi, which could serve as an edge gateway – Not tested.
  10. Performance requirements a. The cloud server can achieve second-level real-time performance – This is possible, but we use SMHE in combination with relatively slow mobile telecom connections. It’s is more important to serve a large number of meters instead of high performance.

This is dependency with Ubuntu, it will be no problem to deploy it on CentOS 9. We used to deploy our solution also on CentOS, but since we moved to Kubernetes deployments we also moved to Alpine as Operating System.

I hope this will give you the information you are looking for. If you have any more questions, please let us know!

Best regards, Robert

rtusveld avatar Sep 17 '24 11:09 rtusveld

Dear Robert,

Thank you very much for the detailed answers to my questions regarding the GXF and SMHE architecture. I really appreciate the thoroughness of your response, especially considering the time it took.

I apologize for my delayed reply. Your explanations have clarified a lot, and I now have a much better understanding of how the GXF platform and SMHE application function together, as well as the specific functionalities related to multi-tenant management, real-time monitoring, and deployment options.

Based on your insights, I believe we can now close the topic on GitHub. Should any additional questions arise in the future, I won’t hesitate to reach out.

Thanks again for your assistance!

Best regards, Sam

On Tue, Sep 17, 2024 at 6:44 AM Robert Tusveld @.***> wrote:

Dear Sam,

Sorry that the answers to your questions took a little bit longer, but here they are!

Before answering the underlying questions is detail, it’s important to explain a little about the architecture of GXF and our Smart Meter Head-End (SMHE) application. Where GXF is the Open Source project, the SMHE application is a Closed Source project. Where GXF is a generic communication platform for several use-cases for several domains, is SMHE the application that enables the Smart Metering functionality within GXF. SMHE in addition has specific Smart Metering functionality that is not part of GXF as it is to specific this purpose.

First the answers to the practical questions:

  1. Currently GXF has been deployed only for the real AMI smart meter project of Alliander, but we are in the discussion with the other DSO’s in the Netherlands to promote GXF as Platform for all Smart Meters in the Netherlands for all Smart Meters currently deployed.
  2. For Alliander there are currently 6.000.000 Smart meters connected and this will lead up to 15 million meter reads per 24 hours.

The answer of the questions about specific functionality:

  1. Multi-tenant management – Yes, based on organization based separation. There needs to be some rework in order to reinstate the functionality
  2. Multi-level user management – Yes, based on organization based separation and role based security. User and role management should be handled inside the application on top of GXF.
  3. A flexible device management architecture that supports grouping and hierarchical management of current and future multi-level IoT devices – Yes, but not part of GXF. This is part of the SMHE functionality. This is part of the gateway functionality.
  4. DLMS/COSEM smart meters proactively push data and events – This is supported, but we only use this in the Netherlands for alarms.
  5. Role and permission management – Yes, but currently only 3 roles are available within GXF (read-only, user and administrator). Within SMHE this is a lot more flexible and this can be configured.
  6. Real-time monitoring dashboards – Yes, but not part of GXF. This is available as part of the SMHE deployments and infrastructure
  7. Logging – Yes, lots of logging available. a. Monitoring communication information and recording it – GXF can record debug information from and to the device. b. Count the consumption data traffic for each device – No, not implemented in GXF c. Daily monitoring information reports – Monitoring dashboards in infrastructure. Not part of GXF.
  8. Containerized deployment using Docker for easy deployment and scalability. It should allow quick deployment to other cloud servers – Yes, everything is deployed using OpenShift. The scripts to do this are currently not available for the Open Source implementation.
  9. Ability to run the core code on a Raspberry Pi, which could serve as an edge gateway – Not tested.
  10. Performance requirements a. The cloud server can achieve second-level real-time performance – This is possible, but we use SMHE in combination with relatively slow mobile telecom connections. It’s is more important to serve a large number of meters instead of high performance.

This is dependency with Ubuntu, it will be no problem to deploy it on CentOS 9. We used to deploy our solution also on CentOS, but since we moved to Kubernetes deployments we also moved to Alpine as Operating System.

I hope this will give you the information you are looking for. If you have any more questions, please let us know!

Best regards, Robert

— Reply to this email directly, view it on GitHub https://github.com/OSGP/Documentation/issues/292#issuecomment-2355466090, or unsubscribe https://github.com/notifications/unsubscribe-auth/BEJFCQOFFJKFV3ICT7YJKP3ZXAIYLAVCNFSM6AAAAABNMEGYYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVGQ3DMMBZGA . You are receiving this because you authored the thread.Message ID: @.***>

SAM200086 avatar Sep 23 '24 14:09 SAM200086