Title: Message
>> In a
homogeneous control network, there is no need for
oBIX
I think this misses something. oBIX is
building controls to the Enterprise, which is different from Enterprise-wide
Building Controls. There is a
wealth of enterprise interactions out there that require several salient
features of oBIX whether or
not the control network is
homogenous.
1)
Abstraction: Can we give the
Enterprise User, who is not a trained engineer, a cohesive, coherent dashboard
on the controls world.
2)
Boxing: (or occlusion, or...)
Can we hide functions that are entirely appropriate g for the maintenance guys,
and for the integrators to do, but not appropriate for the Enterprise to do. I
don't want the SAP accountants getting access to loop
tuning.
3)
A preference for a common
taxonomy across systems (this is similar to (1) but I wanted to say it aloud) -
this should come out of the best practices.
If we accomplish 1-3 properly,
than interoperability between heterogeneous controls will come
automatically. An advantage will be that boxing and
abstraction will simplify inter-system integration, even if the two systems use
the same protocols.
Tc
"The best thinking has been done in
solitude. The worst has been done in turmoil." -- Thomas Alva
Edison
Toby Considine
Facilities Technology
Office
University of North Carolina
Chapel Hill, NC
Email:
Phone:
(919)962-9073
From: Jeremy
Roberts [mailto:]
Sent: Friday, October 29, 2004 11:19
AM
To: OBIX XML
Subject: RE: [obix-xml] RE: [obix-req]
Firewall traversal use cases
Charles,
I think you've
hit Levels 1 and 2 dead on.
However, the term "extension" used for Levels 3 and 4 may be slightly
off:
It is the goal
of oBIX to cover the interfaces to 3 and 4, but as a whole instead of as
parts. oBIX should cover the types
of data (Level 2) and their general normalization, but it should also cover the
Web Services -- which is how Levels 3 and 4 communicate with Level 2. The actual HMIs and loggers at those
upper levels is for developers of those platforms. We will provide the Level-3 and -4 hooks
those developers can use to access our Level-2
information.
As for
firewalls: I suspect the IT experts know how to get the SOAP bubbles through in
their individual installations. I
think you are right: that "we
(OBIX) don't need to concern ourselves with this
issue."
Thank you for
helping to clarify these issues because it's important that everyone have a
unified view of the big picture.
Since I am not a part of the [obix-req] email list, perhaps you can
forward this email thread to that list.
I think it's important for that list
too.
Cheers,
AUTOTEXTLIST \s "E-mail Signature" Jeremy
ROBERTS,
LONMARK
International
TEL: +1-215-918-1026
________________________________________________________________
-----Original
Message-----
From: Watson,
Charles D [mailto:]
Sent: Friday, October 29, 2004 10:41
AM
To: OBIX XML
Subject: RE: [obix-xml] RE: [obix-req]
Firewall traversal use cases
Jeremy, I
think we substantially agree. If I may summarize this e-mail
chain:
Level 1 -
No direct OBIX involvement
Level 2 -
Main OBIX involvement
Level 3 -
OBIX extension
Level 4 -
OBIX extension
Is this
correct in everyone's opinion?
The
original reason this chain was started was to discuss the need to need for
firewall traversal. In my opinion, we (OBIX) don't need to concern ourselves
with this issue. It will be covered by others as long as we use standard XML web
services to communicate data. The OBIX data will need to traverse firewalls
in many systems to get from Level 2 systems to Level 3 and higher systems. Sorry
I did not get this point out in my long e-mail below but it was necessary to get
the levels defined before it could be discussed.
Thanks,
Charles Watson (Chuck)
CEM CMVP
tel: 724-779-5937
http://www.eatonelectrical.com
-----Original
Message-----
From: Jeremy
Roberts [mailto:]
Sent: Monday, October 25, 2004 2:04
PM
To: OBIX XML
Subject: RE: [obix-xml] RE: [obix-req]
Firewall traversal use cases
Charles,
I'm sorry for adding my 2¢
so late to your comments. Travel is
my pathetic excuse.
oBIX should be concerned
with levels 2 through 4, as you have described them, below. The reason for acting at level 2 is
because at that level we have a transformation from the controls network to the
IT-interfacing specification (oBIX).
Level 1 is handled entirely by the controls network of choice (be that
BACnet, LonWorks, or any other installed device network). To propose oBIX at the buildings-control
level would mean modifying the massive installed base of controllers, actuators,
and sensors that have benefited from such existing controls network. Economics aside, for this group of
people in oBIX to redefine installation methods, configuration methods, and
general IT-like maintenance of the devices at the controls level would be far to
daunting a task, and would be a reinvention of the wheel (with arguably
something less robust that presently exists).
The controls networks can
reach as far as level 3 and 4 as well - and presently do. However, in a campus containing level-1
controls networks comprising more than one protocol, there is no
interoperability at levels 2 through 4 (or of course at level 1). It is this case/reason that oBIX is
needed: In a homogeneous control
network, there is no need for oBIX.
Level-two interfacing is the
heart from which oBIX stems: It
allows for a BACnet system to feed information to a black box, and a LonWorks
system to feed information to a different black box, where those two boxes then
convert the information to an IT-palatable, web-services -based set of
standardized "rules" (oBIX) to allow levels 3 and 4 to assimilate those data
into their appropriate systems.
Icing on the cake is being able to share those same data between systems
that play at levels 3 and 4 - with 4 being the primary field of high-level
sharing.
Unless I have missed, or
misinterpreted, something (which is always possible), this was and is the
goal.
Best
Regards,
AUTOTEXTLIST \s "E-mail Signature" Jeremy
ROBERTS,
Technical Director
LONMARK
International - http://www.lonmark.org/
Main
Technical Office - mailto:
PO
Box 268, Jamison PA 18929-0268, USA
Telephone:
+1-215-918-1026, Fax: +1-215-918-1027
________________________________________________________________
-----Original
Message-----
From: Watson, Charles D
[mailto:]
Sent: Monday, September 27, 2004 9:01
AM
To:
Subject: RE: [obix-req] Firewall traversal
use cases
This question depends
on where OBIX fits in the system scheme. If my understanding of the OBIX
scope from the last conference call is correct, we don't need to concern
ourselves with firewall traversal.
However, I don't agree
with the limited OBIX scope that was suggested on the conference call. I believe
we need to go lower in the system which means we may require communication
between remotely located devices communicating over the internet traversing
firewalls. We don't need to layout the exact method of communication at this
time because this standard has not even been 100% defined by the IT (MS and
others) powers concerned. But I believe we can layout some high-end standards
for data formats and minimum data content so that hardware and system
manufactures have something to guide them.
Let me explain for the
people who were not on the latest phone conference and to be clear I understood
what was discussed on the phone. We had a short discussion pertaining to the
different levels in a system and where OBIX should spend its time and
resources. The levels assigned here are my words, not what was discussed
on the phone but I believe the group needs to formally define these
levels.
Level
1: Communicating hardware devices: electrical meters, security and fire
alarm system components, HVAC components, etc.
Level 2: The
communicating gateway: This device normally communicates with the level 1
devices, packages/transforms the data, and communicates it up to a central data
logging system.
Level 3: Central
logging and alarming system: Collects, monitors, alarms, and logs the data
from the Level 2 systems and occasionally communicates with high-end level one
systems directly. This level is usually the HMI or visual process control level
of the system. The direct users of this system are still technical users who
have some understanding of the underlying hardware systems. These users are
usually concerned with how well and efficiently the system (HVAC, electrical,
etc.) operates from a technical perspective. They communicate with the system in
real time, know what is happening right now through direct interaction with the
system and the lower levels of the system.
Level 4: Enterprise
systems. This is where the accountants, building managers, and general
management interact with the system. These users usually have little
understanding of the lower level components and usually are concerned only with
how much it costs, not how it technically works. At this level, the
communication is usually via reports or some real time viewer
(dashboards) but not direct interaction.
Some of these levels
are combined in one device or system but a single device rarely constitutes the
entire system. So the format of communications between levels needs to be
defined. This is where OBIX needs to define the XML standards/guidelines
in my opinion. During the phone call, it was stated that OBIX should only be
concerned with the transfer of data at the higher end of this scheme:
between levels 3 and 4. I don't agree.
Although we don't want
to meticulously define the data interchange format between hardware devices
(level 1) and the level 2 & 3 systems, we do want to define some
standard of data content and some idea of its format. Otherwise, we will get to
the level 3 systems and the data may require complex transformation to get the
data into an acceptable format for the level 4 systems. There could even be data pieces missing.
If we start laying some data transfer standards/formats lower in the system, the
data will already be practically in an acceptable format for the next level with
minimal transformation
In summary, if you want
high-quality data at the top, you need to collect high-quality,
comprehensive data at the bottom. This means the rights pieces of data in
the right format at the right time. The exact method of data transfer can
be determined later.
Thanks,
Charles Watson (Chuck)
CEM CMVP
tel: 724-779-5937
http://www.eatonelectrical.com
-----Original
Message-----
From: Doug Ransom
[mailto:]
Sent: Friday, September 24, 2004 6:38
PM
To:
Subject: [obix-req] Firewall traversal use
cases
We
have not had any use cases involving firewall traversal. Is this an
issue.
Doug
Ransom
Energy Analytics
Domain Expert
Power
Measurement
2195 Keating Cross
Road
Saanichton, BC,
Canada V8M 2A5
Tel: (250)
652-7100 ext. 7558
Fax: (250) 652-0411
E-Mail:
mailto:
Website:
http://www.pwrm.com
ION® smart energy
everywhere(tm)
