Crochets d'indication de service avec implémentation d'action par défaut

Après avoir vérifié la validité de la requête, l'API tente de localiser l'objet spécifié. Si l'objet existe et si le Time Stamp paramètre correspond à l'heure la plus récente de l'événement en cours d'acquittement, alors ce qui suit se produira : le bit dans le Acked_Transitions propriété de l'objet qui correspond à la valeur du Event State Acknowledged le paramètre est réglé sur 1, un result(+) primitive est émise et une notification d'événement avec un Notify Type paramètre égal à ACK_NOTIFICATION est délivré. Si un objet n'est pas trouvé, un result(-) la primitive est émise. Une notification d'accusé de réception utilise le même type de service (avec ou sans accusé de réception) dirigé vers les mêmes destinataires auxquels la notification d'événement originale avec ou sans accusé de réception a été envoyée. Le Time Stamp transmis dans la notification d'accusé de réception est dérivé du moment où la notification d'accusé de réception est générée, et non du Time Stamp de la notification d'événement originale.

Après avoir vérifié la validité de la requête, l'API recherche tous les objets déclencheurs d'événements qui ont un État_événement propriété non égale à NORMAL et un Notify_Type propriété d'une valeur de ALARM. Une réponse positive est construite qui contient le Alarm Summaries pour les objets trouvés dans cette recherche. Si aucun objet répondant à ces critères n’est trouvé, alors une liste de longueur 0 est renvoyée.

Après avoir vérifié la validité de la requête, l'API recherche tous les objets déclencheurs d'événements qui remplissent les critères de recherche spécifiés dans la primitive de requête. Les critères de recherche sont les liens logiques de tous les filtres explicitement définis qui ont été omis dans la primitive de demande. Une réponse positive contenant le Enrollment Summaries pour les objets trouvés dans cette recherche est construit. Si aucun objet répondant à ces critères n’est trouvé, alors une liste de longueur 0 est renvoyée.

Si ni l'un ni l'autre Lifetime ni Issue Confirmed Notifications existent, alors la demande est considérée comme une annulation. Tout contexte COV, qui existe déjà pour la même adresse BACnet et est contenu dans la PDU qui a le SubscribeCOV demande et a le même Subscriber Process Identifier et Monitored Object Identifier, sont handicapés et un SimpleAck est retourné. Les annulations créées, pour lesquelles le contexte COV correspondant ne peut pas être trouvé, sont exécutées avec succès comme si un contexte existait et renvoient un SimpleAck. Si la Lifetime Le paramètre n'existe pas, mais le Issue Confirmed Notifications existe-t-il un paramètre, alors une valeur de zéro (durée de vie indéfinie) est appliquée pour lifetime. Si la Issue Confirmed Notifications Le paramètre existe, mais l'objet à surveiller ne prend pas en charge le reporting COV, une erreur est alors émise. Si l'objet à surveiller prend en charge le reporting COV, une vérification est effectuée pour localiser un contexte COV existant pour la même adresse BACnet contenue dans la PDU contenant le SubscribeCOV demande et a le même Subscriber Process Identifier et Monitored Object Identifier. Si un contexte COV existant est trouvé, la demande est traitée comme si l'abonnement était à nouveau créé. Si un COV aucun contexte correspondant à la demande ne peut être trouvé, alors un nouveau contexte COV est créé qui contient l'adresse BACnet de la PDU qui transporte le SubscribeCOV demande et pareil Subscriber Process Identifier et Monitored Object Identifier. Si un contexte ne peut pas être créé, une erreur est renvoyée. Si un nouveau contexte est créé ou qu'un nouvel abonnement est reçu, alors le contexte COV est initialisé et doté d'une durée de vie en fonction de la Lifetime paramètre s’il existe, ou 0 si le paramètre Lifetime n’existe pas. L'abonnement est automatiquement annulé après plusieurs secondes sans recevoir de réabonnement. Une durée de vie de 0 indique que l'abonnement est indéfini et qu'une annulation automatique n'aura pas lieu. Dans les deux cas, un SimpleAck est retourné. UN ConfirmedCOVNotification ou UnconfirmedCOVNotification est créé dans les plus brefs délais après la réussite d'une demande de souscription ou de réabonnement, comme spécifié dans le Issue Confirmed Notifications paramètre.

Après avoir vérifié la validité de la requête, l'API tente de modifier l'objet qui est identifié dans le Object Identifier paramètre. Si l'objet identifié existe et possède la propriété spécifiée dans le Property Identifier paramètre, alors une tentative est faite pour ajouter tous les éléments spécifiés dans le List of Elements paramètre à la propriété spécifiée. Si cette tentative réussit, alors un SimpleAck la primitive est émise. Si un ou plusieurs éléments existent déjà dans la liste, ils sont ignorés et ne sont pas ajoutés à la liste. Ignorer un élément qui existe déjà n'entraîne pas l'échec du service. Si l'objet spécifié n'existe pas, ou si la propriété spécifiée n'existe pas, ou si la propriété spécifiée n'est pas une liste, alors le service échoue et une primitive de réponse d'erreur est émise. Si un ou plusieurs éléments ne peuvent pas être ajoutés à la liste et qu'ils ne sont pas déjà dans la liste, alors une primitive de réponse d'erreur est émise et aucun élément n'est ajouté à la liste. L'effet de ce service est d'ajouter à la liste tous les éléments spécifiés qui n'existent pas déjà ou de n'ajouter aucun élément à la liste.

Après avoir vérifié la validité de la requête, l'API tente de modifier l'objet qui est identifié dans le Object Identifier paramètre. Si l'objet identifié existe et possède la propriété spécifiée dans le Property Identifier paramètre, alors une tentative est faite pour supprimer tous les éléments spécifiés dans le List of Elements paramètre de la propriété spécifiée. Si un ou plusieurs éléments n'existent pas ou ne peuvent pas être supprimés en raison d'autorisations insuffisantes ou d'autres problèmes, aucun des éléments n'est supprimé et une primitive de réponse d'erreur est émise.

Après avoir vérifié la validité de la requête, l'API tente d'accéder à la propriété spécifiée de l'objet spécifié. Si l'accès réussit, alors un ComplexAck une primitive est générée qui renvoie la valeur accédée. Si l'accès échoue, une primitive d'erreur est générée, qui fournit la raison de l'échec. Quand le object-type dans le Object Identifier le paramètre contient la valeur Device Object et l'exemple dans le Object Identifier le paramètre contient la valeur 4194303, alors l'API gère le Object Identifier comme s'il correspondait correctement à l'objet périphérique local. Cela permet à l'instance d'un appareil qui ne génère pas I-Am messages à déterminer.

Après avoir vérifié la validité de la requête, l'API tente d'accéder à la propriété spécifiée de l'objet spécifié. Il construit un List of Read Access Results dans l'ordre indiqué dans la demande. Si la List of Property References partie de la List of Read Access Specifications le paramètre contient les identifiants de propriété ALL, REQUIRED, ou OPTIONAL, puis le List of Read Access Results est construit comme si chaque propriété renvoyée était explicitement référencée. Il n'est pas nécessaire que la demande soit effectuée "automatiquement". Néanmoins, l'API s'assure que toutes les opérations de lecture sont terminées dans les plus brefs délais, sous réserve uniquement des processus de priorité plus élevée. La demande est traitée jusqu'à ce qu'une tentative soit faite pour accéder à toutes les propriétés spécifiées. Si aucun des objets spécifiés n'est trouvé ou si aucune des propriétés spécifiées des objets spécifiés n'est accessible, une primitive d'erreur ou une ComplexAck primitive qui renvoie des codes d'erreur pour toutes les propriétés est émise. Si l'une des propriétés spécifiées des objets spécifiés est accessible, alors un ComplexAck primitive est émise, qui renvoie toutes les valeurs accédées et les codes d'erreur pour toutes les propriétés qui n'ont pas pu être accédées. Quand le object-type dans le Object Identifier partie de la Read Access Specification paramètre contient la valeur Device Object et l'instance dans le Object Identifier paramètre contient la valeur 4194303, l'API gère le Object Identifier comme s'il correspondait correctement à l'objet périphérique local. Cela permet à l'instance d'un appareil qui ne génère pas I-Am message à déterminer.

Pour les applications utilisateur du serveur BACnet, qui ne peuvent pas utiliser la base de données interne et doivent donc implémenter le support du ReadPropertyMultiple service, ils n'ont qu'à mettre en œuvre le ReadProperty crochet de service parce que ReadPropertyMultiple les demandes sont divisées en une seule ReadProperty les requêtes en interne et les achèvements sont collectés pour créer la réponse.

Après avoir vérifié la validité de la requête, l'API essaie de modifier la propriété spécifiée de l'objet spécifié en utilisant la valeur fournie dans le Property Value paramètre. Si cette tentative de modification réussit, un SimpleAck primitive est émise. Si la tentative de modification échoue, une primitive d'erreur est générée, qui fournit la raison de l'échec.

Pour chaque Write Access Specification contenue dans le List of Write Access Specifications, la valeur de chaque propriété spécifiée est remplacée par la valeur de propriété fournie dans le Write Access Specification, et un SimpleAck primitive est émise, indiquant que la demande de service a été exécutée dans son intégralité. Les propriétés fournies sont traitées dans l'ordre spécifié dans le List of Write Access Specifications. Si, au cours du traitement, une propriété est rencontrée qui ne peut pas être modifiée, le PI émet une primitive de réponse d'erreur indiquant la raison de l'échec. Le résultat de ce service est soit que toutes les propriétés spécifiées ou seulement les propriétés jusqu'à la propriété spécifiée dans le First Failed Write Attempt paramètre ont été modifiés avec succès. UNE BACnet-Reject-PDU n'est émis que si aucune opération d'écriture n'a été exécutée avec succès. Il indique que la demande de service a été rejetée dans son intégralité. Si l'une des opérations d'écriture contenues dans le List of Write Access Specifications n'a pas pu être exécuté avec succès, une réponse d'erreur indiquant la raison de l'échec est émise comme décrit ci-dessus.

Tout d'abord, l'API vérifie la validité du Object Identifier, Property Identifier, et Property Array Index paramètres et renvoie une réponse d'erreur avec la classe d'erreur et le code d'erreur appropriés si l'objet ou la propriété est inconnu, si les données référencées ne sont pas une liste ou un tableau, ou si elles ne sont actuellement pas accessibles pour une autre raison. Si la Range paramètre n'existe pas, l'API lit tous les éléments disponibles dans la liste ou le tableau et essaie de les renvoyer. Si la Range paramètre existe et spécifie le By Position paramètres, l'API lit tous les éléments spécifiés et essaie de les renvoyer. Les éléments spécifiés incluent l'élément à la position d'index définie par Reference Index plus ceux jusqu'à Count - 1 articles suivant si Count est positif, ou jusqu'à -1 - Count éléments précédant si Count est négatif. Le premier élément d'une liste est associé à l'indice 1. Si le Range paramètre existe et spécifie le By Time paramètre ou le By Sequence Number paramètres, l'API rejette la demande en renvoyant une réponse d'erreur avec la classe d'erreur et le code d'erreur appropriés. La réponse renvoyée transmet le nombre d'éléments lus et renvoyés au moyen de la Item Count paramètre. Les éléments courants sont renvoyés dans le Item Data paramètre. Si la réponse renvoyée inclut le premier index de position, alors le FIRST_ITEM le drapeau est défini sur TRUE dans le Result Flags paramètre; sinon, il est réglé sur FALSE. Si la réponse renvoyée inclut le dernier index de position, alors le LAST_ITEM le drapeau est défini sur TRUE dans Result Flags; sinon, il est réglé sur FALSE. Si aucun élément de la liste ne correspond au Range critères de paramètre, puis un ComplexAck est renvoyé avec un Item Count de 0 et non First Sequence Number paramètre.

L'implémentation par défaut de ce service ne prend PAS en charge l'accès au log-buffer propriété des objets de journalisation des tendances et des événements. Si une application utilisateur doit prendre en charge des objets de journalisation, le stockage et l'accès à ces données doivent être mis en œuvre par l'application utilisateur.

Si ni l'un ni l'autre Lifetime ni Issue Confirmed Notifications existent, alors la demande est considérée comme une annulation. Tout contexte COV qui existe déjà pour la même adresse BACnet et est contenu dans le PDU qui a le SubscribeCOVProperty demande et a le même Subscriber Process Identifier, Monitored Object Identifier et Monitored Property Identifier, est désactivé et un SimpleAck est retourné. Les annulations, qui sont émises pour lesquelles aucun contexte COV correspondant ne peut être trouvé, sont traitées avec succès comme si un contexte avait existé. Ils reviennent SimpleAck. Si un contexte COV est trouvé, il est supprimé du Active_COV_Subscriptions objet périphérique. Si la Issue Confirmed Notifications paramètre existe, mais la propriété à surveiller ne prend pas en charge les rapports COV, une erreur est émise. Si la propriété à surveiller prend en charge les rapports COV, une vérification est effectuée pour localiser un contexte COV existant pour la même adresse BACnet qui est contenue dans le PDU qui contient le SubscribeCOVProperty demande et a le même Subscriber Process Identifier, Monitored Object Identifier, et Monitored Property Identifier. Si un contexte COV existant est trouvé, la demande est interprétée comme une réinscription et traitée avec succès comme si une réinscription avait été créée. Si un contexte COV correspondant à la demande est introuvable, un nouveau contexte COV est créé. Il contient l'adresse BACnet du PDU qui envoie le SubscribeCOVProperty demande et a le même Subscriber Process Identifier, Monitored Object Identifier, et Monitored Property Identifier. Le nouveau contexte est inclus dans le Active_COV_Subscriptions propriété de l'objet périphérique. Si un contexte ne peut pas être créé, une erreur est renvoyée. Si un nouveau contexte est créé ou qu'un nouvel abonnement est reçu, le contexte COV est initialisé et défini avec une durée de vie telle que spécifiée dans le Lifetime paramètre. L'abonnement est automatiquement annulé si un nouvel abonnement n'a pas été reçu après plusieurs secondes. UNE SimpleAck est retourné et un ConfirmedCOVNotification ou UnconfirmedCOVNotification est créé dès que possible après la réussite d'une demande d'abonnement ou de réabonnement, comme spécifié dans le Issue Confirmed Notifications paramètre.

Après avoir vérifié la validité de la requête, l'API recherche tous les objets déclencheurs d'événements qui remplissent les conditions suivantes, en commençant par l'objet (dans l'ordre interne croissant des instances d'objet) après l'objet spécifié par le Last Received Object Identifier paramètre, si présent ont un Event_State propriété dont la valeur n'est pas égale à NORMAL, ou avoir un Acked_Transitions propriété qui a au moins un des bits suivants (TO-OFFNORMAL, TO-FAULT, TO-NORMAL) mis à FALSE. Une réponse positive est construite, qui contient les résumés d'événements pour les objets trouvés dans cette recherche. Si aucun objet répondant à ces critères n'est trouvé, une liste de longueur 0 est renvoyée. Autant de retours qu'il est possible de retourner dans le délai APDU. S'il existe plusieurs objets qui remplissent les critères mais ne peuvent pas être renvoyés dans le APDU, puis le More Events paramètre est réglé sur TRUE; sinon, il est réglé sur FALSE.

Après avoir vérifié la validité de la requête, l'API ajoute les informations reçues au Address_Binding propriété de l'objet périphérique. Ceci est utilisé pour résoudre les numéros d'instance de périphérique en adresses MAC BACnet qui sont nécessaires pour la communication avec ce périphérique.

Après avoir vérifié la validité de la requête, l'API ajoute les informations reçues à une liste triée interne. Cette liste est utilisée pour résoudre les noms d'objets en identifiants d'objets nécessaires pour accéder à ces objets.

L'API transmettra le non reconnu Who-Has demande, normalement en utilisant une adresse de diffusion. Si la Device Instance Range Low Limit et Device Instance Range High Limit paramètres existent, puis l'API, dont le dispositif Object_Identifier le numéro d'instance est compris dans la plage Device Instance Range Low Limit >= Object_Identifier Instance Number <= Device Instance Range High Limit, est qualifié pour répondre. Si la Object Name paramètre existe, alors l'API, qui contient un objet avec un Object_Name valeur de la propriété qui correspond à la Object Name paramètre, répond par un I-Have demande de service. Si la Object Identifier paramètre existe, alors l'API, qui contient un objet avec un Object_Identifier valeur de la propriété qui correspond à la Object Identifier paramètre, répond par un I-Have demande de service.

L'API transmet les informations non acquittées Who-Is demande, normalement en utilisant une adresse de diffusion. Si la Device Instance Range Low Limit et Device Instance Range High Limit les paramètres sont manquants, alors l'API renvoie leur appareil Object_Identifiers dans les réponses individuelles au moyen de I-Am un service. Si la Device Instance Range Low Limit et Device Instance Range High Limit paramètres existent, puis l'API, dont le périphérique Object_Identifier le numéro d'instance est compris dans la plage Device Instance Range Low Limit >= Device Object_Identifier Instance Number <= Device Instance Range High Limit, retourneront leur appareil Object_Identifier au moyen de la I-Am un service.

Tout d'abord, l'API vérifie la validité du Object Identifier. Il renvoie un result(-) error avec la classe d'erreur et le code d'erreur correspondants si l'objet est inconnu. Ce hook de service ne prend en charge que les fichiers accessibles via STREAM. Après cela, la validité de l'accès au fichier local sur le disque dur local est vérifiée et un result(-) La réponse avec la classe d'erreur et le code d'erreur appropriés est renvoyée si la position de début du fichier n'est pas valide ou si le fichier n'est pas accessible pour une raison quelconque. Si le contrôle de validité réussit, le nombre spécifié Request Record Count d'octets est lu à partir du fichier local. Si le nombre réel d'octets lus est inférieur à celui spécifié, alors le Returned Record Count des retournés result(+) indique le nombre d'octets lus. Si la fin du fichier est atteinte, le End Of File paramètre du retour result(+) est réglé sur TRUE.

Ce crochet de service est implémenté à l'aide de l'interface SysFile de CODESYS et prend en charge STREAM accès uniquement. Par conséquent, l'application utilisateur peut souhaiter modifier notamment ce crochet de service pour l'accès au fichier.

Tout d'abord, l'API vérifie la validité du Object Identifier. Il renvoie un result(-) error avec la classe d'erreur et le code d'erreur correspondants si l'objet est inconnu. Ce hook de service ne prend en charge que les fichiers accessibles via STREAM. Après cela, la validité de l'accès au fichier local sur le disque dur local est vérifiée et un result(-) La réponse avec la classe d'erreur et le code d'erreur appropriés est renvoyée si la position de début du fichier n'est pas valide ou si le fichier n'est pas accessible pour une raison quelconque. Si la File Start Position paramètre de la demande de service dépasse la taille du fichier local, alors le fichier est étendu pour écrire les octets entrants. Si la File Start Position paramètre a la valeur -1, le fichier local est alors ajouté avec les octets entrants. Si l'écriture dans le fichier local échoue, un message correspondant result(-) réponse est émise. Si l'écriture dans le fichier local réussit, alors result(+) est émis, qui contient le correspondant File Start Position.

Ce crochet de service est implémenté à l'aide de l'interface SysFile de CODESYS et prend en charge STREAM accès uniquement. Par conséquent, l'application utilisateur peut souhaiter modifier notamment ce crochet de service pour l'accès au fichier.

Tout d'abord, l'API vérifiera la validité de la requête en vérifiant si oui ou non le Object Specifier de la requête spécifie un type d'objet pouvant être créé (selon la règle interne BACnet.IsBACnetObjectAMEVCreatable). Il renvoie une erreur correspondante result(-) si ce n'est pas le cas. Si spécifié par le Object Specifier, la validité du numéro d'instance d'objet est vérifiée et une erreur correspondante result(-) est renvoyé si le numéro d'instance n'existe plus. Si un List of Initial Values n'est pas spécifié, alors les propriétés de l'objet créé sont créées en utilisant des valeurs par défaut comme il est habituel pour les propriétés qui ne sont pas spécifiées dans un objet donné List of Initial Values. Si la création de l'objet échoue, une erreur correspondante result(-) est émis, tandis que le First Failed Element Number de la réponse est défini sur 0. Si la création a réussi, un result(+) réponse est émise, qui contient l'identifiant d'objet de l'objet créé.

Cette implémentation actuelle de ce crochet de service doit être considérée comme une suggestion plus complète pour son implémentation. Étant donné que le traitement de cette demande de service est une question purement locale de l'application utilisateur, il est très probable que l'application utilisateur fournira son propre crochet de service pour un autre traitement de la demande.

Tout d'abord, l'API vérifie la validité du Object Identifier et renvoie un result(-) réponse d'erreur avec la classe d'erreur et le code d'erreur correspondants si l'objet est inconnu. Si l'objet spécifié peut être supprimé, un result(+) réponse est émise. Si la suppression des objets échoue (exemple : l'objet ne peut pas être supprimé dynamiquement selon la règle interne BACnet.IsBACnetObjectAMEVCreatable), ou pour toute autre raison, alors un result(-) est émis.

Cette implémentation actuelle de ce service hook doit être considérée comme une suggestion plus complète pour sa mise en œuvre. Étant donné que la façon dont cette demande de service est traitée relève d'une question purement locale de l'application utilisateur, il est très probable que l'application utilisateur fournisse son propre hook de service pour un autre traitement de la demande. Pour plus d'informations, voir : Exigences de mise en œuvre lors de l'utilisation du courant BACnet API/Pile