Good observations and a couple good
points.
Developing consensus standards of high
quality takes time. 9 to 12 months to get to a workable draft is very
aggressive, with 2 years to get to final draft still pretty
optimistic. We can think generally of the process in stages:
1. Establish need and scope (concept
validation)
2. Develop technical approaches and consensus
leading to a draft standard
3. Validation of the draft standard within the SDO
4. Final Approval (which usually involves
approval by people not involved in development of the draft
standard)
Very often vendors take the risk of implementing
draft standards during the third phase (while the standard is still being vetted
inside the SDO) once it looks as though it is fairly stable. This can have mixed
results, and in several examples in my experience, the overall process of both
standard completion and market adoption is actually lengthened considerably when
this is done (if different vendors interpret drafts differently when there are
still missing bits, and thus produce non-interoperable solutions, the market
sours on the technology and it can take a while to get over it). Other
times it works fine. Deciding when the risk is reasonable takes a lot of
experience, in depth knowledge of the standard, the process by which it was
drafted, good timing and a bit of luck (though as a famous golfer once said, the
more I practice, the luckier I seem to get ;-).
Sometimes if the standard is drafted too quickly
the overall time to adoption is actually longer, like many things. IMO the
primary purpose (only purpose?) of standards is to achieve interoperability, and
strong emphasize of this over all other goals during the drafting process seems
to help; it may take a bit more time up front but like so many things if spent
well that time pays back quickly with an overall shorter time to reaching the
goals.
Another trade-off is that the wider the
participation, the better the standard, but the more participants
the longer it takes to reach a true consensus. The term 'consensus can
mean different things to different people, even when operating in the same
SDO with the same rules. It may mean we combine ideas and find a workable
merged approach, or it might mean I can get more votes than you so I
win (and many shades between). I'll agree with Joe that funding
can help broaden participation (I sure wouldn't mind it ;0), but other outside
pressures can actually stifle the process. When consensus is forced both
quality and schedule can suffer.
One way to accelerate the process is when the SDO
task group has a very well defined and focused scope. This tends to narrow down
the options and lead to some obvious 'good enough' points rapidly.
The better we understand the problem to be solved, the easier that is. The flip
side of that is that in many cases what we think we know becomes obsolete
knowledge rapidly, and the problem we think we're solving changes by the time
we're done; too narrow a view leads to irrelevance.
A recurring theme in SG discussions seems to be a
fixation on how things have always been done. I think we need to think beyond
traditional models, because communications technology is an enabler of new ways
to do things. I believe technology will alter the barriers and balances to
new architectures, for example, distributed generation and local storage will
become viable in places it hasn't been so far, and will completely change the
game. The work on SG, mostly based
on what we know to be the rules of the game are today, will be a catalyst that
will change the rules completely. So how hard can it be to characterize that
problem?
Just some things to think about as we try to
maintain useful perspective.
-Ben
Sent: Thursday, March 05, 2009 6:48
PM
Subject: [smartgrid-discuss] Senate
Hearings on Smart Grid - Cyber Security
I had an opportunity to listen to the Smart Grid Hearings
held March 3 with the Senate Energy and Natural Resources Committee. NIST
Director, Pat Gallagher, DOE’s Pat Hoffman, FERC Commissioner Kelly, Commissioner Butler of NARUC,
Katherine Hamilton of the GridWise Alliance, Edward Lu of Google, and Evan Gaddis of NEMA testified.
I was obviously interested in what was being said about
cyber security and will focus on that. It was gratifying to
see that many presenters and Senators recognized the importance of cyber
security. My observations were:
- FERC Commissioner Suedeen Kelly stated
that NIST Standards were “good enough” for the Smart Grid. If they are good
enough for the Smart Grid and for all federal agencies including federal
utilities such as TVA, BPA, and WAPA, they should certainly be good enough for
the NERC CIPs. She also made the connection between security and reliability
which I thought was right on. She went on to state the need to coordinate ac
ross “people” boundaries – FERC (transmission) and NARUC (distribution).
Hopefully, that same approach will be applied to the security of the equipment
where the CIPs currently exclude distribution.
- Senator Dorgan from North Dakota mentioned there should
be demonstration projects for cyber – again, right on!
- Senators Murkowsky and Cantwell discussed the need for
Internet Protocols (IP) for the Smart Grid which is specifically included in
the Stimulus Bill. That leads to the question of why, if IP is good for Smart
Grid applications, have many utilities been removing IP connections from
“non-Smart Grid” transmission applications? Unfortunately, the answer is
obvious - to avoid having to comply with the NERC CIPs by using the loophole
of having to only address routable protocols.
- Based on the discussions and written testimony (as well
as experience with the NERC CIPs), there is a substantial need for developing
good, useable metrics for really measuring security (see previous blog on
compliance vs security). This is even more important for
the Smart Grid which transcends Transmission and Distribution (T&D) where
the CIPS only partially apply.
Other non-security observations:
- The focus of the Smart Grid was on T&D and customers
and not on power generation. Consequently, there was no mention of ISA or
process controls in the prepared testimony, presentations, or question/answer
sessions.
- NEMA mentioned that consensus standards can be developed
in 9-12 months. That is VERY optimistic. Generally, consensus standards take
several years to develop and get approved. Consensus standards organizations
are also voluntary. Attempting to speed up the development process may take
outside funding to “modify” the voluntary process.
Joe Weiss