Contents
Notes from the WG14 modelling call discussion related to measurement profiles (2012-12-04):
Notes from the WG14 modelling call discussion related to measurement profiles (2012-12-11):
Notes from the WG14 modelling call discussion related to measurement profiles (2013-11-12):
Notes from the WG14 modelling call discussion related to measurement profiles (2013-12-10):
Notes from the WG14 modelling call discussion related to measurement profiles (2013-12-17):
Notes from the WG14 modelling call discussion related to measurement profiles (2014-01-21):
Notes #1 (2014-02-10) from the Metering/Measurement enums TF:
Notes #2 (2014-02-17) from the Metering/Measurement enums TF:
Notes from the WG14 modelling call discussion related to measurement profiles (2014-02-18):
Notes #3 (2014-02-24) from the Metering/Measurement enums TF:
Notes from the WG14 modelling call discussion related to measurement profiles (2014-02-25) = Notes #4 from the Metering/Measurement enums TF:
Notes from the WG14 modelling call discussion related to measurement profiles (2014-03-25) = Notes #5 from the Metering/Measurement enums TF:
Notes from the WG14 modelling call discussion related to measurement profiles (2012-12-04):
AI all (2012-12-04): Please review draft in one of two formats, as you prefer:
html page per profile:
Or full CIMTool project, including html, owl, rdfs and xsd: )
- Started looking into .xsd-s (visually easier to show and discuss).
- Please have a look at the included .docx document, with many open questions (and some design notes).
- Timestamp should be optional (in case it's the same for a set of measurements). Note that in IEC 61850, timestamp is normally mandatory.
- (after the call) Kendall: 61970-451 configuration part might need an initial value on MeasurementValue. On system startup, this kind of thing is usually needed, for example to supply a value before the measurement is available from the field source.
- Didier: We should have multiple {value, timestamp, quality} per MeasurementValue subtype, if MeasurementValue identity is fixed. This would allow modelling multiple values of the same thing at different times.
- Tanja: In XML compliant with XSD, we can supply any number of instances with the same mRID and different values/timestamps. Don't know about RDF instance?
- Didier: This sounds like extension at the profile level, because we now state that a measurement value may have multiple {value, timestamp, quality} in a data exchange.
- Should we change UML by grouping {v, t, q} into e.g. one <Compound> per type, then support multi-valued attributes?
- Pat: The question of time and timestamped values and/or e.g. network model snapshots is still not clear how to model, and utilities have different requirements.
- In WG14, we have e.g. ConfigurationEvent class associated to almost everything (Location, Asset, UsagePoint, Organisation, Document, …); This is just for configuration changes.
- For real time data exchanges, we have explicit message payloads / profiles defined (e.g., EndDeviceEvents and EndDeviceControls). These would be close counterparts of the above MeasurementsAndControls.
- Was very interesting initial discussion on draft profiles; continue next week (if sequence diagrams for planned outage not ready).
Notes from the WG14 modelling call discussion related to measurement profiles (2012-12-11):
Continued with measurement profiles discussion.
Created samples for TelemetryConfig (left) and MeasurementsAndControls (right).
For configuration, there is no controversy; existing CIM model and instances we would create and exchange seem ok. We would probably need to add here still relation to Asset and Location, because these also have Measurement associated. We would use this profile for any configuration of telemetered and controllable items, wherever it comes from (ICCP, RTU protocol, 61850, application-deduced, operator-replaced, etc.). This would be a kind of "CIMmificator" for data exchange among enterprise systems where we don't really want to bother with low level industry-specific, binary comm protocols (although, we could probably use this also for communication with the process in many cases…)
It is important to understand that one CIM Measurement (Analog UUID1) may have a number of MeasurementValue-s associated (AnalogValue UUID2 and AnalogValue UUID3), each MeasurementValue being an identifiable object on its own. In the above example, we have the first value coming from source ICCP1 and the second one coming from ICCP2. The third value could be added, with the source MyApplication. All of them "point" to the same Analog measurement. Each of them has an identity.
(Note: mRIDs are of course UUIDs, but I couldn't bother during the call to type them by hand…)
Let's move now to the right, with the dynamic data exchange of {value, timestamp, quality} – that I'll abbreviate with {v, t, q}. Notice that in this profile, we would like to allow for exchange of not only a single value per MeasurementValue, but also multiple instances, e.g., with different timestamps. Think of a phasor measurement. Or of a scan of RTU/ICCP data with some hickups where multiple values for the very same data point are given, but for different timestamps (say, now-3sec, now-2sec, now-1sec) and you want to simply ignore the obsolete two; or do some reasoning on those values so as to assign quality, or whatever. By extension, if we support that, we could use the very same profile to exchange the "regular" time series data, as usually stored in historians. If would probably be a total proliferation of profiles to define one with single, and one with multiple values allowed.
In the upper right pic, we show a sample instance payload that would be compliant with the XSD: namely, two "blocks" of AnalogValue UUID2 with different values and qualities at two different points in time. However, if we were to provide an RDFS equivalent for this profile, we could not express that, because in RDF instance, we couldn't put an item with the same UUID (rdf:id) twice. In the previous call, Didier suggested that if we allowed for this, then it would mean that we're implicitly modifying CIM, by allowing the AnalogValue to have multiple AnalogValue.value, AnalogValue.timeStamp and AnalogValue.quality attributes, which is NOT the case in CIM.
In XSD syntax, we don't have any explicit identity constraints bound to mRID or anything else (although there may be implicit / hidden assumptions, that pair with the RDFS view). It is understandable to want to ensure globally unique identifiers for configuration (like where you'd use 'create/created' verb) to ensure the entities are not duplicated, but this does not seem to be an explicit requirement in XSD dynamic profiles (like where you'd use 'change/changed' verb). Do we want to reinforce that?
We seem to have agreed that we don't necessarily need to always have RDFS counterpart of profiles, in particular for the dynamic payloads where XSD is really the mainstream and supported by the tools. So, the discussion here is really about the pure semantic of CIM and how we map it to the profiles.
Would it be enough to give in text the description of what may be expected (like multiple occurrence of a given UUID)? Could we leverage some of elements in the Message.xsd envelope?
We would also have an option to modify CIM so as to be able to "cleanly" produce what we want, as shown in the right lower pic above. In this constellation, we would have a single instance of AnalogValue with UUID2, that would then contain one or more triples {v, t, q}. This would mean the need for:
- 4 new compounds (one per MeasurementValue subtype), and,
- agreement about usage of multi-valued attributes, and their mapping to serialisation formats (in XSD, it's natural; no idea about RDFS).
Of course, this would mean also change to CIM – some may not be happy about this (which is also understandable).
Question here is, however, don't we want to try to find a way to deal with time series in a way that does not require this kind of change in the UML?
This was a very interesting discussion to close the WG14 modelling calls series for 2012, thanks to all for your contribution! We'll continue on January 8.
Notes from the WG14 modelling call discussion related to measurement profiles (2013-11-12):
- questions about harmonising "native" CIM Meas::Measurements model with: (a) DCIM metering (Reading, ReadingType) and (b) IEC 61850 model
- weather model needs a whole set of new measurements
- participants wanted we start discussing harmonisation / unifying matters first
- base CIM simple measurement model, attached terminal/PSR gives the context; big difference with 61850, which has detailed signal names as data objects (DOs) within logical nodes (basic IED functional blocks accessible through communication)
- we looked into ReadingType class (IEC61968::Metering) and the planned (still INF) enumeration types, and compared with the base CIM counterparts
- ReadingType attributes {measurementKind, phases, multiplier, unit} could be consolidated with Measurement attributes (measurementType, phases, unitMultiplier, unitSymbol}
- problem 1 (for WG14): enum types defined for metering have codes (integer values in addition to the string literals), and that's why we have been blocked to make those enum types normative since several years
- problem 2 (for WG13): another question is that of the content in the metering enums; they are more exhaustive than those in base CIM (note about ExtPhaseCodeKind: the 'funny' ones at the end, like AtoAv is for angle difference / power factor measures).
- if we resolve the above two issues, we could start by moving the relevant attributes into one (abstract) superclass for Measurement and ReadingType and have a single set of unified enum types for at least 3 attributes (phases, unit, multiplier).
- additional mismatch we have is that (a) in metering, ReadingType is associated with a Reading(Value, inheriting from MeasurementValue), while in base CIM that measurement meta-data would be associated rather with the Measurement (and not MeasurementValue). But this is to discuss.
- would Reading (metering model) be counterpart of base CIM Accumulator? Until some years ago, yes. Nowadays, no. Smart meters are like IEDs, DCIM model supports moderns devices in all their aspects, not only as industrial energy meters typically found in HV substations.
- Are we saying we would have measurement type as enum? We don't know yet. As always, there are pros and cons with enums.
Notes from the WG14 modelling call discussion related to measurement profiles (2013-12-10):
Continued discussion on harmonising "native" CIM Meas::Measurements model with: (a) DCIM metering (Reading, ReadingType) and (b) IEC 61850 model
We could better factor common measurement type-related attributes by moving those into a common base class (CommonMeasType in the pic above). To do this, we would first need to ensure that we have fully harmonised the existing base CIM enums with those planned for use in metering (DCIM, Metering, ReadingType). We've seen three of those in the previous meeting, another one is shown above in yellow. Combination of MeasurementKind and PhaseCode give the possibility to express virtually anything, and not be restricted to the "normative strings".
The pic below summarises the list of all the metering enums around reading type, currectly INF (because only strings are used; we were blocked to introduce enums with labels).
The change for the base CIM here would be that the attributes related to measurement type are not anymore instance attribute of Measurement, but can be shared among many instances of Measurement through relation to the CommonMeasType (from above).
Important to note:
The pic below shows the profile using ReadingType (61968-9). Note that the attributes are all optional – they could be used just for configuration, which gives more semantic. In the operational data exchanges, only the instance with its Names.name is exchanged.
If we can agree on using our still INF enums, the type for most of the ReadingType attributes will change from a String to the relevant enum type.
Notes from the WG14 modelling call discussion related to measurement profiles (2013-12-17):
See comments with Sample 1: and Sample 2: in the screenshots below.
We discussed about quality definition and its adaptation to be a compound (instead of how it's defined now).
We made an exercise of adding the means to specify multiple triples {value, timestamp, quality} (will call them {vtq}) to the existing CIM Measurement model. See pic below.
It would require to:
- define additionally 4 new compounds (one per MeasurementValue subtype) and add an attibute [0..n] values. Note: name AnalogueReading is not recommended (don't want to mix with meter readings).
- agree to allow multi-valued attributes in CIM (open combined issue 1126).
Note that this potential solution does allow for smooth transition from the existing model to something that would semantically support time series of measurements. However, we are polluting the model with unnecessary redundancy.
(added after the call) We should maybe give another name for the new 'AnalogValue.values' and mark it as deprecated, for in the future simply changing the type of an existing 'AnalogValue.value' from Float to AnalogueReading?
- various measurements exchange patterns: per device, per time stamp, per measurement kind, at change, one point over time
- plus all the various protocols (RTUs, PMUs)
- these all are relevant queries for the base CIM MeasurementValue-s.
The pic below shows the existing time series model for meter readings; this seems to be specific usage for meter readings. Note that here, every reading will get a new mRID (which is different from how MeasurementValue is intented to work).
Notes from the WG14 modelling call discussion related to measurement profiles (2014-01-21):
Measurement clean-up effort: WG14 asked to provide 2-3 more volunteers; Tanja to coordinate.
WG13:
Kendall Demaree
Lars-Ola Osterlund
Chuck DuBose
Pat Brown
(GowriRajappan)
WG14:
Tanja Kostic
Margaret Goodrich
Marty Burns
WG16:
Pat presented environmental (measurements) model.
- This model is, at present, not yet integrated with the WG16 model (and not reviewed), but we're discussing measurements right now, which is a perfect timing.
- model draft with environmental extensions: <
- May need to bring in Measurement (instead of just inheriting from AnalogueValue; this approach was similar to MeterReading, that inherit just from MeasurementValue, and ignore Measurement). Do we need to reconsider what the Measurement is for?
- The *Set-s: Do we need this as a CIM class (answer would be yes if need the identity of that set)? Or, could we simply have a profile that contains everything that would be in a set, and leverage Message.Header for intervals (as we sometimes do with meter readings)?
- There are some enums for statistical and uncertainty information; this will need harmonisation with 61850 (the harmonisation TF's MeasurementType discussion).
- WG13 may take a look at this model next week; we all continue joint discussion.
Gowri briefed us with some aspects of measurements as used for asset health; we discussed on the way:
- Connection of Measurement with Asset and / or PowerSystemResource (PSR).
- Asset health gives requirements on how to deal with the link between functional (PSR) and physical (Asset) model.
- If Measurement linked (shared by) to both PSR and Measurement, what happens when the asset changes? Measurement goes with the physical and the link to PSR must be updated.
- Asset health related measurements go with Assets, not with PSR.
- Some PSRs will need some (aggregated) measurements. Do we need to distinguish them?
- Is CIM Measurement only for SCADA or a SCADA-like system? No.
- A measurement can sit on both functional and physical (e.g., loading on the transformer).
- What is the meaning of MeasurementSource? SCADA or ICCP are not really sources, they are providers, but a typical EMS considers them as source. What is the meaning of source if measurement and value are used outside the typical EMS application? Do we need both source (physically, where the sensor sits) and provider(s) / "forwarder" (who is my immediate source of value)?
Notes #1 (2014-02-10) from the Metering/Measurement enums TF:
Objective: to address enumerations we have twice, to finally come to:
a) either a harmonised model, or,
b) to acknowledge we keep two or more models (of measurements / readings enumerations.) in the CIM.
Intent is to have 4 x 1h web conferences, starting the week of Feb 10, and resolve this pending problem once and for all (in the foreseeable future :-).
Participants:
*
*
*
*
*
*
()
This is the first out of max 4 calls dedicated to the 4 potentially shared enum types, used for IEC61968::Metering::ReadingType as well as throughout IEC61970 model, but specifically for IEC61970::Meas::Measurement & related classes:
- phases
- currencies
- unit symbols
- unit multipliers
Look at the diagrams under IEC61968::InfIEC61968::Sandbox::SharedEnums in this informal model - I've just merged Marty's contribution for DCIM metering enums, and created diagrams in our Sandbox:
<
I leave measurement type for later on - we'll take up this with the overall measurement / reading modelling on the regular Tuesday calls, starting Feb 11.
I also leave out the aggregation type/kind - the same comment as above; in addition, this may be relevant in the context of harmonisation CIM-61850.
Becky/Margaret, I haven't got the volunteers from WG16; please forward the invite if anybody wants to join and let me know to update my list - thanks.
For completeness: we are handling specifically these combined issues:
c-039: Enums with integer values for metering.
c-070: Complete the Currency enumeration list
c-103: Environmental units and multipliers.
Agreed to move enum literals of Ext… UnitMultiplier into base CIM UnitMultiplier. Adapt doc. Sort order like 61850.