1. TSO Interoperability and the CIM
ＴＲＡＤＩＮＧ
Model
Common
Alert
Semantic
data exchange
Events
Interoperability of Systems and ICT Networks
The IEEE Glossary defines interoperability as:
“the ability of two or more systems or components to exchange information and to use the information that has been exchanged. “[1]
System Interoperability
Data Distribution Services are designed to use existing infrastructure that can be widely geographically dispersed. DDS does this by caching the data involved in the data services. For efficiency, the data remains in situ, and when data is updated, ‘published’ by interested parties, ‘subscribers’ are notified of the data cache updates.
In addition, the OMG defines an interoperability protocol for DDS [2]. Its purpose and scope is to ensure that applications based on different vendors’ implementations of DDS can interoperate.
This approach to data integration works well - a central notification mechanism for the scope and currency of the pooled data. These metadata services may require additional processing infrastructure, however the cost can be quite low, considering they represent a large part of achieving a cost-effective way to ensure interoperability of unlike systems.
Interface Interoperability
This is achieved by mapping individual TSO electricity supply and market data to the Common Model. The Utilities CIM is not enough on its own. For true interoperability, interfaces have to be integrated across energy domains, as well as to technology application and platform services.
This logical linking provides for automated interoperability in a “Smart Grid” context.
Data mapped to the Common Model can thus be routed for workflow, complex event processing and content delivery, before being translated back into the native formats expected by the TSO systems.
This ensures minimal effort to have unlike systems communicate. And by ensuring data can be translated in and out of native format, hosting and network interoperability becomes very viable.
Hosting and Network Interoperability
Given the degree of specialisation required to achieve best practice ‘allocate to order’ infrastructure, hosting and network are best achieved by dedicated expertise, able to fund high volume high speed data centre services.
It may prove very cost effective to purchase private cloud services (hosting, network and possibly technology platform as services) as required. That can mean that a pilot can be conducted at low cost and low risk.
Incremental addition of functionality, only paying for processing as it is required, can ensure budget compliance.

2. Smart Grid Communications Network

3. Energy Exchange Model & Cross Border Automation
Telecommunications Network Data
Electricity Data
Market
Data
Application Domains
Business Metadata
Energy Exchange Model
Geospatially aware Portal/Workflow
To enable portal/workflow to make efficient use of detailed electricity operational data and business and technology metadata, energy industry, application and technology integration domains not only have to be logically linked, but also accommodate data and content geographic caches, to ensure efficient queries, processing and information access and presentation.
One example might be:-
A workflow called from the portal interface, logged into by a job role classified by security policy, links detailed operational data from a Transmission Network Outage with an Asset Management system, displaying the affected plant and transmission lines on a map, and in addition, triggering a maintenance workflow.
This can be achieved by providing logical links to high speed data services cross-domain keys and topics, linking distributed database information from geographically diverse locations, in real time, and displaying on pre-prepared geospatial overlay themes,
And it is not enough just to access the data.
Web/portal functionality has to be able to gather the results data for presentation on web browsers for computers, rugged mobile devices, smart phones, etc. with a speedy response. For complex real-time events, such as updated market prices, or supply and demand balances, data is processed from diverse, distributed sources as the data arrives, before it is stored.
Geospatially cached content elements are immediately accessible to enables secure end users to see this ‘live’ data from a browser.
Technology Domains
Integration Metadata
Electricity
Network
Data

4. Deployment in Smart Grid
Model Automation
UML Model technology can generate the platform specific model for the Data Distribution Services using an MDG add-in for DDS2.0 in a data services domain format provided by the Common Model.
If the Common Model is built and orchestrated correctly, it can enable
High speed data distribution services of electricity and market data.
High speed complex event processing of this data with other sources such as reference material, pricing algorithms, etc.
Business users can activate workflows from browsers that trigger the appropriate events
Aggregation of results data with the content elements required to present a geospatial picture to the end users web browser, for example, for end users to view real-time market demand data, in a geospatial context, in real time.
The design of the Common Model is key. Information exchange is not only predicated on Smart Grid function and data, but also identification of workflow, devices, events and other contextual information, such as geospatial routes, fences and maps, and other relevant display content.
For example, the Common Model has to have the appropriate links to access technical data such as network device ID and network address, and enterprise data such as location information and workflow permissions, and market prices and geospatial maps.
Common model enabled contextual access to linked data, in real-time, is the way forward to add value and meaning to display electricity supply and energy management data .

5. Where Canonical Models Fit
GridWise Architectural Council Interoperability Framework
Progress has been working quite a bit in the Utilities space of the past year …
So if we consider what Mike said, and those categories off of the Gridwise diagram --
Business context
Semantic understanding
Syntactic interoperability

6. Governance is required
in order to continue to derive value from industry standard
Requirements
Design
Publish
Maintain
Requirements
Design
Develop
Deploy
Maintain
Industry Models e.g.
Utilities CIM
Enterprise Models
Energy
Exchange Model
For example, as Mike mentioned, many people are using industry standards as the foundation of their approach. However, those models move at a different pace than your business. For example, so there needs to be a method
Main Point:
Industry models are great sources of canonicals
The model won’t satisfy everything you need (covered in the next couple of slides)
Also rate of change wont be the same as your rate of change – however there is value in staying engaged with and connected to the standards process.
[Telstra Anecdote]
Our service provider customer used the TM Forum’s Information Framework (aka. The SID) as their model. They made extensions and they returned those model extensions back to the TM Forum, they were ratified and accepted. The value they received was that their extensions would now be maintained by the standards body and this meant that anyone in their ecosystem that was going to upgrade to this version of the standard (customers, suppliers: application vendors and network equipment vendors, and even acquisition targets …) would have better interoperability with them.
So maintaining that linkage between the body might be useful as you can continue to add (and harvest) value from the standards body and work that other organizations like yours are doing.
Data Services (Transformation, Mediation)
Standards Process
Enterprise Process

7. Linking the CIM to an Exchange Model – in UML
Common Models
The type of Common Model that is suitable for data mapping is designed with process automation in view. (e.g. Telecommunications NGOSS eTOM, a process-centric model, and the accompanying SID, a data centric model). Models designed around functionality and data provide a ready start for use of data elements, as the process context is easily discovered, and can be readily related to common run-time technology application services. This differs markedly from the Utilities CIM , which has no concept of business process or automated technology services, and therefore is much more difficult to deploy. However the Utilities CIM is a very complete definition of an electricity-centric model.
It can be utilised by a model that is process-centric and technology deployment oriented, and understands the structure of the CIM.
And data mapping is not the only purpose a logically linked Energy Exchange Model can serve. Content management and delivery can be serviced by the Energy Exchange Model, if constructed to do so. And technology integration can be facilitated if the Energy Exchange Model elements, such as workflow , device, geospatial map, asset s, events etc, designed to be linked, includes application and technology domains .
If the Common Model satisfies these criteria, it can provide model based automation of technology integration services.
This means that application services that recognise and map energy data across substations, operational data stores, and market data, for example, can be linked with technical services such as workflow appropriate to a job role, device identification and transmission data, geospatial data such as the appropriate geo-fence ID, on which to display the device data, and, for that matter, any other business and technical data required to provide meaningful information on a web browser, automatically, in real-time .
So, to facilitate model automation of technical services, the essential components are
A representation of the logical data services and workflows, to be automated. This enables a starting point for further, detailed identifications of data elements.
Logical cross domain business and technical data entity elements, used for mapping disparate physical data so that unlike data can be compared, aggregated, etc.
Technology integration metadata model to identify automation concepts such as workflow ID, device ID, map ID, market bids and offers with real energy transmission data.
Industry specific information and data elements for detailed mapping to physical elements.

8. The Same Exchange Model – in Eclipse

9. Moving from Design to Development
Modeling
Industry standard(s)
Enterprise requirements
Model Spec
Integration
Main Point….
When it comes to making the extension to these information models, most of our customers have made those modifications within a tool such as Enterprise Architect, Erwin, or Rational –
The reason is that physical models are projections on the information model and as a result are de-normalized versions (or subsets) of the information model. It’s easier for the data and information architects to model changes and improvements against that normalized information model in a UML or Logical Modeling tool an then export into a more integration / physically focused tool.
Also, centralization of design can be useful when trying to standardize use within an organization
This approach helps get the model off of the wall and into a useable format for integration 
Using tools that connect the steps in the software development lifecycle can facilitate adoption of a standard (in this case the SID)
For example, the Telstra extensions to the SID were modeled inside a design tool, in this case IBM’s Rational Software Architect
The newly extended T/SID model was deployed into Progress’ DataXtend SI to build the data exchange models which integrate our 26 COTS and legacy systems.
UML Tooling
IBM Rational Software Architect exports UML representation of the SID and Telstra-custom extensions (T/SID) as XMI
XMI contains all metadata Information about the model: abstract classes, class hierarchies, extensions and relationships
Progress Enterprise Data Services
Progress DataXtend SI loads XMI representation of the SID including all metadata and extensions into
Imports interfaces from physical systems: WSDL, RDBMS, XSD, Java, and others
Develop semantic mappings through T/SID Model
Source, Service, and other models
Integration requirements

10. Moving from Development to Production
Integration
Application services, other models
Integration requirements
JAR
Service Environment
Main Point….
When it comes to making the extension to these information models, most of our customers have made those modifications within a tool such as Enterprise Architect, Erwin, or Rational –
The reason is that physical models are projections on the information model and as a result are de-normalized versions (or subsets) of the information model. It’s easier for the data and information architects to model changes and improvements against that normalized information model in a UML or Logical Modeling tool an then export into a more integration / physically focused tool.
Also, centralization of design can be useful when trying to standardize use within an organization
This approach helps get the model off of the wall and into a useable format for integration 
Using tools that connect the steps in the software development lifecycle can facilitate adoption of a standard (in this case the SID)
For example, the Telstra extensions to the SID were modeled inside a design tool, in this case IBM’s Rational Software Architect
The newly extended T/SID model was deployed into Progress’ DataXtend SI to build the data exchange models which integrate our 26 COTS and legacy systems.
UML Tooling
IBM Rational Software Architect exports UML representation of the SID and Telstra-custom extensions (T/SID) as XMI
XMI contains all metadata Information about the model: abstract classes, class hierarchies, extensions and relationships
Progress Enterprise Data Services
Progress DataXtend SI loads XMI representation of the SID including all metadata and extensions into
Imports interfaces from physical systems: WSDL, RDBMS, XSD, Java, and others
Develop semantic mappings through T/SID Model
Service Configurations
Performance requirements

11. Model-driven data services
Business Processes
XML / Web Services
Cloud Data
RDBMS
Trading Partners
Consumer
Application
Web Portal
Business Applications
Mainframe
ERP
Billing
System
CRM
Industry Standards
Energy Exchange Model
Exchange Services
Virtualization Services
So again, Progress EDS is focused on model-based design and deployment of multiple kinds of data integration services…

12. Energy Exchange Model – Next Steps
A Standard Energy Exchange Model with the participation and co-operation of Transmission System Operators and relevant ICT and Energy standards stakeholders e.g. CIM, OMG, e-Tag , IEC and DNP3
Common Models
The type of Common Model that is suitable for data mapping is designed with process automation in view. (e.g. Telecommunications NGOSS eTOM, a process-centric model, and the accompanying SID, a data centric model). Models designed around functionality and data provide a ready start for use of data elements, as the process context is easily discovered, and can be readily related to common run-time technology application services. This differs markedly from the Utilities CIM , which has no concept of business process or automated technology services, and therefore is much more difficult to deploy. However the Utilities CIM is a very complete definition of an electricity-centric model.
It can be utilised by a model that is process-centric and technology deployment oriented, and understands the structure of the CIM.
And data mapping is not the only purpose a logically linked Energy Exchange Model can serve. Content management and delivery can be serviced by the Energy Exchange Model, if constructed to do so. And technology integration can be facilitated if the Energy Exchange Model elements, such as workflow , device, geospatial map, asset s, events etc, designed to be linked, includes application and technology domains .
If the Common Model satisfies these criteria, it can provide model based automation of technology integration services.
This means that application services that recognise and map energy data across substations, operational data stores, and market data, for example, can be linked with technical services such as workflow appropriate to a job role, device identification and transmission data, geospatial data such as the appropriate geo-fence ID, on which to display the device data, and, for that matter, any other business and technical data required to provide meaningful information on a web browser, automatically, in real-time .
So, to facilitate model automation of technical services, the essential components are
A representation of the logical data services and workflows, to be automated. This enables a starting point for further, detailed identifications of data elements.
Logical cross domain business and technical data entity elements, used for mapping disparate physical data so that unlike data can be compared, aggregated, etc.
Technology integration metadata model to identify automation concepts such as workflow ID, device ID, map ID, market bids and offers with real energy transmission data.
Industry specific information and data elements for detailed mapping to physical elements.
Research Project and Local Demonstration Projects to validate an Energy Exchange Model - an Interoperability Testbed

13. Thank you for listening!
Any Questions ?
Thank you for listening!
Monitoring the Environment
Carbon Emissions and Smart Grid
4-5 October, Brussels
Sponsored by the European Commission
Contact: