© 2005 Your name here© 2005 Widergren, deVos Ontology and the Age of Integration in the Electric...

© 2005 Your name here© 2005 Widergren, deVos

Ontology and the Age of Integration in the Electric

Power Industry

Arnold deVos Steve Widergren


Download the final version of this presentation at:

http://www.langdale.com.au/SemTech06/

3

© 2005 Your name here.© 2005 Widergren, deVos

Our Topic

The domain– electric power systems

The problem– interoperation between large, heterogeneous

systems of systems

Some history– An ontology wanna-be: the power industry CIM

Issues– Too big: design center competition, versioning

A semantic technology path forward– Federation: distributed authoring/aggregation of

ideas in an industrial setting

A practitioner’s perspective

4


Part I

Power Networks, Control Systems, Market Systems, and

New Players at the Fringe

5


Subcontinents of Electric Power

6


A Lot of Stuff

Lots of lines

Lots of generators

Lots of other equipment

Power networks are graph-like

7


All the Way Down to Your House

8


Many Managing Organizations

Such as– Reliability centers– Operating

companies– Transmission

companies– Distribution

companies– Regulatory

authorities– Regional planning

agencies

Each with their own reasons for being

Figure from California Energy Commission Website

9


Operations Software

The Power Network is operated from control centers using large-scale software systems.

DataAcquisition

TelemetryNetwork

StateEstimator

CurrentState

NetworkSimulator

NetworkModel

ContingentThreatsAlarms

Supervisory Control

Operator Decisions

10


Market Software

Power Generation is bid and dispatched using large-scale software systems.

Forecast

CurrentState

Optimiser

NetworkModel

DispatchBids

MarketRules


Org E

Bigger Picture: Evolving Islands

Org B

Division A

Org A

Org D

Org C

Division C

Division A

Division B

Division D

Process X

Process Y

Integration Interfaces:C = Collaboration-basedE = Enterprise-based

E

E

E

E

C C

C

C

C

C

C

C

C

12


Heterogeneity – Vive la Difference!

Multiple large applications– Within a division– Within an enterprise– Between companies– Across the interconnection

Multiple vendors with multiple products

Multiple versions and mixtures of technology

Overlapping representations/models

Interaction requires a shared view– At least where things overlap

13


But Shared Models are Pervasive

NetworkModel Bids

Domain Models Message Models


Now Consider the E-commerce Future

Aggregators

Appliances, Equipment, Processes

Gen, T, & D Suppliers

EmergencyOperations

DistributionLinemen

Customer

Energy Service Co.s, Vendors, Utility Programs

16


Part II

The Power Industry

Common Information Model

“CIM”


CIM History

An E-R Model for the Network (early 90s)

Became a UML model of 'everything'... (late 90s)

and an IEC standard (2003)


Generation

SCADA

Domain<<Global>>

Wires LoadModel

Core

Meas

Topology

Outage

Protection Financial EnergyScheduling

Reservation

Asset

CIM Packages


CIM Classification Fragment

PowerSystemResource

(from Core)

Connector

Conductor

EquivalentSource

Ground

Jumper

Junction

RectifierInverter

RegulatingCondEq

StaticVarCompensator

Switch

Fuse

TransformerWinding

TapChanger

Disconnector LoadBreakSwitch

DCLineSegment

ACLineSegment

Line

Compensator

VoltageControlZone

BusbarSection

LoadArea (from LoadModel)

EquivalentLoad (from LoadModel)

InductionMotorLoad (from LoadModel)

EnergyConsumer

StationSupply (from LoadModel)

CustomerMeter (from LoadModel)

HeatExchanger

Bay (from Core)

VoltageLevel (from Core)

PowerTransformer

Substation (from Core)

EquipmentContainer (from Core)

Equipment (from Core)

SynchronousMachine

GeneratingUnit (from Production)

Breaker

ConductingEquipment (from Core)

ProtectionEquipment (from Protection)

GroundDisconnector

CompositeSwitch


CIM Network Topology Fragment

Bus/Branch Model

Switch/Node Model

Naming(from Core)

PowerSystemResource(from Core)

TopologicalIsland

ConductingEquipment(from Core)

Measurement(from Meas)

TopologicalNode

1

1..n

+TopologicalIsland

1

+TopologicalNodes 1..n

Terminal(from Core)

0..n0..1

+Terminals

0..n+ConductingEquipment

0..1

0..n

0..1

+Measurements

0..n

+Terminal

0..1

EquipmentContainer(from Core)

ConnectivityNode

0..n

0..1

+ConnectivityNodes

0..n

+TopologicalNode

0..1

0..n

0..1

+Terminals0..n

+ConnectivityNode

0..1

1

0..n

+MemberOf_EquipmentContainer

1

+ConnectivityNodes0..n


CIM an Early RDF Application

CIM/XML is an RDF standard for network model exchange

– Profile of RDF XML Syntax

– Governed by RDFS version of CIM

Xpetal open source tool converts rose files to RDFS

Custom vocubulary used for cardinality and inverses


CIM/XML Milestones

Interop tests conducted between numerous vendors

Now published as an IEC (International Electrotechnical Committee) standard

Future: switch from RDFS+custom vocabulary to OWL


Current Situation

Parallel development of CIM by

multiple expert groups:

Engorged, monolithic model for various domains– Wires, markets, asset mgmt…

Messages (interfaces) need derivation for specific applications

Linkages needed to other (non-CIM) standard (but evolving) models– MIMOSA, OAGIS, OPC (factory

automation, oBix (building automation)…


Engineer CIM as a Federation of Packages

Wires

Assets

Generation

Locations

Markets

Documents

WorkflowMeasurements

Substations

Distributed Energy Resources


Enable CIM in a Federation of Ontologies

MultiSpeak

OPC

Open GIS

MIMOSA

OAGIS

CIM

Proprietary Work

Management Models

OMG

Proprietary CRM Models

Proprietary GIS Models

Proprietary EMS/DMS

Models

Proprietary ERP Models


Challenge – The CIM in UML

UML has limited facilities for 'federated' model building.

No good way for me to extend your model without 'borrowing' it from you.

No good way for me to merge my model with your model.

No good way to evolve packages of the CIM independently

No good way to link CIM to other industry standard models.

No good way to express many semantic constraints (axioms) of a problem domain.

– E.g., line at 345kV bus in one substation must terminate at 345kV bus in another


Solution

Use Web Ontology Language (OWL) to federate different CIM domains.

UML Domain Models

OWLBinding

More about OWL capabilities for federating models anon ...

'Muffin' structure: UML blueberries with OWL dough.


Challenge – Acknowledge Evolution

Conflict between ongoing CIM development and stable interface message definitions.

Domain model and interface standardization are on different timetables.

Possible to define separate message models, but:

– Limited facilities to link message definition back to CIM (use sub-classing? associations?).

– Tendency to bring the whole domain model into each message definition (WG14 XML schemas).


Solution

Use OWL to mediate message definition.

Create OWL version of message definition.

– Captures message semantics.

Link to CIM domain model.

– Similar to federation of domain models with each other.

Generate XSD for message syntax.

– Any syntax flavour you like (pluggable?)


Part III

CIMTool


A New Modelling Process


Generating OWL with CIMTool


Editing Message with CIMTool


Generating XSD with CIMTool


Sidebar:Transforming UML to OWL

Arnold deVos


Parsing XMIWe used a SAX-based parser– Hand crafted classes for parse states

Lessons:– There are many dialects of XMI

• More than one per UML tool!– XMI specs not found useful in practice

• Reverse engineering required.


Sematic MappingUML Class – OWL ClassUML Association – OWL ObjectProperty– One per end– Mutually inverseOf– Functional or IFP per UML cardinality

UML Attribute – OWL DatatypePropertyUML Class <primitive> - XSD DatatypeUML Class <enumeration> - OWL Class– Plus individuals for the values– Chose not to use enumerated class


Alternative MappingUML Property – OWL Restriction– No global domain and range– Can use the UML role name instead of

Class.Role construct for URICan have both global properties and property restrictions– Make the global property subPropertyOf

the restricted property


Identity MappingXMI uses ID's local to document (at least)– Identify classes, associations, etc.– Used to link these to each other

Use separate transformation to handle ids– Parser preserves ids to enable easy

building of the graph– Id transformation stage builds meaningful

class and property URI's from their names


OWL SpeciesSome UML metamodel concepts were kept– Stereotype – UML Packages etc.– Required use of OWL/Full

Alternative: drop UML concepts– Can squeeze down into OWL/DL or Lite


CIMTool

Part of the Solution

Understands a variety of XMI

Generates OWL for model federation

Edits message OWL, generates XSD


Developing CIMTool

Multi-vendor fundingUses open source– Jena– RDFTwig

To be released as open sourceShared infrastructure for– System integrators and vendors– Standards groups (IEC)– Power utilities


CIMTool Next Steps

Abstract message definitions in OWL– Implement model 'cherry picker' UI

Message semantic validation– Two way XSD/OWL bridge – Recognise classes, properties, subjects,

objects, collections in a grammar– Maybe Schematron meets XSD and

OWL? Has someone done this?


Part IV

Lessons

55


Power Industry Lessons

KR and ontology a natural evolution of the power industry CIM

Selective aspects of semantic technology can do wonders

– Don’t need it all immediately

Embrace distributed authoring and aggregation of intersecting ontology– Parallel development of related

ontologies by multiple expert groups– Linkage to other (non-CIM) standard

models

56


OWL v. UML v. XSD Observations

UML good for model visualisation and editing

But OWL provides a better modelling vocabulary– and supports model federation

XSD no good for modelling (but people seduced by XML Spy graphics :-)

But XSD is standard choice for message grammars (alas not RelaxNG)


Top 3 Missing Semantic Technologies

Graphical notation for OWL– more like UML, not Euler diagrams

On-demand inference– Almost impossible to use KR w/o basic

RDFS level of inference– forward chaining is too slow and always

will beHigher level API's– Current API's all do simple triple

matching under different names (s, p, *) (*, p, *) etc

– SPARQL is fine but lets not repeat the embedded S*QL pattern (please)

58


Acknowledgement

Scott Neumann• US Chairman of IEC TC57 - Power Systems

Management and Associated Information Exchange

• CTO, Utility Integration Solutions

[email protected] 612 703 4328


Contact Information

Arnold [email protected]

+61 2 99 862 777

Steve [email protected]

509 375 4556

© 2005 Your name here© 2005 Widergren, deVos Ontology and the Age of Integration in the Electric...

Documents

Transcript of © 2005 Your name here© 2005 Widergren, deVos Ontology and the Age of Integration in the Electric...