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,
Jeremy
ROBERTS,
Technical Director
LONMARK
International - http://www.lonmark.org/
Main
Technical Office - mailto:tech@lonmark.org
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:CharlesDWatson@eaton.com]
Sent: Monday, September 27, 2004 9:01
AM
To:
obix-req@lists.oasis-open.org
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:Doug.Ransom@pwrm.com]
Sent: Friday, September 24, 2004 6:38
PM
To:
obix-req@lists.oasis-open.org
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:doug.ransom@pwrm.com
Website:
http://www.pwrm.com
ION® smart energy
everywhere(tm)