The following is an example planned outage using the XML format. All fields are linked to their respective descriptions.
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 |
<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 (> and < 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.
| 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 |