Asset Health FC Work Items and Issues, 18 Oct 2013

Asset Health FC Work Items and Issues, 18 Oct 2013

Asset Health FC Work Items and Issues, 18 Oct 2013

Item / Description / Status
AH01 – Measurements – Enhancement to support asset health / - How to represent time series data? I think there needs to be a basic exploration/understanding ofthe ways in which the existing CIM model supports data that varies over time. Then we should look at how that basic approach applies to asset health time series data. Our Focus Community has good and interesting requirements to bring to the table on this discussion – for example how the CIM model and anticipated deployments are seen to support the following “data varying over time” scenarios:
- the movement of an asset from one network location to another
- multiple copies of the same type of document
- MeasurementValue.value values that vary over time
- How best to use measurementType?<there are discussions on code lists related to Measurement unit symbols going on in the joint WG13/14 space that have bearing on this> / To be brought up for discussion during WG14 modeling calls on measurement.
AH02 – Measurements – Harmonizing 61850 data / - CIM should be able to bring in 61850 data without losing any information.
- Need only a subset of 61850 data for CIM – i.e., the measurements needed for asset health assessments.
- The CIM-61850 harmonized measurement data should be tied to the asset. <this item is also part of AH04, in my mind>
- When the asset moves to a different location, the historical asset health-related CIM-61850 data should be able to move with it.the “moving asset” part of this item is also related to the first question in AH01 – how the CIM supports data that changes over time. Aside from CIM modeling, it sounds like there is also an “inside the 61850 world” issue around moving assets. And then there is the question of harmonizing the CIM and 61850 ways of handling the situation. / Preliminary use case provided to CIM-61850 Harmonization task force Oct 2012, to be taken up by them, timeline TBD.
AH03 – Measurements and Documents – Gathering measurement data together / Should be able to group together like measurement data. For instance:
- One type of measurement data (e.g., DGA) over a period of time.
- Different types of measurement data during a lifecycle stage (e.g., factory acceptance test)
- Different types of measurement data from a single activity (e.g., trip to the field) agree that values of those types need to be grouped, butwhether the individual values are actually Measurements or not is not yet clear to me.> / AHFC to provide requirement and prelim models.
AH04 – Measurements and Documents – Associating data to assets / Efficiently and accurately associate measurements to assets.
is this about something more than the CIM association between Measurement and Asset? Maybe about how to best leverage the Measurement to Asset relationship in conjunction with the Measurement to PSR and Terminal relationships? / AHFC to provide requirements and prelim models.
AH05 –Asset/AssetInfo –Modeling Bushing, Oil, etc. / - Model salient properties of asset components that are relevant information for asset health analytics.yes, we need the “skeleton” off of which all the needed information (nameplate, test results, real-time data, inspection results, maintenance history, etc.) can be hung. There is probably a part of this work that involves cleaning up the AssetInfo classes and also a part that involves suggesting the instance models that would support various types of specific assets. Important work to dig into once the DGA modeling is finished.
- Asset components also need their measurements associated with them? <just checking to be sure I understand… this item refers to the fact that individual Asset instances (that have been “Lego’d” together to represent a complete asset) will themselves be the objects to which Measurements will be associated. / AHFC to provide requirements and prelim models.
AH06 –Analytics –Modeling Analytics System outcome / Analytics score, recommendation, etc. needs to be modeled since these are analytics outcomes that will be provided to other systems<yes… this work needs to be driven by input from utility asset management folks, control centers folks and field maintenance folks, I would think. It would also benefit from dialog with analytics vendors (who will be understandably concerned about exposing too much of their competitive edge). I would think that this work could be done by type of asset, and would logically follow getting the “skeleton” model done for a type of asset. I see a back and forth design process between organizing the raw data for a given type of asset and defining the analytics outputs for that type of asset.> / AHFC to provide requirements and prelim models.