Challenges Within the Existing IEDs and System

that have considered commercial IEDs for designed laboratory platforms and commercial software configuration tools. Therefore, in order to reduce costs, ef-fort and the time taken, a novel approach for a new proposed SAS configuration tool is adopted. The novel configuration tool is independent of any commercial IED brand. It has the ability to import SCL files from different vendors, IEDs, systems and databases, creating and increasing the relay configuration to the system level based on the proposed full IEC 61850 standard, including the pro-tection and feature setting levels. Moreover, it can separate the SAS configuration tasks between various SAS engineer groups. For instance, the protection engineer is able to focus for the design and implementation of the protection scheme ra-ther than the underlying communications infrastructure.

3.2.2 Challenges Within the Existing IEDs and System Configuration Tool

The IEC 61850 standard assigns several SCL files to describe the SAS’s aspects.

Each IED within the SAS has the ability to generate the SCL files with different extinction to describe its capabilities and to define itself relative to the system

configuration tool. According to the existing SAS configuration process, the SCL files need to be created by a proprietary IED configuration tool or else are provid-ed by the vendors. In order to configure the entire SAS, all the SCL files for the various manufacturers’ IEDs have to be imported to one of the available system configuration tools as chosen by any the IED manufacturers participating in the SAS project, as illustrated in Figure 69.

Figure 69. The existing SAS configuration process.

However, these imported SCL files have to be updated constantly during the sys-tem configuration process to a final configuration containing the protection set-tings parameters as well as the final communications setset-tings. It was considered that, during the importing process, an error report might be produced by the IEC 61850 validator tool such that some of the created SCL files would have some format errors based upon the ambiguity explained earlier, and as illustrated in Figure 70. These errors were the first hurdle that had to be resolved.

Figure 70. An SCL files Validator Tool error report.

Even if the final system configuration is established, in some cases there will still be a chance that the configured IEDs will not be able to receive the GOOSE mes-sages that they were configured to subscribe to. The reason for this is that the GOOSE messages’ description is different to what was actually described in the imported SCL files. In addition, based on the different vendors’ system configura-tion tools, in some cases the system configuraconfigura-tion tool will not show all the GOOSE parameters for the publisher and subscriber to match between them-selves. Moreover, in some other cases the system configuration tool may not offer the modification of the GOOSE parameters (offering it only for the native IED within the SAS). In order to analyse the problem, it is necessary to use a network analyser tool (Wireshark, Ethereal, IEDScout, etc.) that has the ability to detect the network traffic based on the specific protocol. It must display the entire GOOSE structure so that a view of the specific relay GOOSE parameters can be analysed and so that the GOOSE messages can be subscribed to manually – for example, within the Vamp relays, GOOSE parameters can be entered manually based on the Vampset configuration tool.

The next step of the existing SAS configuration process is to export the final SCL file that contains all the system configuration parameters to the different proprie-tary IED configuration tools. Each proprieproprie-tary IED configuration tool needs to update its native IEDs based upon the final system SCL file (associated with GOOSE). The reason for this is that each manufacturer has a proprietary way of linking the configuration tool with their IEDs. Moreover, they have a proprietary file format to describe their features and settings.

At the time of publishing of this thesis, interoperability has not yet reached this level (i.e., the parameter settings level). Furthermore, such proprietary parameter settings’ file formats and specific means of communicating between IEDs and

vendor software tool booths underlie vendors’ business strategies, such that they prefer to keep a particular setting file format and they may also look to develop their own products without being constrained by the restrictions of the standard.

Another crucial issue within the system configuration process is the need to buy and install all the different manufacturers’ software configuration tools and then jump from the proprietary IED configuration tools to the system configuration tool, and vice versa. In relation to this task, in some cases, it may be necessary to make backup files for the project before proceeding through the system configu-ration process because, if any fault within the system configuconfigu-ration occurs, re-turning to the previous configuration will not be available.

According to the previous overview of the existing SAS configuration process and the associated crucial issues deriving from the proposed full IEC 61850 standard (all the levels are standardized, including the parameter settings level), the exist-ing SAS configuration methodology needs to be modified. The modification can be achieved by using a novel, vendor-neutral configuration tool.