RE: [obix-xml] Power Systems Group

["Considine, Toby (Facilities Technology Office)" <Toby.Considine@fac.unc.edu>]

This is beginning to feel [philosophically] more like UPNP - and I think
that is probably good.  We may want to have some sort of template/model
service guidance. "Well behaved services should leverage the following core
oBIX functionalities...

Perhaps a illustrative service for a turboencabulator?

For those who do not remember the finest flower of technical writing, I
include the original description of the turboencabulator. . .

The turbo-encabulator in industry. 

For a number of years now, work has been proceeding to bring perfection to
the crudely conceived idea of a machine that would not only supply inverse
reactive current for use in unilateral phase detractors, but would also be
capable of automatically synchronizing cardinal grammeters. Such a machine
is the "turbo-encabulator." Basically, the only new principle involved is
that instead of power being generated by the relative motion of conductors
and fluxes, it is produced by the medial interaction of magneto-reluctance
and capacitive directance. 

The original machine had a base plate of prefabulated amulite, surmounted by
a malleable logarithmic casing in such a way that the two spurving bearings
were in direct line with the pentametric fan. The latter consisted simply of
six hydrocoptic marzelvanes, so fitted to the ambifacient lunar waneshaft
that side fumbline was effectively prevented. The main winding was of the
normal lotus-0-delta type placed in panendermic semiboiloid slots in the
stator, every seventh conductor being connected by a nonreversible tremie
pipe to the differential gridlespring on the "up" end of the grammeters. 

Forty-one manestically spaced grouting brushes were arranged to feed into
the rotor slipstream a mixture of high S-value phenylhydrobenzamine and 5%
remanative tetryliodohexamine. Both of these liquids have specific
pericosities given by P=2.5C.nexp6.7 where n is the diathetical evolute of
retrograde temperature phase disposition and C is Chlomondeley's annular
grillage coefficient. Initially, n was measured with the aid of metaploar
refractive pilfrometer (for a description of this ingenious instrument, see
Reference 1), but up to the present, nothing has been found to equal the
transcendental hopper dadoscope (2). 

Electrical engineers will appreciate the difficulty of nubing together a
regurgitative purwell and a supramitive wennelsprock. Indeed, this proved to
be a stumbling block to further development until, in 1942, it was found
that the use of anhydrous nangling pins enabled a kryptonastic boiling shim
to the tankered. 

The early attempts to construct a sufficiently robust spiral decommutator
failed largely because of a lack of appreciation of the large quasi-piestic
stresses in the gremlin studs; the latter were specially designed to hold
the roffit bars to the spamshaft. When, however, it was discovered that
wending could be prevented by a simple addition to the living sockets,
almost perfect running was secured. 

The operating point is maintained as near as possible to the h.f. rem peak
by constantly fromaging the bitumogenous spandrels. This is a distinct
advance on the standard nivel-sheave in that no dramcock oil is required
after the phase detractors have been remissed. 

Undoubtedly, the turbo-encabulator has now reached a very high level of
technical development. It has been successfully used for operating nofer
trunnions. In addition, whenever a barescent skor motion is required, it may
be employed in conjunction with a drawn reciprocating dingle arm to reduce
sinusoidal depleneration. 

For more then 50 years the Arthur D. Little Industrial Bulletin has
endeavored to interpret scientific information in terms that he lay person
could understand. "The turbo-encabulator in industry" is the contribution of
J.H. Quick, graduate member of the Institution of Electrical Engineers in
London, England, and was, first published in the Institution's Students'
Quarterly Journal in December 1944.

tc
-----Original Message-----
From: Aaron Hansen [mailto:ahansen@tridium.com] 
Sent: Tuesday, December 21, 2004 4:44 PM
To: obix-xml@lists.oasis-open.org
Subject: RE: [obix-xml] Power Systems Group

I like a bunch of domain-specific services.  The security guys want a
service for CCTV so they can easily expose pan, tilt and zoom operations.
These don't belong in the current set of specs and read/write won't cut it,
especially if complex arguments are needed.

On the other hand, could these be generically handled by an action/command
service?

Sorry about all the email today, this is the last one.
Aaron

-----Original Message-----
From: Richards, Dave [mailto:drichards@trane.com]
Sent: Wednesday, December 15, 2004 1:44 PM
To: obix-xml@lists.oasis-open.org
Cc: RichardCHarwell@eaton.com
Subject: RE: [obix-xml] Power Systems Group


This brings up a big question that we haven't really considered yet (to my
knowledge).

Do we want to have a bunch of domain-specific services like this or do we
want to try to include everything in the basic services?  Even if there is a
serparate set of services, the same data would still be accessible through
the basic read.  What is the case for duplication?  Can some sort of
canonical naming scheme for use with the basic read be as effective as
specific services?  Is that even necessary?

Perhaps we need a joint meeting with the Power Systems SC to discuss the
direction we want to go on this?  That way we'll have a policy when the next
domain-specific group starts up.

The operations listed in the referenced doc can for the most part be done
with the basic read operation or the TBD history service.  The possible
exception is the request_peak_energy function.  Request_peak_energy just
isn't clear to me, but there seem to be calculations involved based on the
"timewindow" parameter, so I don't know if it fits the basic model or not.


Dave Richards


> -----Original Message-----
> From: ahansen@tridium.com [mailto:ahansen@tridium.com] 
> Sent: Wednesday, December 15, 2004 11:11 AM
> To: obix-xml@lists.oasis-open.org
> Cc: RichardCHarwell@eaton.com
> Subject: [obix-xml] Power Systems Group
> 
> 
> The power systems group has built a service description for 
> exchanging info with energy mgmt systems.
> 
> They would like us to review and comment on the next steps to 
> implementation in a way consistent with our services.
> 
> At this point, I think they'll be of more use to us than the 
> reverse.  Having their service in mind should help us with 
> issues such as the ext element.  Would it be best for them to 
> build their ideal schema/wsdl and the two of us adapt to each other? 
> 
> Take a look and we'll discuss at the next telecon (which at 
> this point won't be until next year).  If the link doesn't 
> work, their doc is available from the umbrella oBIX TC 
> document section.
> 
http://oasis-open.org/apps/org/workgroup/obix-power/download.php/10200/OBIX%
20Power%20System%20services.doc

On a slightly related note:
Some think of us as the HVAC group and that we should also be developing
higher level functions similiar to these.  My/our plate is full, is anyone
willing to head up an HVAC sig for this purpose?

Best,
Aaron