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

[Juergen Quittek <[e-mail]>]

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]>:

> 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] | www.coraid.com 
> Coraid: Redefining Storage
> 
> 
> From: Bruce Nordman <[e-mail]>
> Date: Tue, 20 Aug 2013 12:24:03 -0700
> To: Juergen Quittek <[e-mail]>
> Cc: eman mailing list <[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]> 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]
>> https://www.ietf.org/mailman/listinfo/eman
> 
> 
> 
> -- 
> Bruce Nordman
> Lawrence Berkeley National Laboratory
> nordman.lbl.gov
> [e-mail]
> 510-486-7089
> m: 510-501-7943
> _______________________________________________ eman mailing list [e-mail] https://www.ietf.org/mailman/listinfo/eman