[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] RE: [oBIX-xml] RE: [obix-req] Firewall traversal use cases
Toby, I had a feeling that sentence would furrow a few brows. After hitting send, I realized I should
have clarified that statement: Points 1, 2, and 3 are all things you can get from a good System
Integrator for a given controls network (if it is an open network). Standardized within a
control-networking platform, it’s available. Number 3 is quite a bit different from number 1 in that “across
systems” could mean “across control-network systems,” or “across enterprise
systems.” If “across
control-network systems” was meant, then a common taxonomy is indeed missing
from today’s solutions. However,
XML of one kind can be converted to XML of another kind; albeit, with a range
of effort to do such. It is the higher
needed effort that oBIX should be able to abrogate. It should be noted that LonMark is intending to adopt the resulting oBIX
solution as a native-to-LonWorks solution, rather than keeping our LonWorks -only
solution. So in this respect, while
we can accomplish 1, 2, and 3 with what we have, we would rather accomplish it
with oBIX -- a common interfacing platform to which any controls network could
adhere. So here, I would not say
that “no need” and “no desire” should be interchangeable. --- Jeremy ROBERTS, LONMARK International TEL: +1-215-918-1026 ________________________________________________________________ -----Original
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
From: Jeremy Roberts
[mailto:jeremy@lonmark.org] 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, Jeremy ROBERTS, LONMARK International TEL:
+1-215-918-1026 ________________________________________________________________ -----Original
Message----- 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,
-----Original 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, 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] 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,
-----Original
Message----- We
have not had any use cases involving firewall traversal. Is this an
issue.
Doug
Ransom
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]