In part one of this series, we discussed the grid network model management “junk drawer” metaphor for how most utilities find their grid model management situation to be.
In part two, we discussed the different components of a mature grid model management ecosystem, as well as key features and requirements of a GNMM solution.
In this part, we will discuss how to chart a path for achieving grid network model management success, supporting the entire asset management lifecycle and what utilities should consider when they are ready to grow their grid model management maturity.
Recall the network model management ecosystem highlighted in the previous part (shown in the figure below). Although this does not cover every system or person that “touches” network data – this does cover the major systems.
Figure Network model management (NMMS) ecosystem
But, as we discussed using our “junk drawer” metaphor, although these are supposed to be the System of Record (SoR) – sometimes that can get messy. This messiness often comes about due to how the systems evolve and what people get comfortable with. For example, people don’t use more capable analytics tools because they are comfortable with Microsoft Excel. This situation is further complicated by the adage, “Once you have a hammer, everything looks like a nail.” Perhaps the work and asset management systems were supposed to be the SoR for asset data, but then it was easier for people to put it in the GIS. Or if the asset happened to be a meter, it was easier to put it in the CIS. And maybe if the organization decided to make the CIS the SoR for the meter as asset-related data, everything would be fine(ish). But that’s not what happens. What happens is that there is data related to a topic, and the other places the data is stored or acted upon don’t agree with the data in the SoR – so now you have a “junk drawer” of data.
First things First
You may be thinking – “fair enough – we need a GNMM solution including a NMMS application – but how do we tackle this in a structured manner that will result in in this well-designed solution and not again end up with an accidental architecture?”
The simple, 30,000-foot answer is (a) ensure effective executive support and engagement, (b) think about the end-in-mind, including key requirements, asset lifecycle business processes and business functions, and (c) adopt a phased incremental approach to lay the foundation, and keep adding business value through each phase.
The reality is that there are typically plentiful “dragons” that could derail your GNMM program if not identified and communicated effectively to all stakeholders from executive management to the people dealing with day-to-day GNMM issues. These issues could range from data quality issues, business processes, business functions, and roles that need to change or be introduced, and unpacking the GNMM Junk Drawer. Other facets include synchronizing and aligning with other in-flight technology projects, such as legacy software that needs to be replaced or upgraded. Lastly, assuring stakeholders that both their daily work lives, as well as the operation of the organization will benefit to avoid folks “defending their turf”.
By having a clearly stated GNMM vision, strategy, and roadmap in place, and communicating effectively, all of these can be realistically overcome. Other approaches include completion of a “proof-of-concept” with clear success criteria to convince any sceptics of the benefits GNMM solution.
Implementing an NMMS is not trivial, but doing so sets the utility on a path to the digital future.
Charting the GNMM Path to Success
What can be done to avoid this situation – and what are some “no regrets” decisions that the utilities can make?
For starters, a data architecture that encompasses the major systems – with determinations of which should be the SoR for which kinds of data – and, if data needs to exist in different systems, a mechanism for ensuring that it is accurate. Getting a good data architecture in place goes a long way toward reducing the introduction of errors in the utility data that it relies upon.
And if the utility gets started with a solid data architecture, then it is time to think about a standards-based approach to systems integration. For the systems within the scope of network model management – that means the utility common information model (CIM).
The CIM has been in development since 1995, when it started as an Electric Power Research Institute (EPRI) project and is now maintained by the CIM User Group (part of the UCAIUG[1]). This data model also underpins families of standards (IEC 61970, IEC 61968, IEC 62325) from the International Electrotechnical Commission (IEC). IEC 61970 came first, which covered transmission requirements. Then as the data model evolved and distribution was added, it was decided to leverage what already existed instead of creating a new data model. It makes sense when you consider why you would want to define an asset such as a transformer twice. When the data model added distribution requirements, this was when the data model became “common,” as now the same data model was used to underpin two standards. Then, as the requirements for energy markets evolved, the CIM was leveraged once again, so even though there are now three families of standards, they are underpinned by the same common data model, leveraging those things in common that have already been defined.
Internationally, CIM adoption is further along than in the U.S. (and even required for network model exchange between organizations). However, that has changed as the CIM also underpins other grid-related standards, such as Green Button and the Outage Data Initiative. And in 2022, EPRI hosted an interoperability event wherein ten vendors came together to demonstrate their capabilities around exchanging CIM-based data.
The number of organizations and vendors that support the CIM continues to grow – as does the maturity of the CIM itself. (New versions of the CIM are released ~18 months (about 1 and a half years) as new use cases are explored).
Of course, you don’t adopt the CIM and convert all your interfaces “just ‘cuz.” But as your organization adopts a standards-based approach and good data architecture practices, as the utility invests in new capabilities – that is the time to ensure that the interfaces are standards-based. Have conversations with your vendors – you might be surprised how many leverage the CIM. After all, why struggle to invent everything yourself when you can leverage a standard? (We know some organizations’ core competency is “reinventing wheels”). But once you get off that treadmill, it opens possibilities of increasing organizational agility and holding down maintenance costs associated with application data integration.
Mike Daniels, Director of Digital Grid of the Future and Analytics at Ameren, discussing the benefits of NMMS, once the project is complete, stated, “there will be a single source of the truth for as-built, as-planned, as-designed, and as-operated networks, which will be shared with the relevant subscribing applications.”
Invitation: Join us at DistribuTECH 2023 for a more in-depth Utility University course: Improving Data Quality with Network Model Management.
[1] https://cimug.ucaiug.org/