Title: Message
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)
