Journal - BACnet Interest Group Europe eV

Die BACnet Dienste teilen sich in
zwei Klassen, A-Seite und B-Seite.
Wie wir gesehen haben, lässt sich
das sehr leicht mit A=Anforderer
(Client) und B=Bereitsteller (Server)
merken. Im BACnet-Standard
wird auch von dem Begriff „Initiate
= auslösen, initiieren“ für die
A-Seite bzw. „Execute = bearbeiten,
erledigen“ für die B-Seite gesprochen.
Abbildung 2 zeigt die funktionale
Gruppe DS-RP-A und DS-RP-
B, die Abkürzung DS steht hier
für Data-Sharing, also Datenaustausch
und RP für den Dienst
ReadProperty, mit dem eine einzelne
Eigenschaft eines Objektes gelesen
wird, z. B. der aktuelle Wert.
Gibt es in der Kommunikation
zweier Geräte eines, das die Funktion
DS-RP-A als Anforderer und
das andere die Funktion DS-RP-B
als Bereitsteller unterstützt, können
auf diese Weise Daten zwischen
den beiden ausgetauscht
werden.
Conformance Classes /
Functional Groups
In der ersten Ausgabe des BACnet
Standards 1995 wurde bereits der
Versuch unternommen, die verschiedenen
Funktionen zu Funktionsblöcken
als Geräteprofile zu
verankern. Dabei wurden die verschiedenen
Funktionalitäten in
Konformitätsklassen aufsteigend
eingeordnet, wobei jedes Gerät
einer höheren Klasse die Funktionen
der niedrigeren Klassen beinhaltete.
Es gab 5 Klassen für
Controller und eine Klasse für
Leittechnikprodukte sowie zusätzliche
Funktionsgruppen. Diese
Einteilung war jedoch sehr
strikt und hat sich in der Praxis
als wenig tauglich erwiesen. Dazu
kam, dass meist die höchste Konformitätsklasse
(Klasse 6) ausgeschrieben
wurde, hierbei handelte
es sich jedoch um das Profil einer
Leittechnik und wurde irrtümlich
auch für die Anforderungen an
Controller interpretiert.
Dieses Modell wurde daher ersetzt
und heute dienen die BIBBS,
BACnet Interoperability Building
Blocks oder auch Interoperabilitätsbausteine
genannt, zur Festlegung
des funktionalen Rahmens.
Im zweiten Teil dieses Artikels,
der demnächst hier erscheint, erfahren
Sie daher mehr über die
Möglichkeiten, anhand der BIBBs
Geräte und deren Funktionen
komfortabel miteinander zu vergleichen.
Gleichzeitig lernen Sie
die neuen Anforderungen an die
Leittechnikprofile kennen (vom
B-OD = Operator Display über B-
OWS = Operator Workstation bis
zur B-AWS = Advanced Operator
Workstation).
Wenn Sie aktuell Fragen zur Interoperabilität
und deren Bewertung
haben und nicht bis zur nächsten
Ausgabe des BACnet Europe
Journal warten können, steht Ihnen
der Autor gerne per E-Mail
zur Verfügung.
Interoperability, means the correct
interaction between different devices,
plays a major role especially
in multi-vendor projects. While in
homogeneous projects with only
one manufacturer functional interaction
can be easily expected, in
heterogeneous projects missing interoperability
may cause trouble.
To assure the best possible integration
BACnet already provides
methods to illustrate and compare
the supported functionality.
What is interoperability?
Interoperability describes the correct
interaction between two or
more devices within the range of
functionality supported by all devices.
Picture 1 shows according
to simple theory of sets that even
with a large set of functions in
each device, the common functional
range supported by all devices
may be only very small. Only
the functions supported by all devices
can be used congruously.
In worst case two devices cannot
inter-operate at all if there is no
common functionality.
To achieve the best possible depth
of integration it is necessary to find
the highest matching functionality
when selecting the devices.
Another aspect of interoperability
is the question of standardconformance.
Two devices may be
easily interoperable, but could still
violate the standard (if both manufacturers
made the same mistake).
Successful conformance testing
(this means strict compliance to
the standard) is the basic prerequisite
for subsequent interoperability.
Comparing the interoperability
w / o prior conformance testing is
useless!
PICS
From the first revision of the
standard BACnet covered the
functional comparison of BAC-
Anforderer
Initiator / Client
DS-RP-A
BACnet-Service Initiate Execute
Read Property X
Bereitsteller
Executor / Server
DS-RP-B
BACnet-Service Initiate Execute
Read Property X
Abbildung/Picture 2
net components. The PICS (Protocol
implementation Conformance
Statement) as a self-declaration
by the manufacturer describes the
functional range of a device, so
it covers aspects like “how much
BACnet is in a device” and which
functions are supported. Beyond
characteristics like the supported
character sets, segmentation
(transporting larger telegrams in
small segments), routing functions,
etc. first of all the supported
network media (data-link-layers),
the services and the object types
are referenced in this document.
For example in describing the object
types, the PICS illustrates if
dynamic object creation and deletion
is supported, a list of optionally
supported properties and the
capability to write certain properties.
With this questions like “Can
limits be changed via BACnet?” or
“Can a new schedule object be created
using BACnet services?” can
be clearly answered.
In many cases PICS documents are
required in quotations and are often
described as a prerequisite in
tenders. So they become a guarantee
of performance.
Testing the conformance of devices
the electronic form EPICS is
used as a prerequisite for handing
over the device to the laboratory.
Beyond all information contained
in a PICS, the EPICS additionally
contains a copy of the object database
of the device with all property
values.
A-Side / B-Side
BACnet is based upon the client
/ server model. A client is the
requester of the data provided by
a server. If there is only a provider
but no user (requester) or if there
is a requester but no provider the
BACnet insight
functional conformance is missing
and so this function cannot be
used for interoperability.
The services are specified in Aside
and B-side functions, while
A is the client and B is the server.
The client is the one initiating a request,
while the server executes it.
Picture 2 shows the functional
group DS-RP-A and DS-RP-B, the
short cut DS stands for Data-Sharing
and RP represents the service
ReadProperty (reads a single property
value from an object, e.g. the
present value).
If in a device relationship there is
one supporting DS-RP-A and the
other supports DS-RP-B both devices
can exchange values using
this service.
Conformance classes /
functional groups
In the first revision of the BACnet
standard in 1995 the first approach
was to define device profiles
as functional blocks using
conformance classes. The classes
were defined hierarchically where
higher classes contained all functions
of lower classes. A total of
5 classes represented controller
profiles, while class 6 represented
a workstation plus additionally a
few extra functional groups were
specified. This model was too
strict though and did not work
well in practice. Additionally class
6 was often used erroneously in
tenders to describe a controller
where class 6 actually specified a
workstation and not a controller.
This model was replaced and today
the so-called BIBBS = BACnet
Interoperability Building Blocks
are used to specify the functional
range.
In the upcoming second part of
this article you will learn more
about how to compare devices and
functions using the BIBBs plus it
will provide an overview about
the new requirements for workstations
(from B-OD = Operator Display
to B-OWS = Operator Workstation
to B-AWS = Advanced Operator
Workstation).
If you have current questions
about interoperability and cannot
wait for the second part issued in
the next BACnet Europe Journal,
don’t hesitate to contact the author
by E-Mail.
BACnet Europe Journal 14 03/11 37