The NIST Standards Roadmap - very curious

The Smart Grid Roadmap, Report to NIST on the Smart Grid Interoperability Standards Roadmap has some very curious conclusions and descriptions. They involve DNP3, NERC CIPs, NIST SP800-53 and NIST SP 800-82. These descriptions and recommendations (or lack therof) can have long term, expensive ramifications. They can even impact the reliability of the Smart Grid. Section 10 provides the following descriptions with my comments in parentheses and major issues in bold:

10.14 DNP3
Application: Substation and feeder device automation
Actors: Protective relays, metering devices, cap bank controllers, switches, SCADA Master, applications
Interfaces: Serial, Ethernet, IP over TCP or UDP,
Maturity: Has security built in, has users group, has certification and testing
Category: De facto, Open, Industry Standard, Deprecated for new work.
(The dictionary defines “deprecated” as to express disapproval, deplore, or belittle.)

10.58 NERC CIP 002-009
The National Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) is a series of standards are directly relevant to the bulk power system critical cyber assets. CIP-002 states the means by which a critical cyber asset is identified. The remaining standards identify security management controls, personnel and training, electronic security perimeters, physical security of cyber assets, systems security management, incident handling and recovery planning.
(no Actors, Interfaces, Maturity, or Category)

10.61 NIST SP 800-53
Application: NIST Special Publication 800-53 is a standard developed as a foundational level of security controls required for federal information systems. The standard provides a method for tailoring security controls to an organization. Appendix I of the document provides guidance for tailoring to industrial control systems (ICS).
Actors: Federal information systems
Interfaces: Interfaces between federal information systems
Maturity: Widely used by federal information systems
Category: Security –Gov NIST/ITL not a standard

10.62 NIST SP 800-82
Application: NIST Special Publication 800-82 Guide to Industrial Control Systems (ICS)
Security is a draft standard covers security guidance for SCADA systems, distributed control systems and other control system configurations. The standard defines ICS characteristics, potential threats and vulnerabilities to these types of systems, developing an ICS security program, network architecture and security controls.
Actors: Actors in distributed control environments
Interfaces: Interfaces in distributed control environments
Maturity: Just released
Category: Security – Gov NIST/ITL not a standard

Per one of the Roadmap author’s, Erich Guenther, DNP3 is the most popular utility automation protocol in North America.  According to a 2004 Newton-Evans survey, over 75% of North American utilities were already using or planning to use DNP3 in their SCADA networks.  It is applied throughout transmission and distribution networks, providing connections from master stations to substations, between devices within substations, and out to pole-top devices along feeders. DNP3 is an open standard and therefore a good candidate for the Smart Grid.  DNP3 is recognized in the IEEE 1379 standard for communications with Intelligent Electronic Devices (IEDs). DNP3 is a viable Smart Grid technology. DNP3 provides limited self-description of data, can be configured using XML, operates over the Internet protocol suite, and has proven to be an extremely reliable and self-healing technology.  Furthermore – at least until new additions are developed – there is no comparable IEC 61850 standard for the low-bandwidth and hostile distribution automation environment.  Given Guenther’s description of DNP3, why does the EPRI roadmap explicitly want to get rid of it?

The NERC CIPs are recognized as weak and inadequate. The NERC CIPs explicitly exclude electric distribution including home area networks which are the heart of the Smart Grid. NIST SP800-53 is quantifiably more comprehensive. Why aren’t the NERC CIPs “deprecated for new work”?

NIST SP800-53 is mandatory for all federal computing systems including federal power utilities. Non-federal power utilities electronically interface with federal power utilities. NIST SP800-53 is also directly relevant to non-federal utility computing systems including Smart Grid. Why the short-shrift?

NIST SP800-82 includes SCADA as well as process controls. However, the “Actor” and Interfaces” only include process controls.  NIST SP800-82 has been out in draft for several years and finalized almost a year ago. However, the Roadmap states it was just released. Again, why the short-shrift?

I have a hard time understanding the motives of the Roadmap. The DNP3 comment was particularly puzzling as it is widely supported, and it has security features that EPRI is currently testing. Also, NIST 800-53 and NIST 800-82 have a lot of good work and NIST SP800-53 is mandatory for federal entities. However, the Roadmap appears to be pushing them aside. What is going on here?

Joe Weiss

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • <p> On page 155 of the roadmap document, in section 11.5.2, the table entry "Coordination and Future-proofing AMI Systems" refers to something that I've never even heard of.  It says "The AMI systems should be able to handle, at a minimum, the IEC 61850 object models mapped to an “appropriate” protocol (possibly IEC 61850-lite when it is developed)." </p> <p> I was unaware that there are any formal efforts underway to create a 61850-lite. Even if the IEC did create such a thing, I still see a contradiction in terms. IEC-61850 is a very heavy duty protocol with extensive features designed for complex systems. </p> <p> Any effort to make a 61850-lite would be reinveting the wheel. The protocol already exists. It's called DNP. Yes, the same DNP that they would like to "deprecate for new work". </p> <p> On a positive note, at the top of page 156, I noticed that someone has finally recognized the hazards of using unlicensed spectrum. Now, if only we could figure out what to do about it... </p>

    Reply

  • <p> The arcane referral to DNP3 being deprecated in the NIST document is a misunderstood reference to the fact that the IEC technical committtee responsible for IEC 60870-101 and -104 (the IEC versions of DNP3) have deprecated these standards for new work. Instead, IEC TC57 WG10 will put any new work into IEC 61850 related standards. Nobody is seriously suggesting that DNP3 will not be a part of a smart grid especially where it is already widely deployed in the grid. </p> <p> IEC 61850 lite is a reference by some of the consultants involved in this work that desire to eliminate the transmission of strings in some of the IEC 61850 messages. For instance, report control block names are transmitted in reports. A report control block name could be quite long. </p> <p>  It is not an implication that IEC 61850 is too complex. IMHO it is not. It is more complex than DNP3. But, its complexity is warranted, appropriate, and not overwhelming. There are numerous benefits to using names to describe data, control blocks, etc. Minimal use of bandwidth is not one of the benefits. If you have limited bandwidth, DNP3 will be a better choice.  </p>

    Reply

  • <p> Well, all I can say is that it is a good thing this is still a draft. </p> <p> Regardless of the intent behind what was written, the text itself doesn't communicate any of this information. This will have to be fixed --particularly because load oriented utilities, such as water, are stuck with low bandwidth infrastructure for the forseeable future. I don't want someone reading this recommendation and coming to the conclusion that 61850 is the answer to our prayers. </p> <p> For all its performance and capabilities, 61850 has two major flaws: it uses lots of bandwidth, and it doesn't have object models for applications besides electrical distribution. I'll agree that the complexity is not overwhelming, but in industries where even DNP3 implementations seem complicated (and to Modbus users, it can seem that way at times ;-) ), this can be a daunting sell. </p> <p> We want the same thing. We want the load side of the grid to get smarter. The question is how. Limiting the scope before the goals have been clearly stated seems rather premature to me. </p>

    Reply

  • <p> I don't see DNP3 being the 61850-Lite that some are envisioning. The 61850-Lite that has been brought up in IEC discussions was dreamed up by a few people who believe that if you remove textual string descriptions from the IEC 61850 protocol (and a few other tweaks to save a byte here and there) then the bandwidth issues of 61850 would disappear and that IEC 61850 would become acceptable to everyone for all applications. This is a fantasy. There is no effort currently underway. </p> <p> There is nothing wrong with 2 protocols like IEC 61850 and DNP3 (or IEC 60870-5-10X) that were designed for and serve 2 different purposes. But let's not kid ourselves that DNP3 is 61850 Lite either. These are completely different protocols. There is no need to develop a new protocol for these same purposes. Is another protocol needed for AMI? Maybe. Should it use modeling concepts instead of register or index based addressing? IMHO: yes. If an AMI protocol based on 61850 modeling concepts ends up in one of the series of IEC 61850 standards numbers then I guess some might call it 61850-Lite. But it will be another protocol different from the existing protocols (maybe more similar to some then others) with a different purpose. If it was up to me I would suggest it shouldn't be a 61850 number just to avoid confusion. </p> <p> The reference to "future-proofing" is a simplistic way of stating that the abstract definition of models and services can be preserved when mapping these abstract concepts to a new protocol in the future. If all applications only deal with the abstract concept then they are isolated from the concrete encodings used by a protocol. Then those protocols can be swapped out in the future to accommodate new technology without breaking the applications. That is why the IEC 61850 object models are separated from the concrete protocols (called a Specific Communication Service Mapping or SCSM). But the abstract model imposes constraints making it impractical to map 61850 object models to just any protocol. For instance, it is not practical to map 61850 to DNP3 or the IEC 60870-5 protocols. You would have to change the protocol which defeats the whole point of doing it. </p> <p> While there is no reason that the object models for water or any other application space can't be developed to extend the usefulness of IEC 61850 into these spaces, I just don't see the interest in doing this. IEC 61850 is not the last protocol that will ever be developed. </p>

    Reply

  • <p> There are a few things that you may not have heard of, Ralph.  </p> <p> First, there already has been a successful demonstration of how one can map back and forth between 61850 and DNP. Most of the purpose for doing this is to allow for those who need to communicate between the two protocols. </p> <p> Second, Objects do exist in DNP. They're called data-sets. Third, DNP has new features including self description data for points, standardized XML configuration files, and new subset definitions. </p> <p> I think DNP is closer to being a 61850-lite than most people realize. Eventually, I expect we'll see new test procedures for the higher level subset definitions. </p> <p> What we seek is a way to transition between these two protocols so that users don't have to scrap what they have in place. Yes, 61850 is truly a protocol with a long future ahead of it. We have no desire to re-invent the wheel either. What we want to do, however, is to ensure that users don't have to completely re-engineer their entire SCADA systems to make the upgrade.   </p> <p> That said, the metering aspect of the smart grid may require a protocol of its own.  It will have to be something very lean and capable of running on embedded platforms inexpensively.  I have a hard time envisioning DNP or 61850 fitting this sort of application.   </p> <p> But you never know.  DNP over Zigbee anyone? </p> <p>   </p>

    Reply

  • <p> I understand those features of DNP3. I am sure they are useful features, but I am still unconvinced that DNP3 is really 61850 lite. Calling a data set an object doesn't quite cut it. It would be like calling Modbus DNP-Lite because you can transfer a 16-bit integer. Personally, I don't think DNP3 needs to be considered as "61850-Lite" or "Modbus on steroids" any more than 61850 should be considered "DNP3 on steroids". They are what they are. </p>

    Reply

RSS feed for comments on this page | RSS feed for all comments