Suggested change to outage and plannedOutage - to support detailed outage interface

[areroshaa]

Background

The following lists a suggestion to change the proposed definitions of outage (type: forced) and plannedOutage (type: Planned).
The rationale behind the suggestion is to support a standardized interface (API based and/or message streaming based) for detailed outages per TSO/DSO customer, as a national Norwegian standard for outages.
Actors like telco companies, DSB nødnett and other actors responsible for critical infrastructure have a need for detailed information about power outages to plan their actions based on the forecasted outage duration.

A detailed interface, meaning an interface listing identified meters (and their location) affected by an outage, will include i.e.:

• MeteringpointId
• Meter serial number
• outage timestamps (actual, planned and forecasted)
• location Id
• position coordinates
• address
• customer identification
• outage status

Here is a list of references (regulations, codes, issues, and other input) affecting, or encouraging, this proposal:
Ref1: Forskrift om leveringskvalitet i kraftsystemet: https://lovdata.no/forskrift/2004-11-30-1557/§2-3
Ref2: Forskrift om sikkerhet og beredskap i kraftforsyningen (kraftberedskapsforskriften): https://lovdata.no/forskrift/2012-12-07-1157/§2-8
Ref3: ElBits issue #334: OutageStatusKind is missing kinds for Cancelled and Invalid: #334
Ref4: Elvia poweroutage-api pilot interface: https://poweroutage-api.elvia.io/swagger/index.html
Ref5: ENTSO-e codelists: https://www.entsoe.eu/Documents/EDI/Library/CodelistV80.zip
Ref6: Proposed outage yaml: https://github.com/3lbits/NoCIMExtensions/blob/Feature/outage_schema/schemas/yaml/outage.linkml.yaml
Ref7: Proposed plannedOutage yaml: https://github.com/3lbits/NoCIMExtensions/blob/Feature/outage_schema/schemas/yaml/plannedOutage.linkml.yaml

Proposed change

• Based on proposed outage (Ref6) and plannedOutage (Ref7), alter or add information needed to serve the requirements and purpose of a detailed outage interface. The additional information needed is given in the swagger from the Elvia pilot (Ref4).
• Use the proper codes from the ENTSO-e codelists (Ref5) as referenced in the OutageStatusKind issue (Ref3)

Consequences

A detailed interface will most likely have the following consequences:

• the information is classified as "KSI" (kraftsensitiv informasjon / power system sensitive information) and is therefore subject to be regulated by "Kraftberedskapsforskriften"(Ref2)

[EmilieSkog]

Updated the outage schema to cover both planned and unplanned outage : https://github.com/3lbits/NoCIMExtensions/blob/Feature/outage_schema/schemas/yaml/outage.linkml.yaml

Example data for unplanned outage: https://github.com/3lbits/NoCIMExtensions/blob/Feature/outage_schema/data/yaml/unplannedOutage.yaml

Example data for planned outage:
https://github.com/3lbits/NoCIMExtensions/blob/Feature/outage_schema/data/yaml/plannedOutage.yaml

Worth mentioning:

• Included NameType for Meteringpoint ID. UsagePoint.mRID is a uuidv4, to support measurementpoint IDs as per GS1 Name and NameType are added as a workaround. This is shown in the examples.
• Organisation number is not covered in the current CIM (CIM17). Added workaround using Name and NameType, including the NC extensions nc:Name.mRID and nc:NameType.mRID. Could consider adopting changes suggested for CIM18 that support org.no.
• cim:OutageStatusKind might not hold sufficient values to cover common status types
• Location.mainAddress has compound within compounds. Could consider adopting changes in Location suggested for CIM18.