Version 1.2

Introduction

Background

The Planned Outage Coordination process (POCP) and the POCP database were jointly developed by electricity industry participants and Transpower through a series of joint industry workshops during 2002/2003. A further series of joint industry workshops reviewed the POCP and the database in early 2006.

The purpose of the POCP is to provide a consistent approach for Asset Owners to publicly advise timely and good quality information about their planned outages. This allows Transpower as the System Operator to assess the potential impacts of the planned outages on power system security, and then communicate the results of the security assessments to all industry participants. All parties are then able to use that information to make decisions about planned outages in which they have an interest.

The POCP is a voluntary process. It does not override any obligations imposed on Asset Owners or the System Operator by the Rules.

Planned Outage Co-ordination Process (POCP)

The POCP can be summarised as follows:

A detailed process flow chart for the POCP, and supporting Business Rules, are included in Appendix A.

Benefits to Asset Owners of using the POCP

The POCP and database, provide electricity industry participants with information on planned outages affecting the New Zealand Power System. Being part of the POCP allows Asset Owners to:

For further information

For more information on the POCP, the POCP Database or this User Guide please contact:

Greg Spence
Operations Planning Manager
Transpower New Zealand Ltd.
PO Box 1021
Wellington
system.operator@transpower.co.nz

The Planned Outage Co-ordination Process Database

Overview

The POCP Database allows Asset Owners to upload and access data on planned outages of their and other participants' assets.

Uploaded data is used by the System Operator to assess any potential issues between planned outages, as communicated by all Asset Owners, and the System Operator's obligations under its Principle Performance Objectives. Where such issues exist, the System Operator will highlight this within the POCP Database, so Asset Owners are aware of any potential problems, and can then make more informed decisions in relation to assets in which they have an interest.

Asset Owners may download data from the POCP Database to obtain a better understanding of other Asset Owners' planned outages that may affect them. All Asset Owners are encouraged to use the database frequently and be aware of any changes that may require their action or consideration, as well as ensuring their own data remains complete and up to date.

The database can be accessed on http://pocp.redspider.co.nz/. Note that access to the database is restricted for viewing and retrieving planned outage data, to industry participants. However, interested parties can self register to view outage data.

What is an "outage"?
An outage is defined as any asset which is not capable of the generation, conveyance or consumption of electricity. Asset Owners are encouraged to upload the POCP Database with information about all planned outages.
Who is an "Asset Owner"?
An Asset Owner is defined as any person who owns and/or manages equipment connected to the electricity grid system. It includes by definition of "equipment" all lines companies, distribution networks and generators.
Is the POCP a mandatory requirement?
No. The POCP is a voluntary process. However, Asset Owners are reminded that the POCP does not override any obligations that may be imposed under the Rules.

Accessing data on the POCP database

The POCP database can be accessed at http://pocp.redspider.co.nz/.

Any registered user can browse or search the database upon acceptance of the legal Disclaimer that precedes access to it.

Search Function

The detailed search function allows database searching by:

Additionally, information may be viewed in three formats including Excel spreadsheet.

Results from each search are provided in the remainder of the search screen, and may consist of many separate pages. Results can be ordered by start time, outage ID, owner or date of last change.

Within the regular search results, each line represents a planned outage event. A detailed view of the entry can be obtained by selecting the outage plant identification code at the left of the screen. For users with JavaScript enabled, any part of this line may also be selected.

Much more detail on using the online database can be found in Appendix D - Help text.

Downloading

Within the "view" option, Excel view may be selected. This opens a new Microsoft Excel spreadsheet document containing the result data, ready for saving or manipulating as required.

Where can a complete description of each field be obtained?
A complete description of all fields used in the POCP database can be found in Appendix D - Help text.
Is there an on-line help facility available?
Yes, there is an on-line help option which is reproduced in Appendix D - Help text.
Is a password required to search the database?
Yes, access to the database cab be obtained through the self registration process.

Uploading data to the POCP database

Asset Owners should make reasonable efforts to ensure planned outage data uploaded is accurate and up to date.

The system provides for two means of uploading:

The preferred format for uploading data is XML. This is because:

An XML testing platform is available at: http://pocp.redspider.co.nz/xml_test.php. Users are encouraged to test using this platform to ensure their data is tagged correctly before actual uploading.

For further information on XML fields and a format example, refer to Appendix C.1.

Because not every user will be familiar with XML, CSV is also available. CSV is a common format for importing/exporting from/to most database software including Excel and Openoffice. The field descriptions and their order are shown in Appendix C.2.

Once uploaded, the System Operator uses this data to assess any potential failure it might incur in meeting its Principle Performance Objectives (PPO). Where a planned outage does have a potential impact on the ability of the System Operator to meet its PPO, then the relevant planned outage is highlighted, and additional information provided, within the database.

When should planned outage data be uploaded?
Ideally, outage information should be uploaded up to 12 months before the date it is planned to occur. This provides the System Operator and other Asset Owners with sufficient time to appreciate the extent of the outage, and plan accordingly. Recognising that 12 months notice is often not possible, outage information may be provided as soon as practical.
Can data be amended following its upload?
Any information uploaded may be subsequently changed at any time by the Asset Owner until its end date has passed by a certain period (currently 7 days).
Does the POCP apply to all planned outages?
Yes. However Asset Owners have the choice to upload either all planned outage data, or specific outage data at their discretion.
Is a password needed to access this part of the site?
Yes, this part of the site cannot be accessed without a username and password.
What is a "potential EGR issue"?
Under the PPO, the System Operator is tasked with co-ordinating New Zealand's power system in terms of meeting its security, frequency and voltage objectives. Asset Owners are also obliged under the Rules to assist the System Operator in meeting those objectives. A potential EGR issue exists where a planned outage may impact adversely on the System Operator's ability to meet the PPO.

Appendix A - POCP Business Rules and Process Chart

Business Rules

Business Rules for the Planned Outage Co-ordination Process

Business Rule 1
General Principles:
  • Asset owners will use reasonable endeavours to provide accurate, up to date information about outages to the System Operator
  • Asset owners reserve the right to change any planned outage
Business Rule 2
An outage is defined as: Any asset which is not capable of the generation, conveyance or consumption of electricity.
Business Rule 3
Asset owners will provide the System Operator with information about either:
  • All outages; OR
  • Specific outages at the discretion of individual Asset Owners
Business Rule 4
Asset owners will provide outage information to the System Operator:
  • Up to 12 months out from the planned outage;
  • As soon as practical in each instance.
The information will hold good until changed by notification from the Asset Owner.
Business Rule 5
All outage information provided through the POCP will be published.
Business Rule 6
Asset owners will provide the following information:
  • The asset owner's unique record ID
  • The asset owner
  • The asset
  • Start date and start time
  • Finish date and finish time
  • Type
  • GIP or GXP
  • Change in asset capability, stated in applicable units e.g. megawatts, megavars, amps
  • Status of the outage (i.e. Tentative, Confirmed, Cancelled)
  • Contact person
  • Entered by (login/password)
  • Category (i.e. Direct Connection, Transmission, Generation)
  • Recall time
  • Comments (free text)
In relation to each published outage the System Operator will record:
  • A unique POCP record ID
  • The date the outage was published/modified
  • The current asessment status (i.e. Assessed, Assessed (C), Being Assessed, Changed, New, Potential EGR Issue)
Business Rule 7

Outage information received by the System Operator will be collated and published as soon as practical.

The System Operator will then assess the information in terms of meeting its Principle Performance Objectives.

Where the assessment identifies a situation where there is a potential failure to meet the Principle Performance Objectives, then the System Operator will publish notifications of those situations (including details and supporting assumptions), and monitor responses to the notifications

A chart of the general POCP process is available here.

Appendix B - Technical detail on file downloading

Outage data may be downloaded in CSV or XML format. The CSV export option is available within the main search screen, and is discussed further in Appendix D.

For automatically retrieving search results, the POCP site offers a SOAP Web Service capable of handling the same queries as the regular web interface. The web service is accessible via http://pocp.redspider.co.nz/soap4.php. The SOAP interface provides a WSDL schema for ease of integration.

Developers intending to access the Web Service should contact Richard Clark (richard@redspider.co.nz) in order to ensure they are aware of the latest changes.

Developers intending to use this interface should have a solid understanding of how the website works in general, what the various terms such as outage block and plant relate to, and what their expected formats are. The intention of this section is to outline the interface itself, details on using the site are found elsewhere in this guide.

The interface currently supports the following methods:

array_of_outage = search(plant, id, start, end, gps, owners, categories, planning, assessment, last_modified_since)

Arguments:

plant
Plant or outage block
id
Outage ID
start
Start date/time (YYYY-MM-DD HH:MM:SS)
end
End date/time (YYYY-MM-DD HH:MM:SS)
gps
List of Grid Points (array of string)
owners
List of Owner IDs (array of int)
categories
List of Category IDs (array of int)
planning
List of Planning status IDs (array of int)
assessment
List of Assessment status IDs (array of int)
last_modified_since
Only include outages modified since this date/time (YYYY-MM-DD HH:MM:SS)

Return value:

This function returns an array of "outages". Outages are a complex type of the following structure:

id
Outage ID
plant
Outage block/plant
start
Start date and time of outage
end
End date and time of outage
time_type
Whether the range is continuous, or daily
owner
int ID for owner
assessment_status
int ID for current assessment status
planning_status
int ID for current planning status
category
int ID for current category
mwatt_remaining
Megawatts remaining (string, empty if unknown)
mwatt_lost
Megawatt reduction (string, empty if unknown)
mvar_remaining
Megavar remaining (string, empty if unknown)
gps
List of Grid Points (array of string)
last_modified
date/time the outage was last modified
nature
The nature field (string)
reference_id
The reference ID for the outage, can be used to construct URLs to POCP pages. (int)

Reference ID is the POCP internal ID for a given outage, and can be used to construct a URL to link directly to the POCP entry for that outage like this: 

http://pocp.redspider.co.nz/index.php?op=get_outage|view_outage&outage_id=reference_id

So, reference ID 25713 would be: 

http://pocp.redspider.co.nz/index.php?op=get_outage|view_outage&outage_id=25713

owner_list()

Arguments

No arguments

Return value

Returns an array of Mapping, a Mapping is a complex type of the following structure:

name
Name of the element, in this case the Owner name
id
Integer ID relating to the name

category_list()

Arguments

No arguments

Return value

See owner_list, the name field will contain the name of the category however.

assessment_status_list()

Arguments

No arguments

Return value

See owner_list, the name field will contain the name of the assessment_status.

planning_status_list()

Arguments

No arguments

Return value

See owner_list, the name field will contain the name of the planning_status.

Users requiring further technical assistance should contact Richard Clark at Red Spider (richard@redspider.co.nz) in the first instance.

Appendix C - Technical detail on file uploading

  1. XML upload format
  2. CSV upload format

C.1. XML upload format

Note: For easiest integration, the use of the cURL utility (http://curl.sourceforge.net/ is recommended for uploading of XML files via HTTP.

The following is an example planned outage using the XML format. All fields are linked to their respective descriptions.

<?xml version="1.0"?>
<pocp>
<outage_update>
<outage>
<id> TEST_0001 </id>
<planning_status> tentative </planning_status>
<category> generation </category>
<time_type> continuous </time_type>
<nature> pso </nature>
<plant> CCT_241_GYM_WCC </plant>
<comment> Test comment </comment>
<start> 2003-06-25T12:00:00 </start>
<end> 2003-06-25T13:00:00 </end>
<recall> 02:00 </recall>
<mwatt_remaining> 10.00 </mwatt_remaining>
<mwatt_lost> 5.00 </mwatt_lost>
<mvar_remaining> 3.00 </mvar_remaining>
<confidential> true </confidential>
<gp> CCT </gp>
</outage>
</outage_update>
</pocp>

Tag specifics

<pocp>
Quantity: required, one only
The root tag for a POCP related upload or download, all POCP data or operations are contained inside.
<outage_update>
Quantity: optional, unlimited
Indicates that the outages contained within are updates to the outage set stored by the POCP database. At this time, outage_update is the only kind of operation you may do via the XML interface. In the future, other operations may be available. You may have more than one per file if you wish, but it seems a little redundant. Make lots of outage sets instead.
<outage>
Quantity: optional, unlimited
Defines a single outage, identified by the id tag.
<id>
Example: <id>TEST_0001</id>
Format: [A-Z0-9a-z_-]+
Quantity: required, one only
An alpha-numeric string which uniquely identifies the outage for the uploading asset owner. Only one outage with a given ID may be specified per outage_update.
<planning_status>
Example: <planning_status>tentative</planning_status>
Format: tentative|confirmed|cancelled
Quantity: required, one only
The current planning status for the outage, as defined by the uploading asset owner. Outages that are not included in a given upload will automatically be set to cancelled unless they have passed their end date.
<category>
Example: <category>generation</category>
Format: generation|transmission|direct_connection
Quantity: required, one only
Category of outage.
<time_type>
Example: <time_type>continuous</time_type>
Format: continuous|daily
Quantity: required, one only
Times are defined by start and end, time_type determines whether these times refer to a single block of time, or a regular period each day. For example, if the times defined are 9am on the 12th through to 5pm on the 15th, continuous means that entire duration, daily means 9am through to 5pm each day from the 12th tot he 15th.
<nature>
Example: <nature>pso</nature>
Format: pso|rs|sca|oth|ope
Quantity: optional, one only
For transmission outages, a nature may be specified (generation outages should leave this tag out). The available entries are: pso (Power system op) rs (Removed from service) sca (SCADA) oth (Other) ope (In service but unavailable for energy transport)
<plant>
Example: <plant>CCT_241_GYM_WCC</plant>
Format: [A-Z]{3}[A-Za-z_]*
Quantity: required, one only
The outage plant or block is defined as a set of elements separated by an underscore (_), the only constraint is that the first three letters must match one of the given gp entries.
<comment>
Example: <comment>Test comment</comment>
Format: All valid ASCII, with XML entities escaped
Quantity: optional, one only
Comments are optional and arbitrary. The only real restrictions are a maximum length of 4096 bytes, and that the comment (naturally) cannot contain > and < entries (they should be translated to the HTML entity equivalents first (&gt; and &lt; respectively)).
<start>
Example: <start>2003-06-25T12:00:00</start>
Format: yyyy-mm-ddThh:mm:ss
Quantity: required, one only
The start time for the outage in standard XML format. The T is required, no timezone extension is permitted at this time, all times are assumed to be in NZ standard or daylight time as applicable.
<end>
Example: <end>2003-06-25T13:00:00</end>
Format: yyyy-mm-ddThh:mm:ss
Quantity: required, one only
The end time, format the same as start. The end time has several additional restrictions. It must be later than the matching start, and it can be no earlier than 7 days prior to the date of upload.
<recall>
Example: <recall>02:00</recall>
Format: hh:mm
Quantity: optional, one only
Time to recall.
implementation notes: The format hh:mm was chosen rather than a normal XML duration specification because, unlike the start and end default spec, the duration specification is complex and not entirely intuitive. Also note that it is possible to specify hours in the hundreds if required.
<mwatt_remaining>
Example: <mwatt_remaining>10.00</mwatt_remaining>
Format: d+.dd
Quantity: optional, one only
Megawatts remaining while outage is active. Must be a positive number with no more than 2 decimal places. If the value is not known, the tag should be left out entirely.

Note: For Load, this tag defines the load still drawn while the outage is active.

implementation notes: The decimal place limit was put in place primarily because 2 decimal places is about the maximum that can be readable. While it is entirely possible that the POCP system itself could do numeric rounding, it has no understanding of the implications of such rounding. The decimal limit forces the uploading entity to do its own rounding and thus make an intelligent decision as to what direction that rounding should take.
<mwatt_lost>
Example: <mwatt_lost>5.00</mwatt_lost>
Format: d+.dd
Quantity: optional, one only
Megawatts lost from normal while outage is active. Must be a positive number, follows decimal reasoning for mwatt_remaining.

Note: for Load, this tag defines the load no longer drawn while the outage is active.

<mvar_remaining>
Example: <mvar_remaining>3.00</mvar_remaining>
Format: d+.dd
Quantity: optional, one only
Megavar remaining while outage is active. Must be a positive number, follows decimal reasoning for mwatt_remaining. WARNING: for Load only, this field represents Megavar lost, not Megavar remaining, due to the difficulty of estimating the later.
<confidential>
Example: <confidential>true</confidential>
Format: true|false
Quantity: required, one only
If the outage is marked confidential, it will not be displayed to other asset owners on the POCP system.
<gp>
Example: <gp>CCT</gp>
Quantity: required, unlimited
Grid point involved in the current outage. At least one of these grid points must match the first three alpha characters of plant. As many as necessary may be specified by repeating the tag.

CSV upload format

Field position Field name Format
1 Outage ID Anything less than 255 characters long
2 Outage start time YYYY-MM-DD HH:MM:SS or DD/MM/YYYY HH:MM:SS
3 Outage end time YYYY-MM-DD HH:MM:SS or DD/MM/YYYY HH:MM:SS
4 Status TENTATIVE, CONFIRMED, CANCELLED
5 Asset type GENERATION, TRANSMISSION, DIRECT CONNECTION
6 Recall time HH:MM:SS
7 Confidential Y,N
8 Comments Free form, avoid control characters and line feeds
9 Outage plant Description of equipment to be removed from service, i.e, NPL_T8, ROX_1. For a station outage the suffix stn is to used, i.e, CYD_stn
10 Outage time type Daily, continuous: State whether the outage is continuous between start and end date and time or whether it will be removed on a daily basis between start and end times
11 Transmission outage nature Empty if not transmission
12 Megawatt output loss Empty, zero or a positive number (decimals permitted)
13 Megawatt output remaining Empty, zero or a positive number (decimals permitted)
14 MVar output remaining Empty, zero or a positive number (decimals permitted)
15 GIP/GXP Use station code where generation is connected and offered in at or where equipment or load is connected to the system. No bus number required.
16 Another GIP/GXP As necessary, additional GIP/GXPs can be added in a similar fashion

Example:

TESTID0001","2003-01-01 09:00:00","2003-01-01 11:00:00","TENTATIVE","GENERATION","02:00:00","N","Test unit 1","ABC_FO","continuous","","8","20","10","ABC"

POCP Database Help

  1. Adding and Editing user details
  2. Uploading outages to the database
  3. Downloading search results from the database
  4. Search options
  5. Search result viewing options
  6. Outage field descriptions
  7. Bookmarking searches
  8. Example searches

Adding and Editing user details

The User management functions associated with the database are available to administrative users of each Asset Owner only

Administrative users may add or delete new user names and passwords for the Asset Owner they represent. They may also change their Asset Owner name details.

Users with standard password access are able to upload data to the database and edit outage details of the respective Asset Owner they represent. They may also edit their own login name or password, by selecting their user name or description at the top left of the screen.

Uploading outages

Outages can be entered into the database in one of three ways, manual entering using the Add/Edit menu options (Available only to users whose asset owner has requested that they run in manual mode), and uploading entire outage sets using CSV or XML.

XML is the preferred format for uploading outage information to the database, because it:

Asset owners developing an XML interface should contact Richard Clark of Red Spider if they require any assistance. Technical resources available include a testing version of the upload system and file format at http://pocp.redspider.co.nz/xml_test.php.

Asset owners using the XML system are encouraged to use the test facility to ensure their upload system operates correctly before requesting access to the production system.

CSV format files can be uploaded by logging into the database as a user with Edit or higher privileges and clicking "upload outages". The file format definition is available from there as well.

It is important to note, for both XML and CSV uploads, that any outage that is not uploaded, and has not yet passed its end date, is automatically cancelled. This means that the system does not need to be notified explicitly of cancelled outages, they are simply left out of any subsequent uploads.

Downloading results

An excel-compatible (TSV) download of the outage data is available for any search by changing the "View" to "Excel export". For most people, this will place the results directly into excel.

Important note: the format of the results are not the same as the format of the upload for CSV. The upload only requires fields provided by the Asset Owner, whereas the format for the results includes many pieces of information generated by the database itself or the system operator.

Search options

There are a number of different search options, allowing for accurate filtering to provide only the information needed. They can be used in combination.

Plant

The Plant field at the top left of the search screen allows any part of the outage plant/block to be specified. Multiple entries should be separated by a comma, and the '%' symbol can be used as a wildcard.

ID

The ID field allows matching on the asset-owner supplied outage ID. Since the Asset Owner supplies this information directly, more than one Asset Owner may use the same ID. In general however this case is rare and does not cause problems.

Date

The Active fields permit matching by date. Outages are matched if they are active at any time within the region specified.

Owner

Either one or multiple owners may be selected.

Category

There are three generic types of planned outage, which may be searched separately or together:

Direct Connection
Equipment owned or operated by end-users of electricity that are directly connected to New Zealand's power system.
Generation
Equipment owned or operated by Generators
Transmission
Equipment owned or operated by Transmission or Distribution networks

Planning status

One of three outage states defined by the uploading Asset Owner:

Tentative
The planned outage may occur
Confirmed
The planned outage will occur
Cancelled
The planned outage has been cancelled

Assessment status

There are six assessment status. The System Operator sets four of these, "Assessed","Assessed (C)", "Being Assessed" and "Potential EGR Issue" appropriately. The remaining two, "New" and "Changed" are set by the database based on the Asset Owner's upload.

Search result options

There are two fields which determine how the results of a search are viewed or ordered:

Order by

Order by changed the order of the resulting outages on the page, sorting by one of the following fields:

Start time
The results are ordered by start time, with the nearest start time first.
Last modified
The results are ordered by the date of last change to the outage, with the nearest modified time first.
Owner
The results are ordered by Asset Owner, starting at A

View

The view field provides three seperate options for viewing results:

Regular
Default option includes most relevant information for Asset Owners
Operator
Includes additional information required for the System Operator
Excel Export
Creates a new Microsoft Excel document containing the search results. This provides all key information about the outage.

In addition, clicking on the underlined Plant on the left of any row will take you to the outage details screen displaying more information and history of changes.

Outage fields

A description of each field is provided:

Field Description
Plant Plant is identified by the station or transmission circuit asset code.
ID Defines the outage ID used by the Asset Owner. The database uses the outage ID to differentiate new outages from changed outages.
Start The start field shows the date and time of day the outage will commence. Time of day is given in 24 hour format.
End The end field shows the date and time of day the outage will commence. Time of day is given in 24 hour format.
Type Defines the type of outage as either continuous or daily. A continuous outage means that the outage is continuous throughout the time specified between the start and end date/times. Daily outage means that the event occurs each day between the start and end times specified, until the end date.
Owner Defines the Asset Owner responsible for uploading the planned outage data.
Assessment The EGR assessment status, either Assessed, Assessed (C), Being Assessed, Changed, New or Potential EGR issue.

The following information shows the points at which the various Assessment status may be added or changed. These timeframes are indicative only. Lead times will vary due to the number of outages loaded, the complexity of the outages, and the number of outages that are rescheduled or altered in the final weeks leading up to the start of the outage:

Being Assessed
Typically occurs between 4-6 weeks out from the start date of the outage.
Assessed and Assessed (C)
Typically occurs between 2-4 weeks out from the start date of the outage.
Potential EGR issue
Can be identified at any time
Outages that are re-submitted after they have been assessed will revert to Changed status.

Planning Defines the current planning status for the outage, as defined by the uploading Asset Owner. May be tentative, confirmed or cancelled.
MW Remaining Shows the MW remaining while the outage is active. For Load, shows the load still drawn while the outage is active.
MW Lost Shows the MW lost from normal (normal - remaining) while the outage is active. For Load, shows the load no longer drawn while the outage is active
MVar Remaining Shows the MVar remaining while the outage is active. WARNING: counter-intuitively, for Load only, this is field is MVar Lost instead due to the difficulty of estimating the MVar remaining value.
GPs Shows the Grid Points involved in the current outage.
Category Shows the type of outage. May be either transmission, generation or direct connection.
Modified The date and time of the last change to the outage
Recall Time Defines the outage recall time if known
Confidential This field is depreciated and should always be No
Transmission Nature Defines the nature of a transmission outage
Additional comments Any other relevant details provided by the Asset Owner
Current Assessment document If present, a link to a document provided by the System Operator regarding the assessment of the outage.
Constraints Identities of any constraints affecting the system as a result of the outage
History Tracks changes made to the outage previously.

Search bookmarking

The POCP database allows favourite searches to be named, saved and accessed using the "Add to Favorites" function within Internet Explorer and "Add to Bookmarks" within Netscape/Mozilla/Firefox.

Search examples

Example 1

In the following example, a search has been undertaken for generation and transmission outages:

Example 2

In Example 2 (below), a multiple search has been undertaken for generation and transmission outages: