You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Goal:
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.
The text was updated successfully, but these errors were encountered: