Service Indication Hooks mit Implementierung von Standard-Aktionen

Nachdem die Gültigkeit der Anfrage verifiziert wurde, versucht das API, das angegebene Objekt zu finden. Wenn es das Objekt gibt und wenn der Time Stamp-Parameter mit der Zeit übereinstimmt, zu der das Ereignis zuletzt bestätigt wurde, dann geschieht Folgendes: Das Bit in der Acked_Transitions-Property des Objekts, das mit dem Wert des Event State Acknowledged-Parameters übereinstimmt, wird auf 1 gesetzt, ein Basisergebnis result(+) wird angelegt, und eine Ereignismeldung mit einem Notify Type-Parameter gleich ACK_NOTIFICATION wird ausgegeben. Wenn kein Objekt gefunden wird, wird ein Basisergebnis result(-) ausgegeben. Eine Bestätigungsmeldung verwendet denselben Service-Typ (bestätigt oder unbestätigt), gerichtet an dieselben Empfänger, an die die ursprüngliche bestätigte oder unbestätigte Ereignismeldung gesendet worden war. Der Time Stamp, der in der Bestätigungsmeldung übertragen wird, wird nicht vom Time Stamp der ursprünglichen Ereignismeldung abgeleitet, sondern enthält die Zeit, zu der die Bestätigungsmeldung generiert wird.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, sucht das API alle ereignisauslösenden Objekte, die eine Event_State-Property ungleich NORMAL haben, sowie eine Notify_Type-Property mit Wert ALARM. Eine positive Antwort wird zusammengebaut, die die Alarm Summaries für die in der Suche gefundenen Objekte enthält. Wenn keine Objekte, die diesen Kriterien entsprechen, gefunden werden, wird eine Liste der Länge 0 zurückgegeben.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, sucht das API alle ereignisauslösenden Objekte, die den in der Basisanfrage angegebenen Suchkriterien entsprechen. Die Suchkriterien sind die logischen Verknüpfungen aller explizit gesetzten Filter, die in der Basisanfrage ausgelassen wurden. Eine positive Antwort wird zusammengebaut, die die Enrollment Summaries für die in der Suche gefundenen Objekte enthält. Wenn keine Objekte, die diesen Kriterien entsprechen, gefunden werden, wird eine Liste der Länge 0 zurückgegeben.

Wenn es weder Lifetime noch Issue Confirmed Notifications gibt, dann wird die Anfrage als Stornierung interpretiert. Jeder COV-Kontext, der bereits für die gleiche BACnet-Adresse existiert und in der PDU enthalten ist, die die SubscribeCOV-Anfrage befördert und denselben Subscriber Process Identifier und Monitored Object Identifier hat, wird deaktivert und ein SimpleAck wird zurückgegeben. Erstellte Stornierungen, für die kein passender COV-Kontext gefunden wird, werden erfolgreich durchgehen, wie wenn ein Kontext existieren würde, und sie geben ein SimpleAck zurück. Wenn es keine Lifetime-Parameter, aber einen Issue Confirmed Notifications-Parameter gibt, dann wird ein Wert Null (unbegrenzte Lebensdauer) für lifetime angenommen. Wenn es den Issue Confirmed Notifications-Parameter gibt, aber das zu überwachende Objekt das COV-Reporting nicht unterstützt, dann wird ein Fehler ausgegeben. Wenn das zu überwachende Objekt COV-Reporting unterstützt, dann wird geprüft, ob es einen COV-Kontext für die gleiche BACnet-Adresse gibt, die in der PDU enthalten ist, die die SubscribeCOV-Anfrage enthält und den gleichen Subscriber Process Identifier und Monitored Object Identifier hat. Wenn ein existierender COV-Kontext gefunden wird, dann wird die Anfrage so behandelt als ob die Subskription neu gemacht wird. Wenn kein COV-Kontext gefunden wird, der der Anfrage entspricht, dann wird ein neuer COV-Kontext erstellt, der die BACnet-Adresse der PDU enthält, die die SubscribeCOV-Anfrage enthält und den gleichen Subscriber Process Identifier und Monitored Object Identifier hat. Wenn kein Kontext erstellt werden kann, dann wird ein Fehler zurückgegeben. Wenn ein neuer Kontext erstellt wird, oder eine neue Subskription erhalten wird, dann wird der COV-Kontext initialisiert und erhält eine Lebensdauer gemäß Lifetime-Parameter, falls es diesen gibt, oder 0 falls es den Parameter nicht gibt. Die Subskription wird automatisch abgebrochen, nachdem viele Sekunden vergangen sind ohne dass eine erneute Subskription erhalten wurde. Eine Lebensdauer von 0 zeigt an, dass die Subskription unbegrenzt ist und es wird nicht automatisch abgebrochen. In jedem Fall wird SimpleAck zurückgegeben. Eine ConfirmedCOVNotification oder UnconfirmedCOVNotification wird sobald als möglich nach erfolgreichem Abschluss einer Subskriptions- oder Resubskriptionsanfrage erstellt, wie im Issue Confirmed Notifications-Parameter angegeben.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, versucht das API, das Objekt, das im Object Identifier-Parameter identifiziert wird, zu verändern. Wenn das identifizierte Objekt existiert und die Property besitzt, die im Property Identifier-Parameter angegeben ist, dann wird versucht, alle im List of Elements-Parameter aufgelisteten Elemente zur angegebenen Property hinzuzufügen. Wenn dies gelingt, wird ein Basis-SimpleAck erzeugt. Wenn eines oder mehrere der Elemente bereits in der Liste stehen, werden sie ignoriert, also nicht mehr zur Liste hinzugefügt. Das Ignorieren eines bereits vorhandenen Elements verursacht kein Fehlschlagen des Services. Wenn jedoch das angegebene Objekt nicht existiert, wenn die angegebene Property nicht existiert oder keine Liste ist, dann wird der Service fehlschlagen und eine Basis-Fehlermeldung wird erzeugt. Wenn eines oder mehrere Elemente nicht zur Liste hinzugefügt werden können und auch noch nicht bereits in der Liste enthalten waren, dann wird eine Basis-Fehlermeldung erzeugt und es werden überhaupt keine Elemente zur Liste hinzugefügt. Die Wirkung des Services ist also, alle angegebenen Elemente der Liste hinzuzufügen, die dort noch nicht enthalten sind, oder überhaupt keine Elemente zur Liste hinzuzufügen.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, versucht das API, das Objekt, das im Object Identifier-Parameter identifiziert wird, zu verändern. Wenn das identifizierte Objekt existiert und die Property besitzt, die im Property Identifier-Parameter angegeben ist, dann wird versucht, alle im List of Elements-Parameter aufgelisteten Elemente aus der angegebenen Property zu entfernen. Wenn eines oder mehrere Elemente nicht existieren oder aufgrund mangelnder Berechtigung oder anderer Probleme nicht entfernt werden können, dann wird keines der Elemente entfernt und eine Basis-Fehlermeldung wird erzeugt.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, versucht das API, auf die angegebene Property des angegebenen Objekts zuzugreifen. Wenn der Zugriff gelingt, wird eine Basis-ComplexAck erzeugt, die den gelesenen Wert zurückgibt. Wenn der Zugriff fehlschlägt, wird eine Basis-Fehlermeldung erzeugt, die die Ursache für das Fehlschlagen anzeigt. Wenn der object-type im Object Identifier-Parameter den Wert Device Object enthält und die Instanz im Object Identifier-Parameter den Wert 4194303 enthält, dann behandelt das API den Object Identifier wie wenn er korrekt dem lokalen Device-Objekt entspricht. Dies ermöglicht eine Device-Instanz eines Geräts, das keine I-Am-Meldungen erzeugt, um bestimmt werden zu können.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, versucht das API, auf die angegebene Property des angegebenen Objekts zuzugreifen. Es wird eine List of Read Access Results konstruiert, deren Reihenfolge in der Anfrage spezifiziert ist. Wenn der List of Property References-Anteil des List of Read Access Specifications-Parameters den Property-Identifizierer ALL, REQUIRED oder OPTIONAL enthält, dann wird die List of Read Access Results so zusammengebaut, als ob jedes zurückgelieferte Property explizit referenziert worden wäre. Es gibt keine Anforderung, dass die Anfrage „automatisch“ ausgeführt wird, dennoch wird das API sicherstellen, dass alle Lesevorgänge in der kürzestmöglichen Zeit erfolgen und dabei nur höherprioren Abarbeitungen unterworfen sind. Die Anfrage wird solange abgearbeitet, bis ein Versuch unternommen wird, auf alle angegebenen Propertys zuzugriefen. Wenn keines der angegebenen Objekte gefunden wird oder auf keine der angegebenen Parameter der angegebenen Objekte zugegriffen werden kann, dann wird ein Basis-Fehler oder ein Basis-ComplexAck, das Fehler-Codes für alle Propertys zurückgibt, erzeugt. Wenn mindestens auf eines der angegebenen Propertys für die angegebenen Objekte zugegriffen werden kann, dann wird ein Basis-ComplexAck erzeugt, das die gelesenen Werte zurückgibt, sowie Fehler-Codes für alle Propertys, auf die nicht zugegriffen werden konnte. Wenn der object-type im Object Identifier-Teil des Read Access Specification-Parameters den Wert Device Object enthält, und die Instanz dieses Object Identifier-Parameters den Wert 4194303 enthält, dann behandelt das API den Object Identifier wie wenn er korrekt dem lokalen Device-Objekt entspricht. Dies ermöglicht eine Device-Instanz eines Geräts, das keine I-Am-Meldungen erzeugt, um bestimmt werden zu können.

Für BACnet-Server-Anwenderapplikationen, die die interne Datenbank nicht nutzen können und deshalb Unterstützung für den ReadPropertyMultiple-Service implementieren müssen: Sie müssen nur den ReadProperty-Service Hook implementieren, weil ReadPropertyMultiple-Anfragen intern in einzelne ReadProperty-Anfragen aufgeteilt werden und die Fertigstellungen gesammelt werden um die Antwort zu erstellen.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, versucht das API, das angegebene Property im angegebenen Objekt zu verändern, wobei es den im Property Value-Parameter bereitgestellten Wert verwendet. Wenn der Änderungsversuch erfolgreich ist, wird ein Basis-SimpleAck erzeugt. Wenn der Änderungsversuch fehlschlägt, wird eine Basis-Fehlermeldung erzeugt, die die Ursache des Fehlschlagens anzeigt.

Für jedes Write Access Specification, das in der List of Write Access Specifications enthalten ist, wird der Wert jeder angegebenen Property mit dem Property-Wert ersetzt, der in Write Access Specification angegeben ist, und ein Basis-SimpleAck wird erzeugt, das anzeigt, dass die Service-Anfrage komplett abgearbeitet wurde. Die vorgesehenen Propertys werden in der Reihenfolge abgearbeitet, die in der List of Write Access Specifications vorgegeben ist. Wenn während der Abarbeitung ein Property an der Reihe ist, das nicht geändert werden kann, dann gibt der PI eine Basis-Fehlermeldung aus, die die Ursache für das Fehlschlagen anzeigt. Das Ergebnis dieses Services ist entweder, dass alle der angegebenen Propertys erfolgreich geändert werden, oder nur diejenigen bis zum - aber nicht einschließlich desselben - Propertys, das im First Failed Write Attempt-Parameter angegeben ist. Ein BACnet-Reject-PDU wird nur erzeugt, wenn keine Schreibaktionen erfolgreich ausgeführt wurden. Es zeigt an, dass die Service-Anfrage komplett zurückgewiesen wurde. Wenn eine der Schreiboperationen, die in der List of Write Access Specifications enthalten sind, nicht erfolgreich ausgeführt werden konnte, wird eine Fehlermeldung zurückgegeben, die die Ursache für das Fehlschlagen anzeigt, wie oben beschrieben.

Die API wird verifiziert zunächst die Gültigkeit der Object Identifier, Property Identifier- und Property Array Index-Parameter und gibt eine Fehlermeldung mit entsprechender Fehlerklasse und -Code zurück, falls das Objekt oder die Property unbekannt sind, falls die referenzierten Daten keine Liste oder ein Array sind, oder falls gerade aus anderen Gründen kein Zugriff möglich ist. Wenn es den Range-Parameter nicht gibt, dann liest das API alle verfügbaren Elemente in der Liste oder im Array und versucht sie zurückzugeben. Wenn es den Range-Parameter gibt, und er die By Position-Parameter angibt, dann liest das API alle angegebenen Elemente und versucht sie zurückzugeben. Die angegebenen Elemente schließen das Element an derjenigen Indexposition ein, die durch Reference Index definiert ist, plus die bis Count - 1 folgenden, wenn Count positiv ist, oder die bis -1 - Count vorangehenden, wenn Count negativ ist. Das erste Element einer Liste wird mit Index 1 verknüpft. Wenn es den Range-Parameter gibt und er den By Time-Parameter angibt, oder die By Sequence Number-Parameter, dann weist das API die Anfrage zurück, indem es eine Fehlermeldung mit entsprechender Fehlerklasse und -code zurückgibt. Die zurückgelieferte Antwort überträgt mit Hilfe des Item Count-Parameter die Anzahl der gelesenen und zurückgegebenen Elemente. Die aktuellen Elemente werden im Item Data-Parameter zurückgegeben. Wenn die zurückgegebene Antwort den ersten Positionsindex einschließt, dann ist im Result Flags-Parameter das FIRST_ITEM-Flag auf TRUE gesetzt, ansonsten auf FALSE. Wenn die zurückgelieferte Antwort den letzen Positionsindex einschließt, dann ist in Result Flags das LAST_ITEM-Flag auf TRUE gesetzt, ansonsten auf FALSE. Wenn in der Liste keine Elemente sind, die den Range-Parameter-Kriterien entsprechen, dann wird ein ComplexAck mit einem Item Count of 0 und keinem First Sequence Number-Parameter zurückgegeben.

Die Standardimplementierung dieses Services unterstützt NICHT den Zugriff auf das Property log-buffer der Trend- und Event-logging Objekte. Wenn eine Anwenderappliaktion Logging-Objekte unterstützen muss, dann müssen Speicherung und Zugriff auf die Daten von der Anwenderapplikation implementiert werden.

Wenn es weder Lifetime noch Issue Confirmed Notifications gibt, dann wird die Anfrage als Abbruch interpretiert. Jeder COV-Kontext, der bereits für die gleiche BACnet-Adresse existiert, die in der PDU enthalten ist, die die SubscribeCOVProperty -Anfrage befördert und denselben Subscriber Process Identifier, Monitored Object Identifier und Monitored Property Identifier hat, wird deaktiviert und ein SimpleAck wird zurückgegeben. Auftretende Abbrüche, für die kein passender COV-Kontext gefunden wird, werden erfolgreich abgehandelt, als wäre ein Kontext vorhanden. Sie geben SimpleAck zurück. Wenn ein COV-Kontext gefunden wird, wird er aus dem Active_COV_Subscriptions-Property im Device-Objekt entfernt. Wenn es den Issue Confirmed Notifications-Parameter gibt, jedoch die zu überwachende Property das COV-Reporting nicht unterstützt, dann wird eine Fehlermeldung zurückgegeben. Wenn das zu überwachende Property COV-Reporting unterstützt, dann wird geprüft, ob ein COV-Kontext für die gleiche BACnet-Adresse existiert, die in der PDU enthalten ist, die die SubscribeCOVProperty -Anfrage befördert und den gleichen Subscriber Process Identifier, Monitored Object Identifier und Monitored Property Identifier hat. Wenn ein bestehender COV-Kontext gefunden wird, dann wird die Anfrage als Resubskription interpretiert und erfolgreich behandelt, als wäre es eine neu erzeugte Subskription. Wenn kein COV-Kontext gefunden wird, der zur Anfrage passt, dann wird ein neuer COV-Kontext erzeugt. Er enthält die BACnet-Adresse aus der PDU, die die SubscribeCOVProperty-Anfrage befördert, und den gleichen Subscriber Process Identifier, Monitored Object Identifier und Monitored Property Identifier. Der neue Kontext wird in das Active_COV_Subscriptions-Property des Device-Objekts eingeschlossen. Wenn kein Kontext erzeugt werden kann, wird eine Fehlermeldung zurückgegeben. Wenn ein neuer Kontext erzeugt wurde, oder eine Resubskription erhalten wurde, dann wird der COV-Kontext initialisiert und er erhält eine Lebensdauer wie im Lifetime-Parameter definiert. Die Subskription wird automatisch abgebrochen, wenn nach vielen Sekunden noch keine Resubskription erhalten wurde. Ein SimpleAck wird zurückgegeben und eine ConfirmedCOVNotification or UnconfirmedCOVNotification wird sobald als möglich nach erfolgreichem Abschluss einer Subskriptions- oder Resubskriptionsanfrage erstellt, wie im Issue Confirmed Notifications-Parameter angegeben.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, sucht das API nach allen ereignisauslösenden Objekten, die die folgenden Bedingungen erfüllen, beginnend mit dem Objekt nach dem (in aufsteigender interner Reihenfolge der Objektinstanzen) Objekt, das mit dem Last Received Object Identifier-Parameter definiert ist: Ob diese ein Event_State-Property haben, dessen Wert ungleich NORMAL ist, oder ob sie ein Acked_Transitions-Property haben, das mindestens eines der folgenden Bits auf FALSE gesetzt hat: TO-OFFNORMAL, TO-FAULT, TO-NORMAL. Eine positive Antwort, die die „Event Summaries“ für Objekte enthält, die bei dieser Suche gefunden wurden, wird zusammengebaut. Wenn keine Objekte gefunden werden, die die Kriterien erfüllen, dann wird eine Liste der Länge Null zurückgeliefert. So viele Objekte, wie innerhalb der APDU zurückgeliefert werden können, werden zurückgeliefert. Wenn mehr Objekte existieren, die die Kriterien erfüllen, aber nicht in der APDU zurückgeliefert werden können, wird der More Events-Parameter auf TRUE gesetzt, ansonsten wird er auf FALSE gesetzt.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, fügt das API die erhaltene Information dem Device-Objekt-Property Address_Binding hinzu. Dieses wird verwendet, um die Geräte-Instanznummern in BACnet-MAC-Adressen aufzulösen, die für die Kommunikation mit dem Gerät benötigt werden.

Nachdem die Gültigkeit der Anfrage verifiziert wurde, fügt das API die erhaltene Information einer internen sortierten Liste hinzu. Diese wird verwendet, um die Objektnamen in Objekt-Identifizierer aufzulösen, die für den Zugriff auf die Objekte benötigt werden.

Die API übermittelt die unbestätigte Who-Has-Anfrage, normalerweise unter Verwendung einer Broadcast-Adresse. Wenn die Parameter Device Instance Range Low Limit und Device Instance Range High Limit vorliegen, dann ist das API, dessen Device-Object_Identifier-Instanznummer in den Bereich Device Instance Range Low Limit >= Object_Identifier Instance Number <= Device Instance Range High Limit fällt, qualifiziert zu antworten. Wenn der Parameter Object Name vorliegt, dann antwortet das API, das ein Objekt mit einem Object_Name-Property-Wert hat, der dem Object Name-Parameter entspricht, mit einer I-Have-Service-Anfrage. Wenn der Parameter Object Identifier vorliegt, dann antwortet das API, das ein Objekt mit einem Object_Identifier-Property-Wert hat, der dem Object Identifier-Parameter entspricht, mit einer I-Have-Service-Anfrage.

Das API übermittelt die unbestätigte Who-Is-Anfrage, normalerweise unter Verwendung einer Broadcast-Adresse. Wenn die Parameter Device Instance Range Low Limit und Device Instance Range High Limit fehlen, liefert das API ihre Device-Object_Identifier in individuellen Antworten zurück, unter Verwendung des I-Am-Services. Wenn die Parameter Device Instance Range Low Limit und Device Instance Range High Limit vorliegen, dann liefert das API, dessen Device-Object_Identifier-Instanznummer in den Bereich Device Instance Range Low Limit >= Device Object_Identifier Instance Number <= Device Instance Range High Limit fällt, ihre Device-Object_Identifier zurück, unter Verwendung des I-Am-Services.

Das API verifiziert zunächst die Gültigkeit des Object Identifier. Falls das Objekt unbekannt ist, gibt es eine Fehlermeldung result(-) mit entsprechender Error-Klasse und -Code zurück. Dieser Service-Hook unterstützt nur Dateien, auf die über STREAM zugegriffen wird. Danach wird die Gültigkeit des lokalen Dateizugriffs auf dem lokalen Laufwerk geprüft und eine Antwort result(-) mit der entsprechenden Fehlerklasse und -Code zurückgeliefert, falls die Datei-Startposition ungültig ist, oder auf die Datei aus irgendwelchen Gründen nicht zugegriffen werden kann. Wenn die Gültigkeitsprüfung positiv ausgefallen ist, wird die angegebene Anzahl Request Record Count von Oktets aus der lokalen Datei gelesen. Wenn die tatsächliche Anzahl der gelesenen Oktets kleiner ist als die angegebene, zeigt der Returned Record Count des zurückgelieferten result(+) die Anzahl der gelesenen Oktets. Wenn das Ende der Datei erreicht wurde, wird der End Of File-Parameter des zurückgelieferten result(+) auf TRUE gesetzt.

Dieser Service-Hook wird unter Verwendung der SysFile-Schnittstelle von CODESYS implementiert und unterstützt nur STREAM-Zugriff. Somit wird die Anwenderapplikation speziell diesen Serivice-Hook für den Dateizugriff abändern wollen.

Das API verifiziert zunächst die Gültigkeit des Object Identifier. Falls das Objekt unbekannt ist, gibt es eine Fehlermeldung result(-) mit entsprechender Error-Klasse und -Code zurück. Dieser Service-Hook unterstützt nur Dateien, auf die über STREAM zugegriffen wird. Danach wird die Gültigkeit des lokalen Dateizugriffs auf dem lokalen Laufwerk geprüft und eine Antwort result(-) mit der entsprechenden Fehlerklasse und -Code zurückgeliefert, falls die Startposition in der Datei ungültig ist, oder auf die Datei aus irgendwelchen Gründen nicht zugegriffen werden kann. Wenn der File Start Position-Parameter der Service-Anfrage die lokale Dateigröße überschreitet, wird die Datei für das Schreiben der eingehenden Oktets erweitert. Wenn der File Start Position-Parameter den Wert -1 hat, werden die eingehenden Oktets am Ende der Datei angehängt. Wenn das Schreiben der lokalen Datei fehlgeschlagen ist, wird eine entsprechende result(-)-Antwort ausgegeben. Wenn das Schreiben der lokalen Datei erfolgreich war wird result(+) erzeugt, das die entsprechende File Start Position enthält.

Dieser Service-Hook wird unter Verwendung der SysFile-Schnittstelle von CODESYS implementiert und unterstützt nur STREAM-Zugriff. Somit wird die Anwenderapplikation speziell diesen Serivice-Hook für den Dateizugriff abändern wollen.

Das API verifiziert zunächst die Gültigkeit der Anfrage, indem es prüft, ob der Object Specifier der Anfrage einen erzeugbaren Objekttyp angibt (entsprechend der internen Regel BACnet.IsBACnetObjectAMEVCreatable). Es gibt eine entsprechende Fehlermeldung result(-) zurück, wenn dieses nicht der Fall ist. Wenn es vom Object Specifier so angegeben ist, wird die Gültigkeit der Objektinstanznummer geprüft und eine entsprechende Fehlermeldung result(-) zurückgegeben, falls die Instanznummer nicht mehr existiert. Wenn keine List of Initial Values gegeben ist, werden alle Properties des erzeugten Objekts angelegt, unter Verwendung der Standardwerte, wie es üblich ist für Properties, die nicht in einer gegebenen List of Initial Values stehen. Wenn das Erzeugen eines Objekts fehlschlägt, wird eine entsprechende Fehlermeldung result(-) ausgegeben, während First Failed Element Number der Antwort auf 0 gesetzt wird. Wenn das Erzeugen erfolgreich war, wird eine result(+)-Antwort ausgegeben, die den Objekt-Identifizierer der erzeugten Objekts enthält.

Diese aktuelle Implementierung dieses Service-Hooks ist eher als umfassender Vorschlag für seine Implementierung zu betrachten. Da es eine reine Angelegenheit der Anwenderapplikation ist, wie die Service-Anfrage behandelt wird, ist es sehr wahrscheinlich, dass die Anwenderapplikation einen eigenen Service-Hook für eine andere Behandlung der Anfrage bereitstellen möchte.

Das API verifiziert zunächst die Gültigkeit des Object Identifier und liefert eine Fehlermeldung result(-) mit entsprechender Error-Klasse und -Code zurück, falls das Objekt unbekannt ist. Wenn das angegebene Objekt gelöscht werden kann, wird eine result(+)-Antwort erzeugt. Wenn das Löschen fehlschlägt, z.B. weil das Objekt nicht dynamisch gelöscht werden kann (entsprechend der internen Regel BACnet.IsBACnetObjectAMEVCreatable), oder aus anderen Gründen, wird ein result(-) erzeugt.

Diese aktuelle Implementierung dieses Service-Hooks ist eher als umfassender Vorschlag für seine Implementierung zu betrachten. Da es eine reine Angelegenheit der Anwenderapplikation ist, wie die Service-Anfrage behandelt wird, ist es sehr wahrscheinlich, dass die Anwenderapplikation einen eigenen Service-Hook für eine andere Behandlung der Anfrage bereitstellen möchte. Für weitere Informationen siehe: Implementierungsanforderungen bei Verwendung des derzeitigen BACnet API/Stacks