1)      Header URI should be agreed upon.

-          Version classes in the profile contain URIs.

-          For the IOP we will use ENTSO-E URIs. The reason to have ENTSO-E URI is to be able to distinguish what is pure IEC standard and what has ENTSO-E extensions. The reason to have baseURI in the Version class is to indicate the closest IEC profile.  

This is part of the process to first work out some extensions which are coming fast to the ENTSO-E set of profiles if compared with IEC process to standardise the profiles. Network Codes process may bring already some extensions in Sep-Oct and there will be some time until these extensions become IEC standard. In the meantime all this can be used in ENTSO-E exchanges.

2)      Validation tool: Which tool will we use during the IOP to validate the files?

-          CIMdesk/CIMSpy if ready for the IOP. Initial planning is to have first version by 24 June

-          If not vendors own validations

3)      Boundary file: As the UUID rules changed (lower case only, dashes,…) & UUIDs in general

-          OSG can update the test to use the new rules

-          DIgSILENT has also boundary file for the small model

-          In order to allow different styles of the rdfid in the data exchanges, the ENTSO-E standard will define that the rdf is treated as a text. In this way tools and TSOs have maximum flexibility. The issue is outside the scope of the IOP. Vendors are OK that the 2 styles for rdfid are present in the test models used in the IOP.  

4)      EQ/SSH/TP/SV: Which solution will we test during the IOP?

-          The reason to have SSH is to be able to exchange non-solved model and update the input to the load flow without using difference exchange (which can be used for other purposes).

-          For the IOP both EQ and SSH profiles will be exchanged in one instance file. Therefore the file header will need to refer to the URIs of the 2 profiles

-          This decision is only taken in order to

o   Be able to test HVDC and dynamics

o   Be able to demonstrate that necessary attributes needed to run load flow are present in the SSH profile

-          It is very important to discuss what the best solution for SSH is. This discussion will be arranged during the IOP where workshop session will be organized.

-          The discussion in the IOP should try to find a way to construct SSH so that future changes on the EQ have less impact of the SSH i.e. implementation effort is minimized. Depending of the outcome of the solution there are 2 possibilities:

o   1) the solution can be easily applied to the profile or the way of the exchange is performed and does not require an IOP to validate this. If this is the case ENTSO-E will adapt and process with the approval procedure

o   2) the solution is complex and will require IOP session in order to be fined tuned and validated. If this is the case, all action (including a light IOP) should be completed by the end of Oct 2013 and ENTSO-E approval process should be triggered afterwards.  

5)      ConnectivityNodes vs. TopologicalNodes. Which approach do we test during the IOP?

-          Test models will include ConnectivityNodes for node-breaker models.

-          It is valuable to test exchange of pure EQ of node-breaker models. ABB/Ventyx will have an issue to provide (for the IOP) EQ in which all generation/load are declared. Perhaps some of the other vendors can provide this.

-          Additional discussion will be arranged in the workshop session during the IOP

6)       IOP workshop

-          Part of the IOP will be organized as workshop. WG13 members will also be invited. Web conference facilities should be available.

-          The workshop discussions should aim at actually resolving IOP issues and prepare the package for ENTSO-E approval.