[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [smartgrid-discuss] Senate Hearings on Smart Grid - Cyber Security
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.