DataMaintainer DataMaintainer was added in Version 19

Concept Link IconSee Also

 

DataMaintainer was added in Version 19

DataMaintainer objects represent entities responsible for maintaining the input data for objects in the model. The DataMaintainer object serves 2 purposes

  1. When a piece of data in a case is suspected to be in error it provides contact information in the form of an email or phone number of someone to contact to ask about this data
  2. Software has features that allow a user to write out only the data that belongs to a particular DataMaintainer. This construct makes it easier to divide a case into chunks that represent the responsibility of maintaining particular data.

The following statements describe how DataMaintainers relate to other objects.

  1. Some objects can be assigned a specified DataMaintainer.
  2. Some objects may inherit their DataMaintainer from a related object.
  3. Not all object types can even be considered to belong to a DataMaintainer.
  4. Ultimately, an object can belong to only one DataMaintainer, and the assumption is that all fields associated with that object are the responsibility of the DataMaintainer.
  5. Caveat to statement 4: a DataMaintainer object itself can belong to another DataMaintainer. In this way groups of DataMaintainers can be created.

Each Object Type has 2 YES and NO questions based on the first two statements above.

This gives us 4 permutations to the Assign/Inherit questions: YES/YES, YES/NO, NO/YES and NO/NO.

 

Specification of DataMaintainer within Software

Within PowerWorld objects there are potentially 4 different columns associated with a DataMaintainer.

Objects that don't support DataMaintainer (NO/NO)

There is no need to discuss the NO/NO permutation, but generally these are objects representing one of the following 4 types of ObjectTypes.

  1. Solution options (CTG_Options, SimSolution_Options, etc.)
  2. Environment options (RatingSetNameBus, RatingSetNameBranch, etc.)
  3. Objects that are dynamically created and maintained by the software (Island, ZoneTieLine, AreaTieLine, SuperBus)
  4. Results of a software calculation (ViolationCTG)

Objects to Which DataMaintainer can be assigned, but Inheritance is not allowed (NO/YES)

The following is a list of ObjectTypes that can be assigned a DataMaintainer but never Inherit their DataMaintainer from another object (YES/NO).

Area, BalancingAuthority, BGCalculatedField, Contingency, CTGElementBlock, CustomExpression, CustomExpressionStr, CustomMonitor, DataMaintainer, DFACTSCorrection, Direction, DistributionEquivalent, Filter, GlobalContingencyActionsElement, InjectionGroup, Interface, LimitSet, LoadModelGroup, ModelCondition, ModelExpression, ModelFilter, ModelStringExpression, Owner, PlayIn, RemedialAction, StudyMWTransactions, Substation, SuperArea, TSContingency, TSLimitMonitor, VoltageControlGroup, XFCorrection, Zone

Objects that Can Inherit a DataMaintainer (YES/NO and YES/YES)

Adding the ability for objects to inherit their DataMaintainer may seem to add complexity to the concept of a DataMaintainer. However, it is actually crucial to the use the DataMaintainer. This is because without it, it would require every single data record to be assigned a DataMaintainer independently, which would greatly increase the workload for those adding this new assignment. What we expect to occur instead is that each substation in the model will be assigned a DataMaintainer and that the vast majority of network objects will then simply inherit their DataMaintainer definition from the substation. Even if substations are not added to the models, the DataMaintainer could be assigned to a Bus with inheritance occurring from there.

With this explanation for why the inheritance of DataMaintainers is vital, we now cover the final 2 other permutations (YES/YES and NO/YES). For the more complex relationships obtained from the network topology, the following picture illustrates how this inheritance is handled. Boxes which are shaded in light orange represent ObjectTypes which Always Inherit, while boxes that are not shaded represent ObjectTypes which can have a DataMaintainer assigned.

 

This information can always be obtained from within PowerWorld Simulator by going to the Windows ribbon tab and choose Export Case Object Fields > Send to Excel. In the table exports, in the row representing the ObjectType there are columns which show whether Data Maintainers are supported and whether Data Maintainer Inheritance is supported and how. The table below shows a summary of the objects that existed as of November 2015 in PowerWorld Simulator 19, when the DataMaintainer object was first added. The columns in this table are the ObjectType, whether it can be assigned a DataMaintainer, and finally a precedence of how it inherits its DataMaintainer from a related object.

 

ObjectType

Data Maintainer Support

Data Maintainer Inheritance Precedence

 

3WXFormer

YES

1. Primary Bus

2. Primary Bus’ Substation

3. Secondary Bus

4. Secondary Bus’ Substation

5. Tertiary Bus

6. Tertiary Bus’ Substation

 

AreaContingencyReserveBid

AlwaysInherit

Area

 

AreaOperatingReserveBid

AlwaysInherit

Area

 

AreaRegulatingReserveBid

AlwaysInherit

Area

 

Branch

YES

1. NonMetered Bus

2. NonMetered Bus’ Substation

3. Metered Bus

4. Metered Bus’ Substation

(except for windings of a 3WXFormer which inherit from the 3WXFormer)

 

Bus

YES

Substation

(except for star buses of 3WXFormer which inherit from the 3WXFormer)

 

Condition

AlwaysInherit

Filter

 

ContingencyElement

AlwaysInherit

Contingency

 

ContingencyMonitoringException

AlwaysInherit

Contingency

 

CTGElementBlockElement

AlwaysInherit

CTGElementBlock

 

DCTransmissionLine

YES

1. Rectifier Bus

2. Rectifier Bus’ Substation

3. Inverter Bus

4. Inverter Bus’ Substation

 

DFACTS

YES

1. Branch

2. Branch’s NonMetered Bus

3. Branch’s NonMetered Bus’ Substation

4. Branch’s Metered Bus

5. Branch’s Metered Bus’ Substation

 

Gen

YES

1. Bus

2. Bus’ Substation

 

GenBid

AlwaysInherit

1. Generator

2. Generator’s Bus

3. Generator’s Bus’ Substation

 

InterfaceElement

AlwaysInherit

Interface

 

LineShunt

YES

1. Bus

2. Bus’ Substation

 

Load

YES

1. Bus

2. Bus’ Substation

 

LoadBid

AlwaysInherit

1. Load

2. Load’s Bus

3. Load’s Bus’ Substation

 

ModelConditionCondition

AlwaysInherit

ModelCondition

 

ModelFilterCondition

AlwaysInherit

ModelFilter

 

MTDCBus

AlwaysInherit

1. MTDCRecord

2. MTDCRecord’s VConv_Bus

3. MTDCRecord’s VConv_Bus’s Substation

 

MTDCConverter

AlwaysInherit

1. MTDCRecord

2. MTDCRecord’s VConv_Bus

3. MTDCRecord’s VConv_Bus’s Substation

 

MTDCRecord

YES

1. Voltage Controlling Converter Bus

2. Voltage Controlling Converter Bus’ Substation

 

MTDCTransmissionLine

AlwaysInherit

1. MTDCRecord

2. MTDCRecord’s VConv_Bus

3. MTDCRecord’s VConv_Bus’s Substation

 

PartPoint

AlwaysInherit

InjectionGroup

 

PlayInInfo

AlwaysInherit

PlayIn

 

PlayInSignal

AlwaysInherit

PlayIn

 

PVPlotSeries

AlwaysInherit

PVPlot

 

PVPlotVertAxisGroup

AlwaysInherit

PVPlot

 

PVSubPlot

AlwaysInherit

PVPlot

 

ReactiveCapability

AlwaysInherit

1. Generator

2. Generator’s Bus

3. Generator’s Bus’ Substation

 

RemedialActionElement

AlwaysInherit

RemedialAction

 

SGPlotSeries

AlwaysInherit

SGPlot

 

SGPlotVertAxisGroup

AlwaysInherit

SGPlot

 

SGSubPlot

AlwaysInherit

SGPlot

 

Shunt

YES

1. Bus

2. Bus’ Substation

 

StudyMWTransactionsBid

AlwaysInherit

StudyMWTransactions

 

SuperAreaContingencyReserveBid

AlwaysInherit

SuperArea

 

SuperAreaOperatingReserveBid

AlwaysInherit

SuperArea

 

SuperAreaRegulatingReserveBid

AlwaysInherit

SuperArea

 

SupplementalDataContainedObject

AlwaysInherit

MyObject

 

TSContingencyElement

AlwaysInherit

TSContingency

 

TSPlotSeries

AlwaysInherit

TSPlot

 

TSPlotVertAxisGroup

AlwaysInherit

TSPlot

 

TSSubPlot

AlwaysInherit

TSPlot

 

VSCDCLine

YES

From/To_Bus>Substation

 

ZoneContingencyReserveBid

AlwaysInherit

Zone

 

ZoneOperatingReserveBid

AlwaysInherit

Zone

 

ZoneRegulatingReserveBid

AlwaysInherit

Zone