Meeting on 17 March 2015

Meeting Attendees:

Pat Brown Henry Dotson David Haynes Chris Kardos Svein Olsen Gowri Rajappan Greg Robinson Tomasz Rogowski

Meeting Agenda:

Meter reading model.

Discussion Summary:

For meter, started by collecting use cases. What has to be exchanged (CIM classes)? The readings are exchanged as MeterReadings payload. MeterReading contains

Readings, which consist of value, ReadingQualities, ReadingType, etc. ReadingQuality concept could be used to distinguish between online vs laboratory

etc. ReadingType is typecast as string, has 18 attributes, has many constructs around

time, such as time intervals, statistical qualifiers like average, etc. Annex C of 61968-9 has more description. This 18-part string becomes the Names.name for the ReadingType.

The ReadingType within Reading in MeterReadings is included by reference. The units enumeration in 61970, did they harmonize with 61968-9? The 61968-9

added to the 61970 units enumeration and over time may have diverged. Is it possible to inherit from enumerated classes? If so, could be a good way of, once

harmonized, maintaining things going forward. Metering time constructs: Interested in both current value (energy) and over time

value (kW-Hr). Able to express intervals as well as average over time (sliding window).

Grouping of Readings is not there yet, we’ll have to come up with as a layer on top – similar to EnvironmentalValueSet.

Limits and alarms associated with measurements are modeled as EndDeviceEvents. EndDeviceEventType has enumerations similar to ReadingType. isCoincidentTrigger relates Reading to EndDeviceEvent.

MeterConfig profile with root class Meter has all the attributes corresponding to the meter.

Real meter vs. virtual meter: ServicePoint (demarcation point where homeowner owns everything downstream and utility owns everything upstream) vs UsagePoint. But want to able measure things at points other than demarcation point, such as power at a feeder, for which UsagePoint was created. UsagePoint has a ServicePoint flag that indicates whether it is also a service point.

Don’t need a Location for UsagePoint.

Meeting on 31 March 2015

Meeting Attendees:

Pat Brown Henry Dotson Gerald Gray David Haynes Chris Kardos Svein Olsen Gowri Rajappan Tomasz Rogowski

Meeting Agenda:

Meter reading model – continuation.

Discussion Summary:

Some features of meter reading appealing to address asset condition requirements, such as enumerated attributes, being able to indicate source of data, time concepts such as sliding window.

As an example, oil attributes for DGA can come from online monitoring, lab test, field test with a portable analyzer, or factory test.

Reason: why was the reading taken? Source in BaseReading: where is the reading coming from.

MeterReading and Reading? MeterReading collects Readings? They have a many-to-many relationship.

When timestamp in MeasurementValue is populated, it overrides the others? MeterReading is a collection of individual Readings. How does part 9 handle peak and average? That’s within ReadingType –

macroPeriod would be the averaging period, aggregate would be min/max/average etc.

First edition has 11 attributes for ReadingType, but this resulting in same attribute being used to indicate more than one dimension. This was rectified in the subsequent edition by increasing to 18 attributes. Have been happy with how ReadingType has shaped up, including the shorthand notation.

Commodity vs. kind attribute in ReadingType: Commodity is the category & kind is the specific measurement. For instance electricity is a commodity & voltage is a kind.

The intentions of Part 9 ReadingType enumeration is to be a superset of what’s out there including 61850, since revenue metering has many esoteric details not found in SCADA measurements.

Maybe subclass MeterReading to describe context metadata, like sample details, date, lab details etc.

If don’t need all the attributes in ReadingType, could compose the ReadingType.name string with only the attributes we need, so it won’t have to be an 18-part string.

BaseReading.value is a String. Is this used also for float and integer data? Yes, wanted one type to capture all data, including ISO 8601 date-time value. String seemed to be a good type because it can accurately capture the information, so everything is typecast to string.

o In the first edition, everything was float, but it introduced rounding errors.o EXI (Efficient XML Interchange) works best if the types are explicitly broken

out, so may have to revisit this.

Pat’s Notes:

Online monitoring has both instantaneous and averaged values

MeasurementValue.timeStamp overrides other time information

BaseReading.timePeriod is for individual readings

MeterReading.valuesInterval is a way of grouping readings and can be used to apply to all Readings taken at a certain time

ReadingType.macroPeriod defines period

ReadingTypd.aggregate is statistical operation

.commodity would be “variable”

.kind is related to “variable” – further describes what appears in commodity

.measuringPeriod is time chunking

Svein - What do you like about -9, what would you have done differently?

Chris – likes leveraging name for doing “.” delimited ReadingType attribute First edition had 11 attributes and some of them were being used for more than one concept – needed to break them out, so then 11 expanded to 18, maybe in next edition may have to have a 19th

Dave – one of the benefits in the “.” separated list is that the enumeration lists can be translated into various languages

Jerry – yup, Dave & Chris are the experts

Some of attributes of ReadingType may be filled in by a MDMS or Head End, some by meter (depends on intelligence of meter)

In first example that David showed us on spreadsheet

electricitySecondaryMetered power phaseC kVAr

electricitySecondaryMetered - .commodity

power - .kind

phaseC - .phases

kVAr - .units, .multiplier

Example for ch4 “variable” for asset health

indicating ch4 (micro L/L)

indicating - .accumulation

ch4 - .commodity

micro - .multiplier

L/L - .unit

David – history of modeling of currency – started it off as generic, but found it needed to be explicitly identified – is not part of unit of measure – is its own enumerated list – wanted to leverage a list maintained by other entity – made it a separate attribute

At the beginning, intent was to take 61850 description of characteristics of data ‘types’ and create a superset

Use of string

when folks went to implement Edition 1, had XML issues with float, so moved to string in Edition 2

string is used when the content of value is variable (sometimes a date, sometimes an analog)

AI - Dave will send Gowri the Names.name value calculation spreadsheet

Meeting on 28 April 2015

Meeting Attendees:

Pat Brown Henry Dotson David Haynes Chris Kardos Gowri Rajappan Tomasz Rogowski

Meeting Agenda:

Meter reading model – continuation.

Discussion Summary:

Period of time a reading is valid for. Statistical model used in assessing that. Bushing monitoring: powerFactor (daily)

o cumulative and continuousCumulative are very specific meter concept that is done in response to regulations; indicating or summation might be the appropriate value.

o Aggregate vs. accumulation – the latter to provide clues to the recipient on how it on display. Is it like a speedometer (indicating) or odometer (rolls over).

o macroPeriod is 24 hrs starting from midnight; if want an arbitrary 24 hrs, may need new value called 24hrs. The timestamp of the Reading is the end of the 24 hour period.

o Is it useful to know the number of readings that went into the average? Probably not. But if needed, the 3rd position can be used to indicate the periodicity of averaged quantity – i.e., measuringPeriod = sixtyMinute.

o specifiedRollingBlock (measuringPeriod). Gas ratios.

o Unitless, but if need to be more descriptive, could create a new value for position 17 (unit) called gasRatioUnit, which would be dimensionless but would indicate it’s a volumetric concentration ratio. See value 65, Power factor, which is dimensionless. Or perhaps volumeRatio and massRatio as new dimensionless values for unit.

Power factor @ reporting temp.o If measured at arbitrary temps & the temperature reported, that would be a

separate reading. On the other hand if the reading is standards based as in very specific temperatures, would create specific position values.

o In metering world, there is a concept called coincident reading. It could be extended to include case where PF of x is coincident with temp of y.

Some Thoughts on Applying Reading/ReadingType to Asset Condition Test/Measurement Data (14 April 2015)

DGA:hydrogen in ppmo From Lab: h2 volume (μL/L), 0.0.0.0.0.26.58.0.0.0.0.0.0.0.0.-6.143.0

InsulativeOil h2Concentration (μL/L), 0.0.0.0.0.6.500.0.0.0.0.0.0.0.0.-6.143.0 Value 0 (in position 3, measuringPeriod) = none Value 6 (in position 6, commodity) = InsulativeOil Value 500 (in position 7, kind) = h2Concentration Value -6 (in position 16, multiplier) = micro Value 143 (in position 17, unit) = L/L

o From online monitor: thirtyMinute h2 volume (μL/L), 0.0.5.0.0.26.58.0.0.0.0.0.0.0.0.-6.143.0

Would be the same as Lab. Difference indicated in Reading.source.

“When comparing gas variables, have to ensure same reporting temperature or do gas law calculation to normalize for reporting temp.” How do we account for this? MeterReading (or a new subclass of this) providing reporting conditions, which applies to all the Readings aggregated by the MeterReading subclass?

Add commodity enumerations for each of the other gasses, furanic and trace metal variables?

What about if dissolved gas ratios need to be exchanged as well? Need to add commodity enumerations for ratios such as co2/co and co/co2?

For fluid test variables, the “commodity” is insulativeOil:o For powerFactor: insulativeOil powerFactor (c), 0.0.0.0.0.6.38.0.0.0.0.0.0.0.0.-2.0.0

Not able to express temperature, as in powerFactor25C and powerFactor100C. Just have multiple “kind” for powerFactor?

The unit is percent. Is the appropriate expression centi for multiplier and none for unit?

For transformer offline testing, power factor can be measured between various points. For instance, CHL for PF measured between high and low side bushings, CH between high side bushing to ground, CL between low side bushing and ground, etc. How do we indicate that? Are these new “kind” enumerations also? Might be the most straightforward thing to do.

o For most of the rest of the fluid test attributes, need to add “kind” attributes. Test/measurement data that are waveforms: e.g., SFRA and PD are frequency response;

circuit breaker time and travel measurements are a time waveform.o Can we create a new sub-class of BaseReading called VectorReading with the

following attributes? values: String[0..n], abscissa, and abscissaKind. Source attribution and provenance data.

o Use Reading.source to indicate what system it came from. Quick indication of whether it’s online measurement or lab etc.

o Make a sub-class of MeterReading called AssetConditionData. This class will have attributes such as a compound for “labDetails,” a compound for “fieldDetails,” a compound for “monitorDetails”?

Some More Thoughts (24 April 2015)

ReadingType:o Several new values for the commodity attribute. For instance:

insulativeMedium or insulativeSystem when the commodity being tested is some combination of oil, gas, cellulose, air, vacuum;

asset when the test article is the Asset to which the Reading pertains (have to resolve the fact that Reading doesn’t associate to Assets right now – perhaps subclass & associate to Asset) – an example is SFRA or Partial Discharge or inspection.

o New values for the measurementKind attribute. For instance: h2Concentration, co2Concentration, furfuralConcentration,

aluminiumConcentration, etc. – all the oil analysis concentrations. gasRatio. acidNumber, interfacialTension, etc. – the oil analysis non-

concentration miscellany. particle4To6, particle6To10, etc. – the particular counts.

o New values for argument numerator and denominator. To express gasRatios (co/co2, co2/co, etc.)

o A new pair of arguments to describe how a test instrument is connected. connection1-connection2. For instance, high-side/low-side for measurements taken between

high and low sides; high-side/ground for measurements taken between high-side and ground, etc.

Grouping readings that “belong together,” like the various results from one transformer offline power factor test or DGA results or Trace Metal results or Inspection results.

o Subclass MeterReading, called AssetConditionData. Use this subclass to group together readings. AssetConditionData has an enumerated attribute called dataKind, which lists out the different categories.

New metadata classes to describe lab conditions, field conditions, etc. o An IdentifiedObject called LabMetadata (?), with attributes of repeatability,

reproducibility, precision, bias, and detection limit. LabMetaData has a one-to-many association with Reading.

o An IdentifiedObject called FieldMetadata (?), with attributes that describe the field conditions, such as temperature, etc. (need to identify the attributes)

FieldMetaData has a one-to-many association with Reading.o An IdentifiedObject called InstrumentMetaData (?), with attributes

describing the test instrument (need to identify the attributes). InstrumentMetaData has an one-to-many association with

EndDevice (or a subclass of EndDevice for test/online monitoring instruments).

Test/measurement data that are waveforms: e.g., SFRA and PD are frequency response; circuit breaker time and travel measurements are a time waveform.

o A new sub-class of Reading called VectorReading with the following attributes? values: String[0..n], abscissa, and abscissaKind.