Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OPC R4 - OR reference data #45

Open
ERelAlg opened this issue Jun 6, 2023 · 0 comments
Open

OPC R4 - OR reference data #45

ERelAlg opened this issue Jun 6, 2023 · 0 comments

Comments

@ERelAlg
Copy link

ERelAlg commented Jun 6, 2023

Goal:

  • To agree on the content of the header (content of FullModel).
  • Feedback from the Header and Metadata group is needed

Context: messages received

Initial message

I understood the reference data are final. We will not receive on regular basis and we will not include them in the output files generated by OPC Tool. So we basically do not need to process the file with reference data automatically in the application.

We could save the three lists of NamingAuthorities, NameTypes and ObjectTypes to our internal configuration and use it during OR file reception and OR file export. The configuration can be updated when needed (i.e. without the need of new version deployment). So it would be possible to make changes if needed (for example new naming authority).

Would this approach be acceptable for you? Do you see any problem with it?

Answer (ENTSO-E)

Regarding your first point, we agreed that this should be a final version. Regarding term “regular basis” we definitely do not expect such file to be delivered for instance every week or every month but only when new release of OR specification which highly depends on need for development and CIM Experts approval. It should not be included in output files generated by OPC Tool. This is supposed to be an official file (like Boundary set for instance in IGM/CGM creation service) that should be used by different tools in mapping process. Today it is PE OPC Tool, tomorrow it can be STA Tool, CSA Tool or any other so the best would be that all those tools are able to automatically process it.

On the other side I don’t see any obstacles in your proposal to not process it automatically but to have those 3 lists configurable. I’m just not sure if I understood you well - do you propose that we ignore reference data as an input file and define the data that we expect in reference data as dedicated configurable attributers (lists) in PE OPC Tool? Or you say that we should import it once and then make those 3 lists configurable so that in future we do not need to import new version just to reconfigure it?

The whole idea is that we want to reuse the reference data across multiple processes and the alignment process is ongoing, but this should not block OPC project. We do not really have many questions on the CIM expression of the things, but mostly on what the right authority is e.g. ENTSO-E, IEC, UCAIUG or OPC profile for different things which is all mostly instance data alignment.
When implementing the solution in the tool we need to be sure changes of reference data can be done with simple task and not big change requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant