Basic measurement and event data Status Measurement Power revenue measurement Operational Power Measurement Power Quality Measurement Other Analog Measurement Communication Network Measurement Measurement and Status History Device & History Business functions Tagging/Maintenance Generation Forecasting Load Forecasting Weather Forecasting Provide/Consume Cost info Provide/Consume Pricing Settlement Scheduling Ancillary Services Electric Network Modeling Calculate Network Topology Calculate Power Flow Volt/Var/Watt Optimization Economic Optimization Contingency Analysis Islanding/Reconnecting Black Starting Simulation Testing Control DC/AC conversion AC/AC conversion AC/DC conversion Storage management Real control Reactive power control Switch control Load control Load Shedding Alarming Protection Security Key Distribution
Certificate Management Encryption Authentication Access Control Intrusion detection Clock Synchronization Computing and communication Communication Network Modeling Communication Network Management Packet Routing Packet Filtering Publish Subscribe Data Routing Data Filtering File Transfer Data Aggregation Table 4.1-2 provides another way of classifying nodes based on location of the node. In other words, the location will determine the security, latency, role, message exchange patterns, reliability, ownership, and bandwidth supported by an OpenFMB node. Table 4.1-2 OpenFMB Node Classification by Location Location Security Latency Role Message Exchange Patterns Reliability Ownership Bandwidth Bulk Generation Critical Infrastructure - NERC-CIP Subseconds Pub only Request/Reply 99.999% Utility Service Provider <10 Kbps Transmission Substation None critical infrastructure Seconds Sub only Pub/Sub 99.900% Third Party 10-100 Kbps Transmission Line Physical Minutes Pub and Sub Push 99.000% Consumer 100Kbps - 1Mbps Distribution Substation Cyber Hours Subscribe/Notify ISO/RTO >1Mbps/sec Distribution Line Authentication Days Generator Microgrid Access control TSO End consumer premises Encryption DSO Data tagging RSP
After a PIM data model is defined, its Platform Specific Model (PSM) can then be generated using a model-driven tool. Note that one PIM model may be used for multiple PSMs such as XSD and IDL. REQ.26.4.5 Platform Specific Model (PSM) Technical Approach (Shawn Hu, Jim Waight, and Terry Saxton) {expect updates after demo} {this section will describe the approach to go from OpenFMB PIM to PSM. The candidate PSM representations are many, but we will start with XSD for protocols (Web Services, REST, XMPP, MQTT, etc.) that support XML data representation. The approach to go from PIM and PSM will follow IEC TC57 methodology.} The Platform Specific Model (PSM) is technology dependent implementation of the PIM. XML Schema Definition (XSD) was selected as the PSM representation for OpenFMB. An OpenFMB PSM (i.e. XSD) is directly translated from a PIM described in the section above. Shown below is an example of the Recloser Status XSD generated from its PIM. Note the XSD represents all defined items in its PIM that includes the classes, attributes, and associations. Each data profile package has its unique namespace and settings for XSD generation. These settings are defined as UML Tagged Values in the OpenFMB model as shown below. Each data profile model references common classes and data types which are listed in a Common UML Package. This logical Common package is transformed into a separate XSD (Common.xsd) with its own namespace. Each data profile XSD imports the Common XSD as needed. Therefore there are two types of namespaces defined for the OpenFMB PSMs. Common namespace Profile namespace The Common namespace follows the convention of: http://openfmb.org/xsd/<version #>/Common The profile namespace follows the similar convention: http://openfmb.org/xsd/<version #>/<Profile Name>. Here is an example: http://openfmb.org/xsd/v1/RecloserStatus