49
Meeting Minutes, 2014 Asset Health Focus Community Table of Contents Meeting on 7 January 2014............................................ 2 Meeting on 15 January 2014........................................... 3 Meeting on 21 January 2014........................................... 4 Meeting on 22 January 2014........................................... 6 Meeting on 4 February 2014........................................... 7 Meeting on 11 March 2014............................................. 7 Meeting on 18 March 2014............................................. 8 Meeting on 25 March 2014............................................ 10 Meeting on 1 April 2014............................................. 11 Meeting on 15 April 2014............................................ 12 Meeting on 22 April 2014............................................ 13 Meeting on 29 April 2014............................................ 13 Meeting on 6 May 2014............................................... 14 Meeting on 13 May 2014.............................................. 20 Meeting on 20 May 2014.............................................. 22 Meeting on 27 May 2014.............................................. 31 Meeting on 3 June 2014.............................................. 32 Meeting on 24 June 2014............................................. 33 Meeting on 1 July 2014.............................................. 34 Meeting on 8 July 2014.............................................. 36 Meeting on 15 July 2014............................................. 37 Meeting on 22 July 2014............................................. 38 Meeting on 29 July 2014............................................. 39

Meeting on 7 January 2014 - UCAIugcimug.ucaiug.org/Focus_Comms/AssetHealth/Public Doc…  · Web viewMeeting Minutes, 2014. Asset Health Focus Community. Table of Contents. Meeting

  • Upload
    lyhuong

  • View
    215

  • Download
    2

Embed Size (px)

Citation preview

Meeting Minutes, 2014Asset Health Focus Community

Table of ContentsMeeting on 7 January 2014.........................................................................................................................2

Meeting on 15 January 2014.......................................................................................................................3

Meeting on 21 January 2014.......................................................................................................................4

Meeting on 22 January 2014.......................................................................................................................6

Meeting on 4 February 2014.......................................................................................................................7

Meeting on 11 March 2014.........................................................................................................................7

Meeting on 18 March 2014.........................................................................................................................8

Meeting on 25 March 2014.......................................................................................................................10

Meeting on 1 April 2014............................................................................................................................11

Meeting on 15 April 2014..........................................................................................................................12

Meeting on 22 April 2014..........................................................................................................................13

Meeting on 29 April 2014..........................................................................................................................13

Meeting on 6 May 2014............................................................................................................................14

Meeting on 13 May 2014..........................................................................................................................20

Meeting on 20 May 2014..........................................................................................................................22

Meeting on 27 May 2014..........................................................................................................................31

Meeting on 3 June 2014............................................................................................................................32

Meeting on 24 June 2014..........................................................................................................................33

Meeting on 1 July 2014.............................................................................................................................34

Meeting on 8 July 2014.............................................................................................................................36

Meeting on 15 July 2014...........................................................................................................................37

Meeting on 22 July 2014...........................................................................................................................38

Meeting on 29 July 2014...........................................................................................................................39

Meeting on 7 January 2014

Meeting Attendees:

Pat Brown Herb Falk David Haynes Matt Kennedy John Moseley Svein Olsen Gowri Rajappan Susan Richter Greg Robinson Tomasz Rogowski Terry Saxton John Simmins

Meeting Agenda:

Work for 2014. Analytics System process/outcomes.

Discussion Summary:

Measurement-related AHFC tasks are being addressed elsewhere (WG14 meetings & CIM-61850 harmonization task force). These efforts are taking into account the requirements generated at AHFC. In the next several meetings, we will focus on work item AH06 on defining Analytics System.

Terry: Need to present on AHFC work at CIMug Meeting in Melbourne – Gowri will be attending and can do this.

Herb: Location is being discussed in CIM-61850 harmonization, as for how to treat the location from where data is acquired. There is discussion on measurementType as well, which will be a topic of discussion during the Palo Alto WG13 meeting. As part of MeasurementType resolution have had discussions about adopting “calc methodology” and “calc interval” parts of 61850. Will share a document on this.

Pat/Gowri: The requirement we have is more on the physical location of the asset. Gowri: Perhaps one place to start on the AH06 task is to identify the analytic system outcomes. Discussion of 61968-6 IRM interaction diagram and where analytics system fits within this.

This turned out not to be a good starting point, so backtracked to sequence diagrams developed in AHFC for guidance on where this kind of use of analytics output might be used. Then brought up the DGA surveys.

Pat: Where does asset health analytics system outputs go?o Work order / work management (61968-6).o Asset planning/management systems (ranking for maintenance, watch lists for

increased inspections or monitoring, ranking for replacement, etc – 61968-4?)o Operations ((“asset at risk”, derating of asset limits, increased probability of failure –

inputs to various visualization or power flow analytics applications) – 61970? Interactions with work order / work management. From the DGA survey responses, it appears

that scores and implications coming out of the analytics system would feed into work mgmt..? Pat/John: EPRI has many experts and venues who could be leveraged for such a requirement-

gathering exercise. Will investigate. Pat: Would be useful to pull together the pertinent DGA survey responses and available EPRI

material to seed the analytics discussion in next meeting. Pat will pull together list of Operations uses for asset health insight. Gowri will extract “where does the data get used” information from DGA surveys.

Meeting on 15 January 2014

Meeting Attendees:

Tom Berry Pat Brown Margaret Goodrich Tanja Kostic Svein Olsen Gowri Rajappan Greg Robinson

Meeting Agenda:

TC57 experts meeting for asset health.

Discussion Summary:

Areas of work for TC57 modeling experts:1. Modeling asset and asset component (using Asset and AssetContainer classes).2. Use of AssetInfo and its child classes.3. Asset life cycle stages.4. Modeling procedures and procedure results.5. Same/similar data from multiple sources (e.g., online vs lab).

Some of the above already being handled in Tanja’s measurement calls & CIM-61850 harmonization,

Regular calls with modeling experts outside of the Asset Health Focus Community calls. Phone calls every other week (in between AHFC meetings), 10-11 US Eastern, on Tuesdays, with

the TC57 modeling experts. This way, the AHFC calls can focus on requirements and this other call with modeling experts

can focus on solutions.

Meeting on 21 January 2014

Meeting Attendees:

Mark Easley Tanja Kostic Svein Olsen Gowri Rajappan Nada Reinprecht Greg Robinson Tomasz Rogowski Terry Saxton Luc Vouligny Frank Wilhoit

Meeting Agenda:

Asset lifecycle – data produced and analytic assessments made throughout the lifecycle.

Discussion Summary:

Discussed asset lifecycle stages and how they relate to asset health analytics. Six stages: Asset Planning, Asset Procurement, Asset Installation, Asset Brought into Service,

Asset Removal, and Asset Retirement. Asset lifecycle considerations are beyond the scope of asset health. 61968-4 deals with some lifecycle aspects. During the Asset Planning stage, asset maintenance history is also typically taken into account

(e.g., for the particular model), and this is something that might be expected from an asset health analytics system – i.e., reliability study that is used for asset planning.

The informative class GenericAssetModelOrMaterial is means for planning purposes. AssetModel & AssetInfo generally created for Asset Procurement. For assets that are found in

relatively large numbers such as pole-top transformers, AssetModel may already have been created from prior procurements.

For Asset Installation onwards, measurements and work orders come into play. The health-related measurements should be associated with the assets and be able to move

with the asset if the asset if moved (figure below). With the SCADA measurements being associated with the PSR and not with the Asset, this could

be a challenge – moving operational history with the physical asset. Requires duplication. Also, possible that only a summary of the operational history has to be duplicated – e.g., averages, max, min, etc.

Meeting on 22 January 2014

Meeting Attendees:

Pat Brown Tanja Kostic Svein Olsen Gowri Rajappan Greg Robinson

Meeting Agenda:

TC57 experts meeting for asset health.

Discussion Summary:

Lifecycle is a big area and shouldn’t be the focus of AHFC. Revisiting IRM and fleshing out interactions is a better approach. Where should Analytics System reside in IRM? Asset Management – Asset Investment Planning (AM-AIP) seems to have the right description or

very close. This particular subfunction hasn’t seen much work, but from the description would fit Analytics

System. Could be renamed to something more appropriate, perhaps Asset Decision Support (ADS). Develop an IRM interaction diagram similar to 61968-6. Such diagrams are being worked on for

61968-4 (John Simmins) and 61968-5 (Jerome Fremont) as well.

Meeting on 4 February 2014

Meeting Attendees:

David Haynes Tanja Kostic Gowri Rajappan Greg Robinson John Simmins

Meeting Agenda:

Asset health analytics function definition and interactions with other business functions.

Discussion Summary:

Decided to postpone due to poor attendance.

Meeting on 11 March 2014

Meeting Attendees:

Pat Brown David Haynes Svein Olsen Gowri Rajappan

Greg Robinson Luc Vouligny Frank Wilhoit

Meeting Agenda:

1. CIMug Meetings @ Melbourne report.2. Measurements enumeration effort report.3. IRM modifications for asset health.

Discussion Summary:

CIMug Melbourne report (Gowri): Was a productive meeting, majority participants were from Australia, few from NZ, a couple from Asia, and one from Brazil. Most audience not using CIM, but have requirements that CIM addresses, and therefore wanted to find out more. Some of the audience got together to start an Australia-NZ chapter of CIMug.

Measurements enum (Pat): Considerations being given to how things are done both in 61968-9 and 61850. Started with currencies, wrapped up quickly. Moved on to phases – complicated issue, fair amount of dialogue – now done. Unit symbols next focus; there is info in metering, 61970, 61850 all being considered, discussion to start on March 21st. Our contribution may largely be around unit symbols.

Svein: Connection between Asset and PSR. Currently this is many-to-many, which is a problem. There is a proposal to make this one-to-one, which means Assets would have to be aggregated by AssetContainer, which is then associated to the PSR.

Pat: A key work this group can do is templates for different assets. Frank/Gowri/Greg: Agree that this is a good way forward. The templates provide the raw material to construct profiles/messages for the IRM. So this

feeds into the IRM effort as well. Need to re-focus on use cases as well, since they provide the “why” for the “how” that the

templates/IRM show. Action: Gowri to work on use cases (take a look at the use cases from EPRI draft report as well);

and Pat to pull together some initial templates. Next week’s WG meeting to talk about the role of templates; is there a role for such templates

to be provided to the community as Technical Reports? AHFC will be back on bi-weekly schedule.

Meeting on 18 March 2014

Meeting Attendees:

Pat Brown Tanja Kostic Svein Olsen Gowri Rajappan Greg Robinson Tomasz Rogowski

Meeting Agenda:

Asset templates (instance models) and their role in the standard. The following is an example of a specific SF6 breaker.

Discussion Summary:

Tanja: Does is make sense to standardize this at the type level – promote some of the things to information model rather than instance diagram? Can’t standardize instance diagram. But perhaps keep going with the instance examples, which could crystallize into model modifications.

Greg: Good approach to keep going on this path and develop a few examples.

GenericAssetModelOrMaterial – an informative class that is subclass of AssetModel peer to AssetInfo. Look at ElectricalAssets diagram & DCIMAssetsInfo diagram (+ GenericAssetModelOrMaterial class).

What makes sense in terms of connection between Asset and PSR? One would think at the highest level – breaker, transformer, etc. – but components have correspondence as well, such as bushings correspond to terminal? What to do we do?

The connection between Asset and GenericAsset… would be indicative planning aspects of the asset.

Let’s not forget distribution assets – while there may be many unique designs for transmission assets, there is a lot of commonality and scale with distributions assets such as pole-top transformers.

Meeting on 25 March 2014

Meeting Attendees:

Pat Brown David Haynes Gowri Rajappan Nada Reinprecht Tomasz Rogowski

Meeting Agenda:

Breaker asset template. Tanja’s comments for breaker document:

1. “The proposed changes indicated in Figure 2-12 are the ones mentioned above plus the change of multiplicity from 0..1 to 0..* on the AssetInfo end of the Asset to AssetInfo association. This change is suggested to support the possibility that some assets may have both asset-specific and model-specific nameplate information.” The idea of distinguishing instance vs. model *Info is good, but it gives a problem of many on the side of *Info (i.e., non-unique relationship). I would prefer we either:

a. Add relationship AssetModel – Asset for this purpose and keep 0..1 on the AssetInfo for everybody. Asset would then go through its model to fetch the model-specific nameplate data, and would be able to “own” its own instance if required). This means that the existing Asset-AssetInfo relation would be for the instance case exclusively. Or,

b. (probably preferred, because self-describing) add a second relationship [0..1]-[0..1] between Asset and AssetInfo, with different role names, for the instance case. The existing AssetInfo role would be the one shared by many (all with the same model)

and thus “owned” by the model, while the new one would be for the asset instance, for that instance’s exclusive use – if given.

Both of these ensure we still keep [0..1] on the AssetInfo side, to avoid ambiguities.

2. We have an INF Bushing class and a couple more related to bushing tests, mainly for transformer bushings. This needs to be reworked and adapted (to make it useful for both breakers and transformers).

3. I saw on Fig 2-32 instances of AssetLifecycleEvent. That class is a compound and at any one time, the Asset instance has exactly one “set” of values in attributes of AssetLifecycleEvent. But, if we need to track what’s happening in time, we have the class ActivityRecord (generic) and should provide a more specific subtype and link to Asset (thus replacing overly generic relation Asset-ActivityRecord currently in the model; I think this relationship was used in one of metering profiles and people were reluctant to remove it, but we can review the real need and maybe negotiate a subclass with part 9 team J).

Discussion Summary:

Nada: Asset health for Lines etc. as well as non-conducting assets such as poles, towers etc? Pat: Starting w/ transformer, breakers, batteries, cap banks, etc. – assets that have data in

multiple places & people seem to be most interested in applying asset analytics concepts. But the general concept of asset modeling may be more generally applicable to lines and non-conducting assets.

Large data rich assets such as large transmission transformers vs. more numerous but relatively data poor assets such as pole-top transformers.

Once we start with an asset such as transformer/breaker, also consider the smaller, more numerous versions of the asset.

In the case of breakers, once we work through transmission breakers, consider versions at all voltage levels & across the world.

Nada: From experience on developing work mgmt. standards, focusing on one sub-set and delivering something that people could use while we move on to work on the next may be best.

Actions: Focus on breaker next several meetings; set up recurring meeting; propose asset health CIMug webinar for late June/July.

Meeting on 1 April 2014

Meeting Attendees:

Pat Brown Tanja Kostic Gowri Rajappan Greg Robinson

Meeting Agenda:

Discussion of work going forward.

Discussion Summary:

Greg: Have a long Asset Health session on Tuesday during WG13-WG14 meeting. Sketched out next several meetings – focused on breaker template.

Meeting on 15 April 2014

Meeting Attendees:

Pat Brown Gowri Rajappan Greg Robinson

Meeting Agenda:

Planning asset health topics for WG13/WG14 meeting in Brussels.

Discussion Summary:

ISO 55000 asset management standard – we want to track it. This is an agenda item for WG13/WG14 Brussels meeting. Gowri to provide an overview.

Summarize the general principles in asset modeling. Action item for Gowri. Asset vs. AssetInfo. Do we always need an instance of Asset per AssetInfo and vice versa? Multiple instance of AssetInfo per Asset? Procurement person just needs the generic specs to

purchase. We need to have these things clarified for ourselves before we do serious modeling discussions

with AHFC utilities. Folks to involve for asset knowledge: John Simmins, Nada Reinprecht, Jerome Fremont. Send

them an email for Apr 29th. At Brussels, Tuesday or Thursday as breakout? Wed-Friday may get best participation. Have a

significant session Tuesday and a follow-up on Thursday? Half a day on Tuesday.

Meeting on 22 April 2014

Meeting Attendees:

Pat Brown Jon Fairchild Herb Falk David Haynes Svein Olsen Gowri Rajappan Nada Reinprecht Greg Robinson Tomasz Rogowski Carey Schneider Luc Vouligny Frank Wilhoit

Meeting Agenda:

Recap the utility asset analytics environment and the motivating requirements for our work. Review the asset modeling concepts already in CIM. Discuss breaker testing, maintenance and management practices. Identify common breaker types to model. Work on CIM templates for breakers.

Discussion Summary:

Discussion of utility asset analytics environment slides from Pat that were originally presented at CIMug Melbourne 2014 by Gowri.

Email comments from Siri: “I notice that the presentation talks about risk. However I did not see any links to the financial system within the enterprise architecture diagrams. The diagrams are very comprehensive from an engineering perspective. But, asset management is about making decisions and money! Not including financial data - insurance claims, project costs, O&M, capital etc. - in the picture leaves the risk calculations incomplete, at best.”

Meeting on 29 April 2014

Meeting Attendees:

Pat Brown Tanja Kostic Gowri Rajappan

Meeting Agenda:

Circuit breaker asset health work. ISO 55000 Asset Management standard and our effort. Agenda for Brussels.

Discussion Summary:

Folder for model sandbox to be created under WG14 > Part 11 > Draft Models (done).

Link to the sandbox: http://iectc57.ucaiug.org/WG14/Part11/Draft%20Models/Asset%20Health%20Focus%20Community%20Support

Circuit breaker test/monitoring vendors to present next two meetings: May 6th Ken Elkinson (Doble Engineering), May 20th Tony Poeltl (ABB).

Asset – PSR recommended practice: Keep Asset generic, associate with PSR (identify using PSRType), and subtype AssetInfo.

The generic approach to model asset-related data is to capture data common to multiple asset instances in classes such as AssetInfo.

Some informative classes such as Bushing, Joint, FACTSDevice, StreetLight etc. which came about as exceptions. Where possible, they need to be dealt with and brought to the same look-and-feel as the general approach.

In the case of Bushing, position is information that it doesn’t have in common with other asset types. May justify an Asset subtype for Bushing in order to capture this instance data.

Meeting on 6 May 2014

Meeting Attendees:

Paul Barnett Pat Brown Ken Elkinson Herb Falk David Haynes Svein Olsen Gowri Rajappan Nada Reinprecht Richard Greg Robinson Tomasz Rogowski John Simmins Luc Vouligny Frank Wilhoit

Meeting Agenda:

Breaker test & maintenance overview by Ken Elkinson (Doble).

Discussion Summary:

Ken Elkinson

Works at Doble w/ Gowri Client service, field test, installation at Doble Was substation engineer at utility

Why test circuit breakers

In normal operation, breakers are “in operation” for about 1 minute in 30 years.

As they are sitting waiting to operate, things gum up.

Testing is part of comprehenisive maintenance program, find problems early, prevent problems, catch trends (among population of similar breakers), find bad actors

Types of testing

Timing tests – verifies control circuit, check motion of moving parts, validate time of operation, determine contact wear (every time breaker interrupts fault the breaker contacts are eaten away), demonstrate results of maintenance, assess capability

Need to know how breaker works before test (design test plan)

Breaker design Breaking medium Contact system design What kind of mechanism operates the breaker

Types of breakers

Dead tank breaker (see slide)

(Control circuit is in box on side)

Also SF6, OCB, live tank, vacuum, air

Offline Circuit Breaker Testing

Trip Coil Current (time and travel measurements)

(in box) – sends signal to breaker to open

Are monitoring the waveform of the trip coil current (sample breaker was 66 ms between time coil opened and closed again – maybe between time

Raw results of this trip coil testing will be a wave form

Problems identified by: difference from family, wave form shifted

There is value in “first trip testing” – the first trip when test crew is in the field when the breaker is still in service (is how it would have reacted if it really had been called on to trip) – other trip coil tests are done w/ cb out of service

The more trips the breaker has during testing, the more the lubrication may improve

There is software that analyzes wave forms and produces numerical information and pass/fail indications

Breakers have information that came from manufacturer

Look for outliers – one voltage class that operates differently, one substation where breakers are different

Also want to look at distances that parts inside breaker are moving

Can see how far contacts are moving to accomplish

Need transducer that mounts on operating rod of breaker – then measure motion of transducer

Breaker has to be out of service

Circuit breaker design actually includes things that facilitate installation of transducer

Paul (TVA) – Utilities rarely see contact wear being the issue

Contacts bounce on close

Power Factor test

Can do pf test on any breaker, but not likely to be routine test: are measuring quality of insulation inside cb (oil, SF6, etc.) or of bushing

Dielectric quality -

Dynamic Resistance Measurement

Online monitors

Measuring insulation quality or timing

Operational

MVA, amps, volts

Visual & Operational Inspections

Counts of operations (load, fault and no-load)

Questions after presentation

Parts of breakers that merit modeling?

Trip coil Bushings Contacts Operating rod Medium

What caused the catastrophe in the last slide?

Mis-wiring / labeling of control house circuits probably

Common types of Breakers?

Transmission

SF6 dead tank Oil CB

Distribution

Lots of SF6, air blast Switchgear have air breakers Inside substation, but not in sg (wide variety)

Meeting on 13 May 2014

Meeting Attendees:

Pat Brown Tanja Kostic Svein Olsen Gowri Rajappan Nada Reinprecht John Simmins

Meeting Agenda:

Asset health use case for ProcedureDataSet (related to last week’s WG14 modeling call discussion.)

Agenda for Brussels.

Discussion Summary:

John Simmins – would like to find out what kind of Inspections are done by utilities and get messages created to support them

Pat – this might provide an opportunity to also help us identify what common types of breakers (and other assets) are, since inspections vary by asset type

John mentioned trying to engage Maximo in the discussion – they might be able to contribute default inspection questions or default asset categorizations that their product uses

Got clarification from Tanja that some Asset child classes exist because they do not have a corresponding role in the network model.

Pat’s interpretation of when “childing” Asset or (AssetContainer) is appropriate:

If there is a need for a relationship to a network model class other than PowerSystemResource (like Terminal , for instance)

If there is no corresponding network model role and there is asset-specific (not asset type-specific) information that needs to be defined. See EndDevice and EndDeviceInfo example below. Note that the EndDeviceInfo class would be used for both catalog information and typical planned asset information.

From Tanja: We need to read Part 11 thoroughly

She would like help in improving Part 11 document if it is not clear enough – there is a draft on the IEC CIMug website

Pat promised to have some suggested revisions to Tanja in October – assuming this will be after we are done with breaker templates

Also we need to look at CDPSM profiles – have Asset profile that uses AssetInfo classes

Tanja asked the WG13 members on this joint group to help be sure that the 61970 modeling of electrical behavior data be coordinated with the asset information modeled in 61968.

Meeting on 20 May 2014

Meeting Attendees:

Pat Brown Michel Condemine Check DuBose David Haynes Svein Olsen

Ryszard Pater Anton Poeltl Gowri Rajappan Nada Reinprecht Tomasz Rogowski Carey Schneider Siri Varadan Luc Vouligny

Meeting Agenda:

Online monitoring of circuit breakers.

Discussion Summary:

Presentation objective: what a breaker monitor does and what type of data it maintains.

Anton Poeltl, ABB

Supports/markets ABB Circuit Breaker Sentinel

The 4 areas that are monitored on breaker:

The monitoring described in this presentation applies to ABB SF6 dead-tank breaker with same pressure SF6 used for both arc extinguishing and insulation.

Useful types of monitoring

Travel monitor (done using a rotor encoder) – picks up the travel of the interrupter Phase currents transformers

(these are big bushing CTs that monitor current for relaying and metering) – breaker monitor has another CT (clamp-on) that reads the output of the big CTs to measure for input into monitor – uses but doesn’t disrupt existing big CT function

Temperature Heater current transformers (measure heater current) – heaters are important in cold climates:

o tank heaters – need to prevent SF6 from liquefying (need gas density for both extinguishing and insulating in case of SF6)

o heating of mechanismso cabinets - anti-condensation hetaers in cabinets (keep cabinet slightly warmer than

outside) Also something on mechanisms

From travel curve and contact energization

Tony pointed out that the contact velocity on a close/open operation would not be as fast as on a trip not preceded by an open

Interrupter wear

More advanced than i2t

There are different parts that are impacted by arc at different phases during the opening operation (contacts, aux nozzle, main nozzle)

Calculate wear over full operation on each part (since ABB knows how its breakers work) so estimate is much more accurate

Coil monitoring

Can monitor close coil and trip coils both and can monitor in both breaker positions (typically monitoring is only for trip coil and only in closed position). Have little circuit that periodically puts potential across coil to see how it reacts.

Gas (SF6) pressure

Every second temperature & pressure monitored. Gas density can vary locally. Also changing temperature of tank influences calculated gas pressure. This can be a problem. Do gas trending (of temperature compensated temperature) over 5 different time periods so get good picture of trends over time.

Quantitative monitoring vs functional monitoring

Quantitative

Like SCADA point alarming Expected range, caution limits and problem limits Monitor has ability to set up expected ranges as breaker goes into operation for the first time

Functional

Complex calculation that take states into account, does calculations involving multiple inputs and can have timer or counter before alarm is issued

Interesting alarming strategy on daily motor start counts (a bit like accumulators)

GUI

Use nameplate data to configure monitor

Display raw data points and limits (also configure expected, caution, problem)

Log screen showing events related to monitored data over time

Operations trends (currents during operations)

Gas trends (temperature-compensated pressure)

Communication

Simplest – monitor in field, communication w/ RS232 – need fiber optic, not copper

Can use Ethernet, still need fiber

If can’t do fiber, could do RF modems

If don’t have connectivity to substation

Comms protocols:

Native efficient protocol (is used between monitor and GUI) Modbus

Question: what data is available via Modbus: Is a larger set of data available, but user configuration is more difficult

DNP3Question: what data is available via DNP3? (all data on condition page – points & limits, also COMTRADE info for operations)

Meeting on 27 May 2014

Meeting Attendees:

Pat Brown Gowri Rajappan Nada Reinprecht

Meeting Agenda

Determine agenda for Brussels WG13/WG14 Asset Health session.

Discussion Summary:

Proposed agenda:o Motivation (ISO 55000), use cases, IRM business function.o ProcedureData / ProcedureDataSet – use cases that necessitate extension.o Asset/AssetInfo –

Asset types that may necessitate subclassing Asset

Don’t have a need to be represented on the network side. The attributes pertain to the asset instance and not the model. Have a special relationship to the network side – e.g., bushing.

Asset types that can be addressed by subclassing AssetInfo.o Breakers as a case study.

Asset-side modeling: tank, interrupter, bushing & mechanism. Measurements for these: e.g., 61850 SwitchgearSupervision.

o Handling measurements that are not made at the asset – e.g., flow. Need to get together with work management team (Nada, Greg, Gerald, Jim Thomson) & with

asset planning (John Simmins et al.) Confirm meeting space with Chavdar for Jan 10th, 1:30pm onwards, for asset health session. Need to able to associate phases with specific aspects of the asset. For instance, the phase

association of the bushing may be helpful from asset health perspective, since the measurements on that phase would be indicative of the operating history of the bushing.

The breaker components that may be worth modeling from asset health perspective: tank, interrupter, bushing & mechanism.

How important is voltage & flow. The latter esp. is not measured at the asset. List of common breakers.

Meeting on 3 June 2014

Meeting Attendees:

Pat Brown Chuck DuBose Mark Easley Gowri Rajappan Susan Richter Greg Robinson Miguel Escribano Rodenas Luc Vouligny Xiaofeng Weng

Meeting Agenda:

CIM asset health modeling concepts. Modeling circuit breakers.

Discussion Summary:

Mark Easley described how asset health and management is getting a lot of attention and many vendors are adding such functionality to their products.

o The data sources and approaches are disparate – each utility is doing something slightly different, but there are commonalities, which is what something like CIM would help standardize.

o Cascade, Maximo, etc. putting asset management on top of their product. In different stages of maturity, putting it in as modular. Survey indicated each vendor has a niche.

o Smart Grid data being incorporatedo Control room information being incorporated – alarms and alertso Control room needs the AHI systems for operationso Business needs the systems for health/planning replacemento Alarms & alerts are being utilized for failure predictiono Clear movement to put IEDs in the fieldo Information still disparateo Lack foundational informationo Obsolescence table – recommended as risk – no support, no partso Safety bulletins being incorporated into risko Environmental incorporated into risk

The attributes in Asset are inadequate for asset health. Why? Because historically the model was developed for work management, may need extensions for asset health.

AssetModel is somewhat general, where there is a generic item in the asset catalog, such as a 25 kVA pole-top transformer. ProductAssetModel is more specific, e.g., GE 25 kVA pole-top transformer of a particular vintage.

AssetModel is keyed for CompatibleUnit and can be used together to great effect. A macro CompatibleUnit can be used to very quickly grab the information needed to put together the design for a new project. The CompatibleUnit should be considered in the asset health modeling.

Meas package was developed from the operations perspective. Need to investigate asset health-related considerations such as oil temp. The intent is to enumerate such measurements.

Meeting on 24 June 2014

Meeting Attendees:

Pat Brown Svein Olsen Gowri Rajappan Greg Robinson

Meeting Agenda:

Plan AHFC meetings for July and August (5 meetings). ProcedureData/ProcedureDataSet – discussion of the informative subclasses.

ActivityRecord – continuation of Brussels discussion. GenericAssetModelOrMaterial class & intended use. CompatibleUnit & intended use of CUAssets.

Discussion Summary:

Dig into templates for breakers at the AHFC meetings. Who might be the right people to be on the AHFC calls – breaker and breaker maintenance experts who can help figure out what pieces need to be represented? Carey Schneider, Paul Barnett. Folks at EPRI? Statnett?

o Can you get a picture of this kind of asset?o Sample of nameplate data?o List out tests done of the specific breaker types?

Gowri to work on pictures of breaker with labels on locations where tests/measurements are made and the output of the test/measurement.

AHFC Meetings for July and August:o 5 meetings; Agenda: agreed upon templates for transmission and distribution breakers

at the end. Transmission: SF6 dead tank, OCB dead tank, SF6 live tank, Air blast (live tank). Distribution: SF6, OCB, Vacuum, Air blast, Air magnetic.

o Reclosers and circuit switchers are next iteration.o July 1st: Current breaker templates; ask utility participants for pictures and nameplate

data.o July 15th: Ongoing templates; first set of labeled pictures and measurement/test data.o July 29th: o Aug 12th:o Aug 26th:

UML model for AHFC work:o AHFC package.o AHFC stereotype for new informative classes.o Instance diagrams. What dials/level of detail on the instance diagrams?

Target invites to utility experts: Southern Company, Alabama Power. Larry Clark? Breaker manufacturer participation? Get catalogues and nameplates from ABB, etc. Tony Poeltl

for ABB; Pat to investigate contacts for Alsthom and ABB. Get Doble breaker maintenance expert (Ken) to participate. Post CIMug presentation on the AHFC site.

Meeting on 1 July 2014

Meeting Attendees:

Pat Brown

Mark Easley David Haynes Svein Olsen Gowri Rajappan Susan Richter

Meeting Agenda:

CIM templates for common transmission and distribution breakers.

Discussion Summary:

Presentation from the Oslo CIMug meeting posted on the AHFC Public > Resources folder. Types of breakers:

o Transmission: SF6 dead tank, OCB dead tank, SF6 live tank, Air blast (live tank).o Distribution: SF6, OCB, Vacuum, Air blast, Air magnetic.

Is this a fairly complete list to start with? Mark Easley and Susan Richter thought that the list looked quite complete.

CIM UML package. Our template work focused on 61968. Asset and AssetInfo are the main packages. In addition to the normative package, the informative Asset/AssetInfo packages contain many classes that may be of use.

Added an AHFC package to 61968 for the ongoing AHFC work. Walk through of the class diagrams in the AHFC package. Different coloring for normative and information classes in the diagrams.

There are subpackages under AHFC that contain classes that we suggest be added – for instance currently a AHFCAssets sub-package has a AssetKind enumeration class that we suggest be added.

There is a Templates sub-package under AHFC that contains the instance diagrams for various asset types. The top-level instance diagrams in this package doesn’t show all attributes in order to keep the diagram clean. There is a TypicalInstances sub-package that has the complete set of attributes.

<<AHFC>> stereotype is used with all suggested class and attribute additions. What to model and what not to model? Some rules:

o Anything that has a serial number, nameplate, etc. and is tracked in Enterprise Asset Management (EAM) systems.

o Can you replace the component independently?o Are there tests that are done specifically for that component?o Does any distinguishing characteristic of the component matters for

health/maintenance purposes?o Other rules?

Protection control guys want to track cards inside their protection equipment. There is a point of diminishing returns in terms of modeling smaller and smaller components.

Need type attribute that is data type AssetKind & for e.g., SF6DeadTankBreaker is an enumeration value. Allows for unique programmatic identification of the asset type.

Not sure why lotNumber included in Asset & not modeled independently. Also, it seems more relevant for supplies and smaller bulk assets.

What about model specific information? This could be captured using lotNumber? AssetModel has information pertaining to the model, so may not need to use lotNumber for the assets we are interested in.

Critical Boolean attribute. People have had different definitions of criticality. NERC CIP or more expansive definitions for asset health. May be useful to indicate the source and measure of criticality; also, being able to express level of criticality – low/medium/high.

Flag criticality as something to explore further. Need to solicit requirements from utility participants on the criticality considerations: e.g., network position, asset location, safety, etc. Also, the granularity of criticality: low, medium, high or more levels?

It is important to understand that criticality is not a component of health, but rather an expression of impact.

electronicAddress not applicable for breaker? How do we flag things the attributes that are out of scope such as this might be?

Meeting on 8 July 2014

Meeting Attendees:

Pat Brown Svein Olsen Gowri Rajappan

Meeting Agenda:

ProcedureData/ProcedureDataSet – discussion of the informative subclasses. ActivityRecord – continuation of Brussels discussion. GenericAssetModelOrMaterial class & intended use. CompatibleUnit & intended use of CUAssets.

Discussion Summary:

Discussion of modeling interrupter and mechanism. Email comment from Paul Barnett (TVA): “Some breakers, typically larger ones for 345kV and 500kV systems have one mechanism per phase. Smaller ones generally have one mechanism that is mechanically ganged to all three interrupters.”

Would both interrupters and mechanism both be Asset? If so would mechanism contain interrupter(s)? This wouldn’t work since interrupter would also be contained by the breaker tank assembly AssetContainer, but an Asset cannot be contained by multiple AssetContainers.

How to model the two different possibilities for mechanism (1 vs. 3)? Asset.type for the breaker container class can indicate whether it has 1 mechanism or 3 mechanisms. Alternatively, it is not indicated in the Asset.type and instead reflected by the number of mechanisms that relate to interrupter.

Meeting on 15 July 2014

Meeting Attendees:

Pat Brown Matt Garber Margaret Goodrich Gowri Rajappan Nada Reinprecht Susan Richter

Meeting Agenda:

CIM templates for common transmission and distribution breakers.

Discussion Summary:

SwitchInfo has an isUnganged attributes, which serves to indicate (when TRUE) whether there are 3 mechanisms, one attached to each breaker tank assembly or (when FALSE) there is only 1 mechanism attached to the breaker as a whole.

Confirmed from Ken Elkinson (Doble) that mechanism and interrupter can be tested, maintained and replaced independently of other breaker components. Therefore, it makes sense to model them as Asset.

The component model is not meant to reflect the internal connectivity of the breaker. There is some diagnostic value to know which side of the switch the interrupting mechanism is. There may be more than one interrupter per phase in some SF6 breakers; may be able to get to

the insulating medium between interrupting mechanism. In order to identify the direction of the interrupting mechanism, could have an attribute like

OpenDirection – even or odd – and the even/odd numbering of bushings aligns with this. Also, all three tank assemblies open the same way, so maybe the indication of direction of operation can be indicated at the breaker level.

o This probably belongs in SwitchInfo, since it’s generally done one way and one way only in a utility (e.g., interrupter always on odd-side bushing).

Are the number of tanks and mechanisms perfectly correlated? In other words, one mechanism if it’s a single tank breaker and 3 mechanisms if it’s a 3-tank breaker? No, only whether there is ganging or not determines the number of mechanisms.

Need to change breaker tank assembly to breaker pole assembly. The multiplicity of medium object is going to tell us how many tanks there are. In other words, if one instance of medium exists for each pole assembly, it’s 3 tank. If it’s just one medium for the whole breaker, it’s single tank.

SwitchInfo:isUnganged and SwitchInfo:isSinglePhase. Does this information belong in the asset component model? From a planning and maintenance viewpoint, it makes sense to have them be in SwitchInfo, since then ganged breakers could all be treated one way, etc.

Meeting on 22 July 2014

Meeting Attendees:

Pat Brown Tanja Kostic Gowri Rajappan

Meeting Agenda:

Getting Tanja caught up.

Discussion Summary:

UCAIug WG14/Part 4 SharePoint folder to be only home for models and other asset health material not open to the general public.

The model file and packages should be renamed/relabeled to start INF, so that there is no confusion if someone downloads the file.

Use GenericAssetModelOrMaterial to express the asset type? For instance, 3-pole, 3-tank, SF6 dead tank breaker?

AssetModel and GenericAssetModelOrMaterial meant to deal with a generic asset description without having to deal with the specifics. Can be used to pull together asset type commonalities.

There used to be 40+ sub-classes of AssetModel that were eliminated. AssetInfo class provided replaced functionality?

Subtype Asset for Interrupter (need an unambiguous name for it), which can have two different association roles with Bushing, one for the FixedEnd and another for MovingEnd.

Meeting on 29 July 2014

Meeting Attendees:

Elizabeth Bray Pat Brown Mark Easley Herb Falk Fook-Luen Heng Igor Honhoff Tanja Kostic Svein Olsen Gowri Rajappan

Meeting Agenda:

CIM templates for common transmission and distribution breakers.

Discussion Summary:

Started with an overview of CIM asset health work for the new attendees. Discussion of SF6 dead tank breaker template. Should Interrupter and Mechanism be specializations of Asset or AssetContainer? Right now,

propose these to be Assets. Interrupter and Bushing proposed to have two relationships, one with the role MovingContact

and another with the role FixedContact. The experts who were providing the requirements for this not on the call due to IEEE PES. Need to circulate the proposed concept to get feedback before next meeting.

The way we are providing additional requirements in EA is not searchable. One suggestion is to add description under Tagged Values. Tanja: not the right way. Use stereotypes, which is visible, vs the suggested method is hidden.

In the run-time objects, should the attributes that aren’t used be still included for illustrative purposes?

As for the new suggested attribute called positionNumber (in Asset), better call it sequenceNumber, because that’s a term used elsewhere.