530 likes | 718 Views
Arnold deVos. Ontology and the Age of Integration in the Electric Power Industry. Steve Widergren. Download the final version of this presentation at: http://www.langdale.com.au/SemTech06/. Our Topic. The domain electric power systems The problem
E N D
Arnold deVos Ontology and the Age of Integration in the Electric Power Industry Steve Widergren
Download the final version of this presentation at:http://www.langdale.com.au/SemTech06/
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
Power Networks, Control Systems, Market Systems, and New Players at the Fringe Part I
A Lot of Stuff Lots of lines Lots of generators Lots of other equipment Power networks are graph-like
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
Operations Software The Power Network is operated from control centers using large-scale software systems. NetworkModel DataAcquisition StateEstimator NetworkSimulator TelemetryNetwork CurrentState Alarms ContingentThreats Supervisory Control Operator Decisions
Market Software Power Generation is bid and dispatched using large-scale software systems. NetworkModel CurrentState Forecast Bids Optimiser Dispatch MarketRules
C C Division D C Division C C C E Process Y C E Process X E Division A C E Division B C C Bigger Picture: Evolving Islands Org E Org C Org B Org A Division A Org D Integration Interfaces: C = Collaboration-based E = Enterprise-based
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
But Shared Models are Pervasive Domain Models Message Models NetworkModel Bids
DistributionLinemen Energy Service Co.s, Vendors, Utility Programs Customer Appliances, Equipment, Processes Now Consider the E-commerce Future Gen, T, & D Suppliers Aggregators EmergencyOperations
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)
<<Global>> Wires LoadModel Domain SCADA Topology Core Outage Generation Meas Financial Energy Reservation Protection Scheduling Asset CIM Packages
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)…
Distributed Energy Resources Markets Documents Assets Generation Substations Wires Locations Workflow Measurements Engineer CIM as a Federation of Packages
Proprietary EMS/DMS Models Proprietary Work Management Models OMG OPC MIMOSA MultiSpeak CIM Open GIS Proprietary ERP Models OAGIS Proprietary GIS Models Proprietary CRM Models Enable CIM in a Federation of Ontologies
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. 'Muffin' structure: UML blueberries with OWL dough. UML Domain Models OWLBinding More about OWL capabilities for federating models anon ...
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
Arnold deVos Sidebar:Transforming UML to OWL
Parsing XMI • We 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 Mapping • UML Class – OWL Class • UML Association – OWL ObjectProperty • One per end • Mutually inverseOf • Functional or IFP per UML cardinality • UML Attribute – OWL DatatypeProperty • UML Class <primitive> - XSD Datatype • UML Class <enumeration> - OWL Class • Plus individuals for the values • Chose not to use enumerated class
Alternative Mapping • UML Property – OWL Restriction • No global domain and range • Can use the UML role name instead of Class.Role construct for URI • Can have both global properties and property restrictions • Make the global property subPropertyOf the restricted property
Identity Mapping • XMI 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 Species • Some 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 funding Uses open source Jena RDFTwig To be released as open source Shared 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
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
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 be Higher 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)
Acknowledgement • Scott Neumann • US Chairman of IEC TC57 - Power Systems Management and Associated Information Exchange • CTO, Utility Integration Solutions sneumann@uisol.com 612 703 4328
Contact Information Steve Widergren steve.widergren@pnl.gov 509 375 4556 Arnold deVos adv@langdale.com.au +61 2 99 862 777