Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world?

["John Parello (jparello)" <[e-mail]>]

Ah simple edit!

We already start with physical equipment, then a physical Device then talk about the Device Class abstraction, so thanks we got that concenr of yours covered in the last rev.

Let's use the same notation ASHRAE used for (class) and we need to add a physical meter to be even clearer.

For reference the flow in the doc for device (which I'll make sure we follow for meter:)

Terminology:
Electrical Equipment

A general term including materials, fittings, devices, appliances, fixtures, apparatus, machines, etc., used as a part of, or in connection with, an electric installation.

Reference: [IEEE100]

Device

A piece of electrical or non-electrical equipment.

Reference: Adapted from [IEEE100]

Abstraction Section:

4.2.1 Device Class
The Device Class is a sub-class of Energy Object that represents a physical piece of equipment.
A Device Class instance may represent a physical device that contains other components.
BTW. The ashrae definition of Meter fits nicely to our evolution of equipment->device for physical.

Thanks!
Jp



________________________________
From: [e-mail] [[e-mail]] on behalf of Juergen Quittek [[e-mail]]
Sent: Tuesday, August 27, 2013 2:31 AM
To: Brad Schoening
Cc: eman mailing list
Subject: Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world?

Dear Brad,

Thank you for picking the ASHRAE example. It fully illustrates my concern.

If you read the text before the ASHRAE model elaboration that you cited on page 26, you will find on page 10 that ASHRAE first says

3.1.21. Meter
"Meters are devices which measure the amount of electricity used at a particular site. ..."

So ASHRAE exactly follows the approach to FIRST talk about the real world and THEN about a model of it.

We should follow the same approach in eman.

Cheers,
    Juergen


Am 20.08.2013 um 14:10 schrieb Brad Schoening <[e-mail]<mailto:[e-mail]>>:

Bruce & Juergen,

NIST uses the same modeling language and creates a meter as a distinct class of device, so we appear to be in good company.

For example, pg 29 of ASHRAE 201 'Facility Smart Grid Information Model':

ElectricMeter (Class)
The ElectricMeter Class is a subclass of the Meter Class. It is an abstract representation of devices that measure real
optionally reactive, energy consumption. These devices optionally measure other electrical parameters such as Present
Subinterval Demand or Power Quality.

Brad Schoening
Engineering | Coraid
Tel: [phone]
[e-mail]<mailto:[e-mail]> | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage


From: Bruce Nordman <[e-mail]<mailto:[e-mail]>>
Date: Tue, 20 Aug 2013 12:24:03 -0700
To: Juergen Quittek <[e-mail]<mailto:[e-mail]>>
Cc: eman mailing list <[e-mail]<mailto:[e-mail]>>
Subject: Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world?

I concur with Juergen's concern about how to approach the Framework.
A key concern I have is that the software modeling approach seems to
lead to a document which has more apparent complexity to the reader
than the alternative.   I say apparent because for implementation, the
result might be the same.  However, the apparent complexity is likely
to deter some people from implementing or using EMAN at all.
--Bruce


On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek <[e-mail]<mailto:[e-mail]>> wrote:
Dear all,

Before the IETF meeting I posted high-level comments on the new version of our framework draft (draft-ietf-eman-framework-08) and on the alternative framework proposal from Bruce (draft-nordman-eman-er-framework-01).

Now I send a series of individuals mails each focusing on a particular issue that I found in one or the other draft. For each issue I try to point out how the drafts address it and what the differences are.

My first point is about our very general approach to describe the eman framework: Do we start with describing a software design and map this to the real world? Or do we start with describing the physical world an derive a model from it?

The two drafts are quite different in that respect. draft-ietf-eman-framework-08 (EMAN Framework) rather develops the framework from a software model while draft-nordman-eman-er-framework-01 (ER Framework) starts from the physical world. Here is an example that illustrate the difference.

EMAN Framework section 4.2 Energy Object:

        4.2 Energy Object
An Energy Object is an abstract class that contains the base
        attributes for Energy Management.  There are three types of
        Energy Objects: Device, Component and Power Interface.

ER Framework, section 2.5 Energy Object:

2.5.  Energy Object
Devices, Power Interfaces, and Components are all Energy Objects (EOs).  The term
   "entity" in the Requirements draft generally corresponds to Energy
   Object.  The kinds of data available for an EO depends on its type as
   shown in Figure 1.

This is just one example out of many similar instances that can easily be found in those drafts.

The different choices made by the drafts result in different ways of describing the framework.

The ER Framework describes which information is reported for an Energy Object (power, state, voltage, etc.) while the EMAN framework tells us which attributes (power, state, voltage, etc) the class Energy Object has.

So the basic question that occurs to me is: Do we want to define our energy management framework as an object-oriented (software) model or do we want to describe a view of physical systems?

This would be the core question to be answered for addressing this issue.

Of course, in the end we need a data model for interoperable exchange of information based on our framework.
But for this purpose we already have other documents. Here the candidates for  are MIB modules using SMI that do not support the concepts of classes and inheritance (which also holds for YANG modules using XML).
:
Cheers,
    Juergen

_______________________________________________
eman mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eman




--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov<http://nordman.lbl.gov>
[e-mail]<mailto:[e-mail]>
510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/eman