Image Processing Reference
In-Depth Information
The same is true for oBIX services: only three network request types are defined at the WS level. The
first two of them are
read
(applicable to any object) and
write
(for writable objects). For operations
beyond basic “get” and “set,” custom operations can be defined on the oBIX level, just as any other
custom object. For invoking these operations a third base network request type
invoke
is provided.
Naming in oBIX is realized via two different, complementary concepts. First, every object can have
a
name
. It is used to identify a subobject within a composite object (e.g., consider an object with two
string members or two operations—their name tells them from each other). Second, every object
canbeassignedaURI(an
href
). This is necessary whenever an object is to be referenced from the
outside. To apply any network request (read, write, or invoke) to an object, this reference is required.
No higher-level semantics are associated with the URI namespace.
29.5.6.3 Comparison
he main difference between BACnet/WS and oBIX lies in their data model. While BACnet/WS pro-
vides a rather static type system and arranges nodes in a tree hierarchy, the oBIX data model is far
more flexible and does not predefine a particular arrangement of application related objects. For
example, the oBIX unit system is based on the flexible combination of SI base units, while BAC-
net/WS provides a predefined collection of text strings. As another, BACnet/WS offers a fixed set of
services for attribute access, while oBIX allows adding custom operations. While the simplicity of the
BACnet/WS data model makes it easily understandable, oBIX provides more possibilities due to its
extensibility.
In addition to SOAP, oBIX also supports a plain HTTP protocol binding. Both oBIX and
BACnet/WS leave security to the transmission channel and recommend the use of standard WS
security like HTTP over SSL/TLS and the WS-Security standard. oBIX further suggests imple-
menting permission-based degradation, which basically means that users should only see (and thus
manipulate) the objects they have permission for.
29.5.7 Home Automation
Adopting automation technology is equally attractive in the residential domain. Besides efficiency
considerations, increased comfort and peace of mind are key motives here. Also, elderly people can
live in their own homes longer (ambient assisted living, smart home care). The importance of this
aspect continuously increases as life expectancy does.
Despite having a considerable number of things in common, there is a difference between home
automation (residential settings) and building automation (functional buildings). Since mechanical
ventilation is seldom present in residential settings (although continuing attention to low energy
consumption can be expected to change this situation in the long run), lighting and shading control
have a more visible position in home automation than HVAC. Considerable emphasis is placed on
the integration of consumer electronics (entertainment systems) and household appliances.
Building automation focuses on the goals of energy efficiency, optimized management, and
detailed accounting. While energy efficiency is a growing concern in the residential domain as well,
the additional comfort and peace of mind a home automation system promises are still influential
decision factors. One obvious difference is the scale of the system: he number of devices involved
in a home automation project is by orders of magnitude lower than for large building automation
projects.
Nonetheless, the complexity of home automation projects must not be underestimated, not at
least since a large number of application domains must be integrated. All field, automation and
management functions mentioned are relevant. Both equipment as well as commissioning and main-
tenance cost have to be kept very low. Easy configuration is of particular importance, since the
disproportionately high setup cost will otherwise reduce the attractiveness of automation. his favors
