Embed Size (px)
Citation preview
P011: Challenges of Modern Settings Management facing Relay Manufacturers, Power Utilities, Settings Management Specialists and Power
System Calculation Software Vendors
Hugh Borland, Daryl Coleman, Dr.Zeljko Schreiner and Adam Middleton, MIET, MIEEE, CIGRE
Email: [email protected]; adam,[email protected]
Ireland / USA/ UK / Germany
1. Introduction
Historical development of protective relay technology, deregulation and restructuring of the power
utilities has brought a set of entirely new requirements upon relay settings management. Parameter
quantity has increased from 10 – 20 Parameters per relay up to several hundreds and hence migrated
to even several thousands of parameters per individual multifunctional protection, control and
automation device (or IED – Intelligent Electronic Device). The current situation in which leading
electrical power utilities find themselves is framed by the existence of digital protective devices.
Further, the existence of a multitude of manufacturer setting software programs, numerous file
formats, database structures and the like makes control of critical protection and automation
information very difficult. Such complexity is taken extremely seriously by utilities, especially in the
context of recent network interruptions.
A significant number of electrical power utilities have become deregulated in the past 10-20 years and
are faced with the operational challenges of conflicting interdepartmental or even inter-company
processes. Specifically in larger power system corporations, protection and automation settings
management is typically influenced by several functions, groups or divisions within that organization.
These can include Network Planning, Engineering, System Analysis, Asset Management, Operations
and Site Services (maintenance and commissioning). Personal reductions in all segments of the
power utilities influenced as well area connected with setting management. This becomes additional
reason of optimization of the entire process.
Financial, political and environmental pressure on power utilities is putting high importance on network
stability requirements without having the historic levels of spare capacity or back up. As a result, the
quality of the protective relay and automation equipment settings becomes very significant.
This paper will describe requirements for the entire process of protection and automation settings
management in order to ensure highest possible efficiency, safety and quality of the relay settings
information – and hence the electrical power network The authors will take current experience from
each of the primary stakeholders (utilities, protection and automation product and system
manufacturers, test and maintenance system specialists, protection engineering software specialists)
in proposing an integrated, practical strategy and implementation to address each of the critical
drivers identified.
Today, electrical power utilities and major industrial users have to face an ever-increasing variation in
the approaches proposed by each of the main protection and automation manufacturers, related to
their corresponding relay / automation product software correlated with different profiles of each
individual user. Such increasing variability will be used by the authors to explain the need for a
“manufacturer neutral format” for managing and keeping critical relay settings. Further, the paper will
explore the concept and potential structure for an appropriate Worldwide standard for relay settings
and the related relay setting exchange process.
Understanding of the needs of electrical power utilities regarding modern processes of protection and
automation setting live cycle management will result in additional requirements in respect of “Cyber
Security”, critical setting management workflows, work organization and setting data management
software.
The authors will present proposals around process optimization for relay manufacturers which will
allow more efficient and robust data management in respect of the optimization of the data exchange
between relay software and relay setting database management systems.
Finally, the paper will present a current case study around optimized protection and automation
settings management processes, realized as a joint program between a leading European power
utility, a software systems specialist and protection engineering software vendor.
2. Problem Description from the Power Utility Perspective
The entire process of the protection setting management interfaces with various departments and
divisions within a power utility. Further, several generations of the relay technology, comprising digital
Intelligent Electronic Devices (IED‟s), Electronic and Electromechanical devices need to be managed.
Within the digital technology frame, the different manufacturers are using in addition different
technologies that reflect different relay parametrisation software and different test file formats. Further,
the range of asset and relay management softwares and protection calculation software and
databases are using different technologies and different formats. The protection test device
manufacturers are using a range of different technologies and formats to describe relay setting.
Historically “critical relay settings” for electromechanical and electronic relays have been managed on
the so called “setting sheets” which used to be on paper, in Excel spreadsheets or some other
software format or available database formats. Around the World, utilities tried to develop some
“Universal Setting Sheet” which would have the capability to manage all relay settings. This proved to
be not so easy because of the simple fact that even old relays had significant differences in the
parameter types between different manufacturers. In any case, it was possible to unify several
requirements and to develop reasonable number of the typical setting sheets for covering relay setting
management for electromechanical and electronic relays.
The Digital era brought new problems and additional requirements. Relays now had a very large
number of “Critical Parameters”. In addition to these critical parameters, Digital relays generated the
requirement to manage relay files with all settings. Relay parameter started to be divided into variable
and non-variable parameters. In the generations of Pre-Numerical relays, non-variable parameters
had been the various bridges, or internal screws which were often inside the physical device case. As
a consequence, this was not problem in respect of the “security” of the coincidental parameter
change. The problem is that within digital relays (and parameterisation software), all parameters are
variable. It is not possible to label individual parameters as variable and non-variable. New
requirements were then created to manage Non Variable Relay Parameter separate from the variable
parameters. As a result, this generated new requirements on the planning of switchgear and
protection where standardization is required already in the protection design stage. Utilities tried to
manage relay settings as an amalgam of the paper, excel databases, relay vendor software, windows
explorer structures and the like. The serious problem was to ensure data consistency between various
parties involved in the process and different data sources. In particular, data in the respective
manufacturers‟ file formats has been difficult to control and manage. Several different software
platforms must be used for this and it is very difficult to be dependent on the file name only. A main
focus of the manufacturers‟ parameterisation software is the setting, editing and management related
to one device but not the entire setting management. For example, for many power utilities, it was not
possible to answer the question as to which relays have settings where a given Autorecloser Function
is active or where SIR (R/X) ratio is >3. Data queries, across the base of all relays‟ settings (between
different manufacturers), are not possible. Correction and improvement of the settings are very
difficult especially because of different data sources and not having the possibility to present data in
an efficient manufacturer neutral data structure. An additional problem was the introduction of the
Configuration File (CFC) and configuration files that sometimes separate files from the setting file,
depending on the manufacturer. Further, Marshalling exhibits the same problem in considering that all
of the flexibility in the customizing of the relays is also present. Marshalling frames are very often in
the range of very different structures as those of the relay settings. Sometimes, those frames are
linear text structure similar to the settings but, in many cases, they are matrix structures that cannot
be managed by a standard setting management structure. Configurations and CFC are additionally
graphical structures which are manufacturer dependent and cannot be documented and managed
with any standardized data models.
Additional problems encountered include the quantity of setting parameters. An example of the
quantity is the case of the power utility with about 5,000 protection devices including around 50% of
the installed units based on digital technology. In this example, the entire number of setting
parameters may reach 5,000,000 individual data points. The management of 5 Million setting
parameters requires a transparent and structured system with strong data management performance.
One major problem in this respect is trying to manage the so-called “important” or variable parameters
separate from “non-variable parameters”. In this case, control of the remainder of the parameter set is
just done by file control and, in may cases, is not sufficient. Simply, there does not exist one reference
with all setting parameters. There exists at least two references one with “critical (or variable)” settings
usually as some sort of database, excel or even paper (pdf) format and another with site settings (all
other settings) kept as relay files. There exists today no possibility to ensure the value of each setting
parameter to be same as in the required reference format.
The process of the parameter setting life cycle management within power utilities is probably specific
to the individual but the authors contend that there exists many similarities.
From review of many major power utilities, it can be observed that the following business areas are
involved in the parameter setting life cycle management or using that setting information:
Network Planning,
Engineering,
System Analysis,
Asset Management,
Dispatching,
Operations
Site Services (maintenance and commissioning).
One of the scenarios observed is that the utility Engineering department introduces relay technology
and establishes templates for the base settings. Network planning will make changes in the network
topology and hence sends notification of the system analysis which calculates the critical settings and
eventually establishes in addition the complementary settings by merging calculated settings with
those templates selected by the Engineering division. Further settings are transferred to Operations
where, for example, the site Services function implements settings within relays and test setting for
the required service. After commissioning of the settings, the System Analysis function needs
feedback about the setting in service and Dispatching needs some setting information relevant to
feasibility based on those relay settings.
It is noted that the following problems are faced in the above process:
Communication is mostly done by e-mail which is personal communication and not public (Ie
it is not possible to see who gets e-mails related to specific setting)
Setting data are spread within several sources and stored as several formats, such as
Calculation Software, Setting Management (Setting Sheets), Relay Files, Test Results, Relay
Data (Asset) Management, Primary Settings (Network Parameters), Various support
documents and graphs (Z/T, T/I etc…) are also produced.
The problem of separate and unco-ordinated data management for relay hardware, relay
testing and relay settings:
o Relay hardware is often managed within asset management data bases (SAP or
something else developed as a one-off)
o Relay testing result are managed within the Field Service department as test template
management, test document management and test results management
o Relay settings are managed separately within several sources (calculation software,
some data bases, excel file structures etc…)
There is a problem of traceability and data control through entire process
Also, there is a problem of “Cyber Security” and data change control (Who and when changed
which parameter) and the legitimacy of their intervention (access rights)
Further, there is the problem with difficult trouble shooting and plausibility control of the
setting parameters
A problem exists with some manufacturers around saving of the individual setting files in
windows folders without manufacturer software. Here, there is no export of the setting in the
file format (there are some zip mechanisms for zipping an entire project or some database
with all projects, etc).
A issue with some manufacturers is that they have no export of the setting in some readable
ASCII format
The final problem is related to the management of all used and required data, documentation
and communication
3. Problem Description from the calculation software vendor perspective
From the perspective of the vendor of the calculation software, they may see:
- A problem with population of the system because of various network data existing.
Specifically, the problem of populating the starting data base
- The generic issue of roblemthe breadth and range of the different relay models, generations
and technologies
- Problems with various relay logics
- Problems with various setting data formats
- Problems with multiple languages of the settings
- Issues with inaccurate setting file exports
- Problem with interfacing between network planning (topology) systems
- Problem with interfacing setting data management databases
4. Problem Description from the relay manufacturer vendor perspective
From the perspective of the protective relay vendor, there may well be issues related to:
- Parameterisation software Compatibility with wide range of historical protection models
- Data exchange with asset management, setting management, testing, calculation software
- Compatibility with another manufacturer‟s setting configuration & parameterization tools
- Cyber security
- Central server and multi-user applications
5. Problem Description from the setting life cycle management software vendor
perspective
As described within problem description from the power utility perspective, one of the major problem
areas is the existence of various data sources and various systems which make implementation of the
setting management very difficult. For example, a typical example is that protective relays are
managed in some existing asset management and maintenance management systems, which are
basically ERP systems such as SAP PM. Such systems do not support the management of the
settings and corresponding documentation about relay testing (test documents and test results).
Further, some information about maintenance (testing) is managed without corresponding test
documents and without corresponding test results. Clearly, it is not possible nor optimal to manage
relay settings exclusively without managing relays. In order to successfully manage the relay setting
life cycle, it would be typical to have following structure:
Protective Relay 1
Setting 1
Parameter Set 1
Protection Test 1
o Test Document 1
Test Results1
o Test Document 2
Test Results2
o …
….
Parameter Set 2
…
Parameter Set n
o Setting 2
o ….
o Setting n
Protective Relay 2
….
Protective Relay n
Often, there are required interfaces between technically very different systems. This can be seen to
increase cost of implementation and makes utilisation more complicated. In numerous cases, it is the
strategy that the utility “Must” have a central database system where everything must be done: reality
is somewhat different, however. Implementation of settings life cycle management requires
“interdivision” thinking and is hence a very complex process, that requires as well active and
innovative “intersystem” thinking.
One of the typical implementation problems is fighting with various (sometimes very poor) data
sources, which must be migrated and imported into the future settings life cycle system. That is to
say, the location hierarchy and relay must be imported from the existing ERP system (like SAP PM),
in addition to existing relay settings from various excel formats, word documents, pdfs, paper
documents, access data bases or other data base formats. Relay files must be opened with relay
software exported into database readable format and imported into the new system. If the relay
number is large (typically in the region of more than 10 000 units), then the implementation process
could take significant time and be very costly depending of the current data source quality. High levels
of automation and various software tools are necessary to be used.
In the societal context, a further problem is the perceived “conservative thinking” of some involved
power utility staff. This can manifest itself as “paper systems are the most efficient” such that ”we
never get any problems with our existing system, and hence we don‟t see the cost advantagee of
making changes” and “with new system we needs more people to implement and run it”, are
sometimes provoking difficulties during the implementation. During the implementation and migration
of the data into a transparent and well structured database system, it quite often becomes obvious
how bad was the data and how inefficient was work without a structured system (“no identified
problems” is clearly not the same as not having information about a problem.
Implementation of a interdivision process for the management of critical data settings is often blocked
by some thinking “this is not our job” and ”we don‟t care about this part since it is not our
responsibility”. From the utility company point of view, it is important that all process parts are working
well. The major goal is ensuring network stability and ensuring correctness and control of the relay
settings from the calculation until implementation in the relay.
The vendor of the life cycle management software is as well facing problems with multi-languages
coming from the relay settings, this being dependent upon the relay vendor language support. It is
often observed for some manufacturers that relay parameter names are the only identifiers of the
parameter and those names are then language dependent. The consequence of such language
dependency is that the selected relay data model must be established as being language dependent.
One of the major problems for setting management software is that not all relay vendors have setting
export capabilities in some readable format. In order to manage relay settings, it is necessary to build
up a database structure that will support data management.
The authors contend that the expectation of major power utilities is that management of the relay
settings, marshaling and configurations has to be done within a future setting life cycle management
system. This requirement is driving the software for relay setting management to develop database
structures which will be able to manage relay settings, relay marshaling and relay configurations
(CFG). Relay settings can be implemented in the standard structure but marshalling and
configurations are very different from the vendors of the relay technology. This leads to the problem of
developing standard solutions for complete protection data management. Some manufacturers have
linear marshalling data structures that are one dimensional (like settings); some others have matrix
data structures where one parameter can have several values.
Very often, power utilities are using some software for protection setting calculations. As a result,
there is a keen requirement (and need) for interfacing (data transfer) from this software to setting life
cycle management software.
Several problems are faced within these requirements, including: inappropriate data models, generic
parameters (not relay dependent), software vendors for calculation software often did not implement
any potential for interfacing to other systems, mapping of the relay, mapping of the parameters etc…
Interfacing with utility asset management systems is often required. Concerning to this requirements
following problems are faced:
o Inaccurate type definitions (manufacturer type name is not consistently managed)
o Manufacturer‟s name is often problematic due to migration over time (AEG, GEC Alsthom,
Alstom, Areva…)
A major expectation of many utilities is having the possibility to use one software for parameterisation
of the relays supplied by different manufacturers (or having manufacturer neutral parameterisation
software). The central requirement is to have the possibility to export settings from the relay setting
database and to upload this setting to the relay without opening the manufacturer‟s dedicated
parametrisation software. This requirement could be solved if relay manufacturers‟ parameterisation
software had automation functionality (i.e. command lines). In this situation, it would be possible to run
the relay manufacturer‟s software in the background in order to download settings into the relay. A
major precuror to this functionality would be having native relay settings not in binary format but
ratherhaving them in a native format, such as XML. In this case, additing and manipulation of the relay
setting from setting management systems would be possible. Additional automation will improve the
ease of use of the power utility user and will ensure stronger control of the process. This is crucialin
impacting a reduction of human errors in this critical process.
it has bee observed that some relay manufacturers have almost no possibility of exporting settings in
some readable format which is robust and allows some treatment of the settings, as seen in the user
interface of the parametrisation software. It is concluded that such relays can be managed only
through manual procedures. Some manufacturers have very primitive text export (print to file) which
can be used for automatic import but parameter pattern modeling for such relays is almost exclusively
a manual activity. For some manufacturers, XML setting export pattern generation is almost
automatic. Setting import as a result is very accurate and the entire process can be made to run
without any problems. Specifically parameters that have enumeration value types are very
problematic. today, it has been seen that the majority of the relay softwares do not have unique
identification of the enumeration items, which makes data management more difficult. In addition to
major problems around enumeration without a unique ID, dependency on language is a significant
issue. The authors address the problem of missing structured XML parameter export in the section of
this paper regarding requirements for a standard relay setting interface.
Setting life cycle management is necessarily connected with the management of relay testing. As a
result, connectivity with relay testing software becomes one of the requirements. This can be seeen to
be based on the question who needs setting of the relays:
- Setting Calculation Software
- Relay and Settings Life Cycle management Software
- Testing Software
- Protective Relay
Setting data exchange between the above systems becomes necessary in order to allow efficient data
management and fulfill basic requirements regarding “Cyber Security”.
The key elements of the setting management problem from the setting life cycle management
software vendor‟s perspective include the following:
- Problem of implementation with existing very different data sources within power utilities
- Problem of interdivisional (interdepartment) implementation
- Problem with conservative thinking of some utility staff
- Lack of a robust and dependable standard setting data export format for all IED vendors
- Problem with handling Multilanguage settings
- Problem with no standard data structure for the marshalling
- Problem with no standard data structure for the CFC (Configuration)
- Problem with interfacing setting calculation software
- Problem with interfacing utility asset management software (ERP)
- Problem of the Automation (Starting and control) system vendors‟ parameterisation software
- Problem with inaccurate setting exports
- Problem with unique ID‟S for enumeration parameters
- Problem with interfacing test device software
6. Needs and requirements for a manufacturer neutral format of protection setting –
Neutral Relay Setting Interface
There are several key requirements for a manufacturer neutral format in protective relay settings but
the most important are listed below:
Control of each individual setting parameter across all relay settings within the given unique
power utility
Setting exchange between different systems, such as setting calculation software, setting
management software, protection testing software and Relay Parameterization software of
any manufacturer
The possibility to set up control mechanisms in order to ensure “cyber security” consistent
with the norms and standards in vigour, across the entire process of the setting life cycle
management
Comparison of the settings between relays of different manufacturers
Possibility to manage settings, marshalling and configuration by using one file format for
different manufacturers
Management of the setting for entire relays of any manufacturer in the same data base
In order to fulfill the majority of the above-mentioned requirements, a database structure is required.
In the case that a Worldwide standard format for export/import relay settings could be established, it
would be possible to build up a standard database data model which would cover all relays and all
permutations of settings. Such a database structure can be in this case automatically generated and
will be capable of managing any relay setting of any manufacturer. Such database structures must be
capable to manage, within a common framework, all generation of the protection devices including
electromechanical, analog and digital. Requirements placed upon modern digital relays will be that
their setting software would have an export / import capability supporting such a standard format
(being the Relay Setting Interface).
The critical capability of such a Relay Setting Interface would be:
Standard XML data format
Unique Identificators: the authors suggest using UUID (Universally Unique Identifier) or
Microsoft implementation of UUID, being the GUID (Global Unique Identificator) Unique
identifier of each parameter (being language independent). Unique identifier of each
enumeration value
Unique identification for setting
Unique identification for parameter set
Unique identification for the list of all possible enumeration values including actual active
value
Parameter Data Type description
Parameter Blocks Description
Localization on all supported languages
Possibility to add customer nodes and sub nodes like XRIO, DATABASE Keys etc. This will
end in the file having a standard structure in one part and any number of other nodes or
subnodes which can be manufacturer specific, utility specific, calculation software vendor
specific or life cycle setting management software vendor specific.
Possibility to add various requirements related to cyber security, such as machine name, user
name, data source etc.
Possibility to label setting parameter as variable and base parameter (Parameter which can
be changed and which belong to the base settings (location independent settings)
Possibility to handle several parameter sets within one relay setting file
Possibility to show origin of the value (E.g. Manual Entry, written by foreign application, etc…)
Possibility to add unique Relay Device ID (unique identification of the relay)
Possibility to add relay setting ID (unique identification of the relay setting)
Possibility to add parameter set ID (unique identification of the parameter set)
An example of such a standard relay setting file is shown below:
NOTE: The structure shown above is setting life cycle software specific and incorporates some
specific nodes and attributes dedicated to this application. The example given below is of the relay
Setting/relay parameter node:
</RelayParam>
<RelayParam RowGuid="3AA25EBA-53AC-44B4-B3EC-1C66877EB37A">
<RelParBlockID>BDE38064-8886-47AE-BD2F-E05FCE77C14D</RelParBlockID>
<RelParModelID>FD1BDFCB-4043-419B-BDC7-3D63D4F43BC3</RelParModelID>
<XRioID>FD1BDFCB_4043_419B_BDC7_3D63D4F43BC3</XRioID>
<OriginName>CAPE</OriginName>
<XRioFlag>True</XRioFlag>
<SheetFlag>True</SheetFlag>
<BlockPath>Setting/0013 - Distance Zones/Zone Z1/</BlockPath>
<Address>1303</Address>
<CapeTag>1303</CapeTag>
<Name>1303</Name>
<Description>X(Z1), Reactance</Description>
<DataType>Double</DataType>
<Unit>Ohm</Unit>
<Value>2.5</Value>
-<Localization>
<Name Lang3="ENU">1303</Name>
<Description Lang3="ENU">X(Z1), Reactance</Description>
<Unit Lang3="ENU">Ohm</Unit>
<Name Lang3="DEU">1303</Name>
<Description Lang3="DEU">Reaktanz X(Z1)</Description>
<Unit Lang3="DEU">Ohm</Unit>
<Name Lang3="FRA">1303 - X(Z1)</Name>
<Description Lang3="FRA"/>
<Unit Lang3="FRA"/>
<Name Lang3="ESP">1303 - X(Z1)</Name>
<Description Lang3="ESP"/>
<Unit Lang3="ESP"/>
<Name Lang3="SLV">1303 - X(Z1)</Name>
<Description Lang3="SLV"/>
<Unit Lang3="SLV"/>
<Name Lang3="HRV">1303 - X(Z1)</Name>
<Description Lang3="HRV"/>
<Unit Lang3="HRV"/>
<Name Lang3="ELL">1303 - X(Z1)</Name>
<Description Lang3="ELL"/>
<Unit Lang3="ELL"/>
</Localization>
</RelayParam>
NOTE: For further analysis and discussions regarding standard relay interface file structures, please
refer to the authors.
7. Requirements for relay parameterization software
Various manufacturer softwares for relay parameterization are widely used. In addition, several
generations and multiple software versions are in service in most cases. As a result, users are facing
problems of managing all of the numerous versions and technologies.
In order to standardize and simplify the process, the following requirements can be defined for a
future relay parameterization software:
Possibility of automation of parameterization software by using something of the form of
“command Lines” in order to run manufacturer software from another application. The idea
behind this will be that all use can be done with common applications for different
manufacturer.
Possibility of importing and exporting relay settings by Standard Relay Setting Interface Files
(Standard XML File).
8. Case Study – Implementation of Setting Life Cycle Management within ESB Networks
(Ireland)
Following chapter will describe major steps in the implementation of an optimized settings life
cycle management strategy within ESB Networks in Ireland.
The project target was to optimize relay life cycle management, especially with focus on relay
setting life cycle management. The administration time cost saving, improved effectiveness,
improved quality, greater cost effectiveness is seen as the real benefits of implementing this
system.
The following benefits after implementation of the new system has been anticipated:
o Protection settings across the business would be managed and maintained in a
holistic, consistent and efficient manner, minimising human error and improving
quality
o Improvement of data security in setting data management thereby reducing legal and
safety risks as by automating data management and reporting, the risk of losing data
or inaccuracies caused by human intervention is minimized
o Improvement of the transparency of the setting control process across setting request
management, issue and tracking of settings and setting application records.
o Improvement of data control between data source and field operation yielding
administrative efficiency in the entire process by reducing the time spent by field staff
on administration
o Improved reporting and customer service
o Releasing synergy with Protection Commissioning functions:
Policy documents and Standards (pdf)
Links to relevant relay manuals and other technical documentation (pdf)
Commissioning standards (pdf)
State of the technology before the project:
ESB Networks Ltd. (ESB) is responsible for building, operating, maintaining and developing
the electricity network and serving all electricity customers in the Republic of Ireland.
Inside ESB, relay data management was done within the following domains:
- Relay inventory management is done within SAP PM (SAP PM is the main ERP
system and main asset inventory system)
- Setting Data Management was done within CAPE (HV) and within a privately
developed system, PDM – Protective Device Manager (access based relay setting
application) for MV
- Setting Calculations had been done within CAPE (HV) and SynerGEE PCM (MV)
- Various documents relevant to settings were stored as word or excel formats
- Communication relating to setting life cycle had been undertaken mostly through e-
- Relay files has been managed within a Windows folder structure or vendor software
file structure
- Maintenance and commissioning is done within ESB International, the service branch
of the ESB company. Maintenance and commissioning management is undertaken in
conjunction with specialist settings and parameter management systems [1]
- Testing documentation has been managed within the Service department
- For relay testing, ESBI use Omicron CMC and Doble test devices
Project Implementation:
The project plan was to implement optimized relay live cycle management within ESB Networks. As
part of the overall framework, the following IT Landscape was planned to be implemented:
- SAP PM should be used as ERP and main asset inventory database. Basic technical
location and relay hardware data will be managed within SAP PM
- CAPE (HV) and SynerGEE PCM (MV) should be used for protection setting
calculations
- A privately developed system for relay and setting management, PDM (Protection
Devices Manager), should be replaced with an Enterprise Protection Information
System [2]. This system would provide the management of the operational
maintenance and commissioning and was designated to be the main relay data
management database supporting relay data, settings, testing, test results, relay files,
relay disturbance files and all other protection relevant data.
The selected solution was to extend the Enterprise Protection Information System for maintenance
management including implementation of interfaces with SAP PM and CAPE.
Figure 2 below presents the IT Landscape and interfacing between the database systems employed.
Figure 2:
The following preconditions must be fulfilled in order to allow the interfacing between database
structures to work properly:
- Consolidation consistency checks and mapping of the technical location and relay
inventory data between existing IT systems: SAP PM, IPS-ENERGY and CAPE. For
mapping, TAGS has been used in addition to SAP Equipment and technical location
ID and IPS-ENERGY GUID.
- Consolidation consistency checks and mapping of the relay CAPE relay styles and
IPS Parameter Patterns.
- Specify and develop scripts for data migration from the legacy PDM system into the
Enterprise Protection Information System.
During the above procedures, several operational problems occurred and are noted as follows:
- Same Substation or feeders (LZOPs) had different names or references within the
existing system
- It proved difficult to keep track with daily data changes and implementation
- Data inconsistency within the legacy PDM system
- Missing some relay styles/parameters within CAPE
- Missing some user specific styles and corresponding patterns within the Enterprise
Protection Information System
After implementation of all pre-established requirements, implementation of the Setting Workflow
Management process system is done by using dedicated software tools for setting workflow
management.
Figure 3 below presents a simplified process chart of the multidivisional process within ESB
Corporation for the management of the protective relays settings.
The following abbreviations are used:
- SCN – System Change Notification
- GSR – Global Setting Request
- RSR – Relay Setting Request
Figure 3:
There are basically three Divisional role included in this process:
1. Role included in the creation and management of the system change (reason for setting
creation/change)
2. Role which takes care about nominal setting creation/calculation
3. Role which implements the site setting, test setting and setting implementation
The entire process is managed with transparent communication. Logging mechanisms are used to
save and log all e-mails and all other communications related to specific settings.
The process is well documented and controlled in order to fulfill requirements for cyber security. The
process is managed with a system that is designed specifically for and integrated within the power
utility IT landscape.
During the writing of this paper, the project implementation was just in the stage of final testing. The
next planned stage is to start with personal training and commencement of production.
Initial results from the implementation show high optimization of critical data management over the
entire corporate process. One of the good examples of the efficient data management is the handling
of the setting and relay data from the initial calculations until putting it into service without repetition of
the data entry:
1. Relay Created in SAP PM
2. Relay Transferred (Replicated) to IPS-ENERGY
3. Relay Transferred (Replicated) to CAPE
4. A theoretical Setting is calculated in CAPE
5. The Setting is transferred to the EPIS and reference setting is automatically
generated
6. Reference Setting implemented into the given relay on site and compared to the
database reference
7. The Setting is exported to the OMICRON or DOBLE test software for testing of the
relay
8. Setting approved as being “In service”
Before implementation of the entire new process, data had been added in several systems
independently. Relay data was entered in SAP, into CAPE or PDM in addition to upload into the
OMICRON or DOBLE software independently. This was highly difficult to control and was highly
inefficient from the data management point of view.
As can be seen within entire new process, there are no multiple data entries of the same data cross
over all process.
9. Implications
The vision of establishing worldwide standard for protection setting interfaces will allow higher
efficiency in the setting data management and will allow inter-division, inter-vendor and inter-
technology thinking.
The authors are willing to help establish such standards and will make available to all interesting party
all necessary information.
10. Summary and Conclusions
In this paper, the authors have outlined how electrical power utilities and major industrial users have
to face an ever-increasing variation in the approaches proposed by each of the main protection and
automation manufacturers, related to their corresponding relay / automation product software
correlated with different profiles of each individual user.
Such increasing variability has been used by the authors to explain the need for a “manufacturer
neutral format” for managing and keeping critical relay settings. Further, the paper explored the
concept and potential structure for an appropriate Worldwide standard for relay settings and the
related relay setting exchange process.
Understanding of the needs of electrical power utilities regarding modern processes of protection and
automation setting life cycle management will result in additional requirements in respect of “Cyber
Security”, critical setting management workflows, work organization and setting data management
software. This specific domain has been identified by the authors as an area for future research as the
standards and learning around Cyber Security develop in the different areas of the World.
The authors see the learning from such practical case studies as being critical in establishing a viable
and valuable “manufacturer neutral format” for protection and automation equipment lifecycle
management that will be seen as beneficial to all of the stakeholder groups.
Acknowledgments
The authors gratefully acknowledge the support of the Electricity Supply Board (ESB Networks),
Ireland in the preparation of this paper.
References
[1] IPS-ENERGY™ Enterprise Reference Manual, IPS GmbH 2009 [2] IPS-EPIS™ Enterprise Protection Information Systems (EPIS) System Description, IPS GmbH
2010 [3] CAPE Manual, Electrocon Inc. [4] “Innovative Techniques for Intelligent Power System Mobile Data Management”, Z Schreiner, AJ
Middleton, J Bizjak, T&D Europe 2008, Amsterdam, 11-13 March 2008.
Index Terms:
Manufacturer independent relay setting data format, Setting Workflow Management, Setting life cycle management, Setting Maintenance, Setting plausibility control, Setting Cyber Security, Setting Data Exchange, Setting Testing, Setting Calculation
Bibliographies:
Hugh Borland
Daryl Coleman
Adam Middleton
Born in Burton-upon-Trent, UK, on July 29, 1964. He graduated from the University
of Bradford, UK in Electrical & Electronic Engineering and studied Business
Administration (MBA) at the Warwick Business School, UK.
His employment experience includes GEC, GEC Alsthom, ALSTOM and AREVA
T&D in the UK and France. Since 2005, he has held Strategic Marketing and
Business Management assignments within the T&D Business of GE Energy, based
in Europe and Canada.
His specific fields of interest relate to the construction, renovation and automation of electrical power
transmission and distribution networks and substations.
A Chartered Engineer, he sits on the Executive Committee of CIGRE UK, is a Member of the Institute
of Engineering and Technology (MIET), a Member of the IEEE and a Member of the Institute of
Directors (MoID).
Zeljko Schreiner
Dr. Zeljko Schreiner graduated in Electrical Engineering for Power Systems at
the University of Sarajevo in 1987. In 1999, he was awarded the research
degree Mphil at University of Bath, UK. 2004, he was awarded a PhD degree in
Electrical Engineering at the University of Bath, UK. He started his career as a
Project Engineer for electrical substations and power plants. As an
„International Supervisor and Commissioning Engineer for Protection, Metering
and Controlling‟ and as an „International Project Manager for electrical
switchgear‟, he gathered valuable practical experience. In 1997, he joined
OMICRON electronics GmbH, Austria, where he held several leading positions
as leader of Product Management and director of OMICRON Optimization
Services. In 2004, Dr. Schreiner founded German software company IPS-Intelligent Process Solutions
GmbH, where he is General Manager today. He has presented several papers at International
Technical Conferences, including DPSP, DistribuTECH, CIGRE, PowerGen and at the IET.
Dr.Zeljko Schreiner has been working on several studies in the area of power systems asset
management and maintenance optimisation for western European power utilities, including VKW AG
(Austria), LEW AG,VWEW AG and MVV AG (Germany).
