RE: [smartgrid-interest] Draft Charter - Energy Market Information Exchange

[ngreenfield@aep.com]

The easiest way to answer this question
is to go back to an old term - FCAPS.

It's all well and good that vendors
have a number of different native languages and proprietary protocols,
and that's great, if you operate in a single vendor environment.  At
one time, that may have been possible, but I don't believe it is today.

What seems to always be forgotten is,
what happens after you've implemented and deployed all of these technologies?
 There is the operational component that almost everyone tends to
forget.  It's one of those things that's added after the fact (like
security, for instance), which I vehemently argue against doing.

There needs to be a common framework,
mechanism, protocol, etc., that give organizations the ability to manage
these technologies at the enterprise level.  Whether it's IP or some
other protocol, it needs to be common among all of the technologies.

FCAPS is a standard framework that both
ISO and ITU-T have turned into international standards.  ISO came
up with "CMIP", or Common Management Information Protocol, which
is a mechanism for implementing "CMIS", or Common Management
Information Services.

ITU-T has a series of "recommendations"
in the X.700 series and M.3000 series (free for downloading) that should
be looked at.  Another standard that has been developed, of course,
is the IETF's SNMP standard, which is IP based.  If you look at SNMP,
only use Version 3.  The others are essentially obsolete.  RFCs
3411, 3418 and 3584 are good references for SNMPv3.

FCAPS, by the way, stands for:

Fault Management
Capacity Management
Accounting Management
Performance Management
Security Management

FCAPS is all about metrics and the business
side of things.  It is an enabler of the business to make sure that
organizations are getting an effective ROI. 

I realize some people will say that
FCAPS is oriented only towards IT or telecommunications, but this framework
contains some very good principles on the business side of the house.

Additionally, the proposed FERC Smart
Grid Policy document specifically requires that all Smart Grid technologies
must incorporate, at a minimum, the following Cyber Security services:

• Integrity of data communicated
• Authentication of the communications
• Prevention of unauthorized modifications to Smart Grid devices
• Logging of all modifications made
• Physical protection of Smart Grid devices

These Cyber Security services
enable the identification of potential impact of unauthorized use of Smart
Grid devices on the bulk-power system.  This is an argument for common
protocols to be used between devices.  

Best regards,

Neil Greenfield

"Michel Kohanim" <michel@universal-devices.com>

04/02/09 01:40 AM

Please respond to
<michel@universal-devices.com>

To	<smartgrid-interest@lists.oasis-open.org>
cc
Subject	RE: [smartgrid-interest] Draft Charter - Energy Market Information         Exchange

Hi Brian, I had to think
about this for a day! Perhaps my statements are going to cause a heated
debate, but, here I go:
 
I really do not see why everything
has to communicate IP. What’s wrong with having devices communicate in
their own native languages and over their desired (most optimal) media?
What do we gain by having all devices communicate IP if – and as you (Brian)
suggested – we do not first come up with the abstract model? We have a
hammer?
 
With kind regards,
 
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
 
(p) 818.631.0333
(f) 818.708.0755
http://www.universal-devices.com
********************************
 
From: Brian Frank [mailto:brian@skyfoundry.com]
Sent: Tuesday, March 31, 2009 11:11 AM
To: smartgrid-interest@lists.oasis-open.org
Subject: Re: [smartgrid-interest] Draft Charter - Energy Market Information
Exchange
 
Couple of my thoughts since Toby
cross-posted some of my oBIX ideas...

I don't suspect that many in this group need to be convinced that technologies
like 6LoWPAN create the opportunity to communicate IP all the way out to
the edge.  In fact, it is hard to imagine using anything but IP for
communication these days - even for sub $10 devices (legacy devices excluded
of course).

But just because a 6LoWPAN device speaks IP doesn't necessarily mean that
it going to run a SOAP stack:
  - These are typically sub-3$ dollar microprocessors with less than
100KB of memory
  - Low end wireless networks don't run TCP well,  only UDP;
this means common techniques for end-to-end security such as TLS are not
available
  - Payload size on a 6LoWPAN packet is ideally less than ~80 bytes
  - 6LoWPAN nodes spend most of their time sleeping which makes communication
difficult

But these are all surmountable problems if you define an information model
which works well end-to-end.  Translating between protocols (HTTP-to-UDP)
is pretty easy.  Translating between data encodings is also easy (XML-to-Binary).
 But translating between data models is really, really hard and almost
always results in a degradation of information.

So my perspective is that the most important task is define the abstract
model.  Then you can apply different protocols and encoding as needed
as long as everyone is working off the same basic ontology.  

This is exactly what oBIX does.  It defines a very simple, but powerful
meta-model for building models.  The oBIX meta-model is based on type
theory that embraces the notion that modeling the real-world is a messy
and inexact science.  But it turns out to work really well for simple
sensors all the way up to million point SCADA systems.

Brian

S/MIME Cryptographic Signature