Hook di indicazione del servizio con implementazione dell'azione predefinita

Dopo aver verificato la validità della richiesta, l'API tenta di individuare l'oggetto specificato. Se l'oggetto esiste e se il Time Stamp corrisponde all'ora più recente in cui l'evento è stato riconosciuto, quindi si verificherà quanto segue: il bit in Acked_Transitions proprietà dell'oggetto che corrisponde al valore di Event State Acknowledged il parametro è impostato su 1, un result(+) viene emessa la primitiva e una notifica di evento con a Notify Type parametro uguale a ACK_NOTIFICATION viene emesso. Se un oggetto non viene trovato, a result(-) viene rilasciato il primitivo. Una notifica di conferma utilizza lo stesso tipo di servizio (riconosciuto o non riconosciuto) diretto agli stessi destinatari a cui è stata inviata la notifica dell'evento originale riconosciuto o non riconosciuto. Il Time Stamp veicolata nella notifica di conferma è derivata dal momento in cui viene generata la notifica di conferma, non dal Time Stamp della notifica dell'evento originale.

Dopo aver verificato la validità della richiesta, l'API ricerca tutti gli oggetti di attivazione di eventi che hanno a Stato_evento proprietà non uguale a NORMAL e un Notify_Type immobile con un valore di ALARM. Viene costruita una risposta positiva che contiene il Alarm Summaries per gli oggetti trovati in questa ricerca. Se non vengono trovati oggetti che soddisfano questi criteri, viene restituito un elenco di lunghezza 0.

Dopo aver verificato la validità della richiesta, l'API ricerca tutti gli oggetti che attivano gli eventi che soddisfano i criteri di ricerca specificati nella primitiva della richiesta. I criteri di ricerca sono i collegamenti logici di tutti i filtri impostati in modo esplicito che sono stati omessi nella primitiva di richiesta. Una risposta positiva contenente il Enrollment Summaries per gli oggetti trovati in questa ricerca è costruito. Se non vengono trovati oggetti che soddisfano questi criteri, viene restituito un elenco di lunghezza 0.

Se nessuno dei due Lifetime né Issue Confirmed Notifications esiste, allora la richiesta è considerata un annullamento. Qualsiasi contesto COV, che esiste già per lo stesso indirizzo BACnet ed è contenuto nella PDU che ha il SubscribeCOV richiesta e ha lo stesso Subscriber Process Identifier e Monitored Object Identifier, sono disabili e a SimpleAck viene restituito. Gli annullamenti creati, per i quali non è possibile trovare il contesto COV corrispondente, vengono eseguiti correttamente come se esistesse un contesto e restituisce a SimpleAck. Se la Lifetime parametro non esiste, ma il Issue Confirmed Notifications non esiste parametro, quindi viene applicato un valore pari a zero (durata indefinita). lifetime. Se la Issue Confirmed Notifications esiste, ma l'oggetto da monitorare non supporta la segnalazione COV, quindi viene emesso un errore. Se l'oggetto da monitorare supporta il reporting COV, viene eseguita una verifica per individuare un contesto COV esistente per lo stesso indirizzo BACnet contenuto nella PDU che contiene il SubscribeCOV richiesta e ha lo stesso Subscriber Process Identifier e Monitored Object Identifier. Se viene trovato un contesto COV esistente, la richiesta viene gestita come se l'abbonamento venisse creato di nuovo. Se un COV non è possibile trovare il contesto corrispondente alla richiesta, quindi viene creato un nuovo contesto COV che contiene l'indirizzo BACnet dalla PDU che trasporta il SubscribeCOV richiesta e lo stesso Subscriber Process Identifier e Monitored Object Identifier. Se non è possibile creare un contesto, viene restituito un errore. Se viene creato un nuovo contesto o viene ricevuta una nuova sottoscrizione, il contesto COV viene inizializzato e gli viene assegnata una durata in base al Lifetime parametro se esiste o 0 se il parametro Lifetime non esiste. L'abbonamento viene automaticamente annullato dopo che sono trascorsi molti secondi senza ricevere una nuova sottoscrizione. Una durata di 0 indica che l'abbonamento è a tempo indeterminato e non si verificherà un annullamento automatico. In entrambi i casi, a SimpleAck viene restituito. UN ConfirmedCOVNotification o UnconfirmedCOVNotification viene creato il prima possibile dopo il completamento con successo di una richiesta di abbonamento o riabbonamento, come specificato nel Issue Confirmed Notifications parametro.

Dopo aver verificato la validità della richiesta, l'API tenta di modificare l'oggetto identificato nel file Object Identifier parametro. Se l'oggetto identificato esiste e ha la proprietà specificata in Property Identifier parametro, quindi viene effettuato un tentativo di aggiungere tutti gli elementi specificati in List of Elements parametro alla proprietà specificata. Se questo tentativo ha esito positivo, a SimpleAck viene rilasciato il primitivo. Se uno o più elementi esistono già nell'elenco, viene ignorato e non viene aggiunto all'elenco. Ignorare un elemento già esistente non causa il fallimento del servizio. Se l'oggetto specificato non esiste, la proprietà specificata non esiste o la proprietà specificata non è un elenco, il servizio ha esito negativo e viene emessa una primitiva di risposta di errore. Se uno o più elementi non possono essere aggiunti all'elenco e non sono già nell'elenco, viene emessa una primitiva di risposta di errore e nessun elemento viene aggiunto all'elenco. L'effetto di questo servizio è di aggiungere all'elenco tutti gli elementi specificati che non esistono già o di non aggiungere alcun elemento all'elenco.

Dopo aver verificato la validità della richiesta, l'API tenta di modificare l'oggetto identificato nel file Object Identifier parametro. Se l'oggetto identificato esiste e ha la proprietà specificata in Property Identifier parametro, quindi viene effettuato un tentativo di rimuovere tutti gli elementi specificati in List of Elements parametro dalla proprietà specificata. Se uno o più elementi non esistono o non possono essere rimossi a causa di autorizzazioni insufficienti o altri problemi, nessuno degli elementi viene rimosso e viene emessa una primitiva di risposta di errore.

Dopo aver verificato la validità della richiesta, l'API tenta di accedere alla proprietà specificata dell'oggetto specificato. Se l'accesso ha esito positivo, a ComplexAck viene generata la primitiva che restituisce il valore a cui si accede. Se l'accesso non riesce, viene generata una primitiva di errore, che fornisce il motivo dell'errore. Quando il object-type nel Object Identifier parametro contiene il valore Device Object e l'istanza nel Object Identifier parametro contiene il valore 4194303, quindi l'API gestisce il Object Identifier come se corrispondesse correttamente all'oggetto dispositivo locale. Ciò consente l'istanza del dispositivo di un dispositivo che non genera I-Am messaggi da definire

Dopo aver verificato la validità della richiesta, l'API tenta di accedere alla proprietà specificata dell'oggetto specificato. Costruisce un List of Read Access Results nell'ordine specificato nella richiesta. Se la List of Property References parte di List of Read Access Specifications parametro contiene gli identificatori di proprietà ALL, REQUIRED, o OPTIONAL, poi il List of Read Access Results è costruito come se ogni proprietà restituita fosse esplicitamente referenziata. Non è necessario che la richiesta venga eseguita "automaticamente". Tuttavia, l'API fa in modo che tutte le operazioni di lettura vengano completate nel più breve tempo possibile, soggette solo a processi con priorità più elevata. La richiesta viene elaborata fino a quando non viene effettuato un tentativo di accedere a tutte le proprietà specificate. Se nessuno degli oggetti specificati viene trovato o se non è possibile accedere a nessuna delle proprietà specificate degli oggetti specificati, allora una primitiva di errore o un ComplexAck viene emessa una primitiva che restituisce codici di errore per tutte le proprietà. Se è possibile accedere a una qualsiasi delle proprietà specificate degli oggetti specificati, a ComplexAck viene emessa la primitiva, che restituisce tutti i valori a cui si accede e i codici di errore per tutte le proprietà a cui non è stato possibile accedere. Quando il object-type nel Object Identifier parte di Read Access Specification parametro contiene il valore Device Object e l'istanza nel Object Identifier parametro contiene il valore 4194303, quindi l'API gestisce il Object Identifier come se corrispondesse correttamente all'oggetto dispositivo locale. Ciò consente l'istanza del dispositivo di un dispositivo che non genera I-Am messaggi da definire

Per le applicazioni utente del server BACnet, che non possono utilizzare il database interno e quindi devono implementare il supporto per il ReadPropertyMultiple servizio, devono solo implementare il ReadProperty gancio di servizio perché ReadPropertyMultiple le richieste sono suddivise in singole ReadProperty le richieste internamente e i completamenti vengono raccolti per creare la risposta.

Dopo aver verificato la validità della richiesta, l'API tenta di modificare la proprietà specificata dell'oggetto specificato utilizzando il valore fornito nella Property Value parametro. Se questo tentativo di modifica ha esito positivo, a SimpleAck viene rilasciato il primitivo. Se il tentativo di modifica fallisce, viene generata una primitiva di errore, che fornisce il motivo dell'errore.

Per ciascuno Write Access Specification contenuto nel List of Write Access Specifications, il valore di ciascuna proprietà specificata viene sostituito dal valore della proprietà fornito in Write Access Specification, e un SimpleAck viene emessa la primitiva, che indica che la richiesta di servizio è stata eseguita nella sua interezza. Le proprietà fornite vengono elaborate nell'ordine specificato nel List of Write Access Specifications. Se durante l'elaborazione viene rilevata una proprietà che non può essere modificata, il PI emette una primitiva di risposta di errore indicando il motivo dell'errore. Il risultato di questo servizio è che tutte le proprietà specificate o solo le proprietà fino a, ma esclusa, la proprietà specificata nel First Failed Write Attempt parametro sono stati modificati con successo. UN BACnet-Reject-PDU viene emesso solo se nessuna operazione di scrittura è stata eseguita correttamente. Indica che la richiesta di servizio è stata respinta nella sua interezza. Se una delle operazioni di scrittura contenute in List of Write Access Specifications non è stato possibile eseguire correttamente, viene emessa una risposta di errore che indica il motivo dell'errore come descritto sopra.

In primo luogo, l'API verifica la validità del Object Identifier, Property Identifier, e Property Array Index parametri e restituisce una risposta di errore con la classe di errore e il codice di errore appropriati se l'oggetto o la proprietà è sconosciuto, se i dati di riferimento non sono un elenco o una matrice o se attualmente non è possibile accedervi per un altro motivo. Se la Range parametro non esiste, quindi l'API legge tutti gli elementi disponibili nell'elenco o nell'array e tenta di restituirli. Se la Range esiste e specifica il By Position parametri, quindi l'API legge tutti gli elementi specificati e tenta di restituirli. Gli elementi specificati includono l'elemento nella posizione dell'indice definita da Reference Index più quelli fino a Count - 1 articoli seguenti se Count è positivo, o fino a -1 - Count elementi che precedono se Count è negativo. Il primo elemento di una lista è associato all'indice 1. Se il Range esiste e specifica il By Time parametro o il By Sequence Number parametri, quindi l'API rifiuta la richiesta restituendo una risposta di errore con la classe di errore e il codice di errore appropriati. La risposta restituita trasmette il numero di articoli letti e restituiti tramite il Item Count parametro. Gli articoli correnti vengono restituiti nel Item Data parametro. Se la risposta restituita include il primo indice di posizione, allora il FIRST_ITEM flag è impostato su TRUE nel Result Flags parametro; in caso contrario, è impostato su FALSE. Se la risposta restituita include l'ultimo indice di posizione, allora il LAST_ITEM flag è impostato su TRUE in Result Flags; in caso contrario, è impostato su FALSE. Se nessun elemento nell'elenco corrisponde a Range criteri dei parametri, quindi a ComplexAck viene restituito con un Item Count di 0 e n First Sequence Number parametro.

L'implementazione predefinita di questo servizio NON supporta l'accesso a log-buffer proprietà degli oggetti di registrazione trend ed eventi. Se un'applicazione utente deve supportare la registrazione di oggetti, l'archiviazione e l'accesso a tali dati devono essere implementati dall'applicazione utente.

Se nessuno dei due Lifetime né Issue Confirmed Notifications esiste, allora la richiesta è considerata come un annullamento. Qualsiasi contesto COV che esiste già per lo stesso indirizzo BACnet ed è contenuto nella PDU che ha il SubscribeCOVProperty richiesta e ha lo stesso Subscriber Process Identifier, Monitored Object Identifier e Monitored Property Identifier, è disabilitato e a SimpleAck viene restituito. Le cancellazioni, che vengono emesse per le quali non è possibile trovare un contesto COV corrispondente, vengono gestite correttamente come se esistesse un contesto. Ritornano SimpleAck. Se viene trovato un contesto COV, viene rimosso dal Active_COV_Subscriptions oggetto dispositivo. Se la Issue Confirmed Notifications il parametro esiste, ma la proprietà da monitorare non supporta la segnalazione COV, quindi viene emesso un errore. Se la proprietà da monitorare supporta la segnalazione COV, viene eseguito un controllo per individuare un contesto COV esistente per lo stesso indirizzo BACnet che è contenuto nella PDU che contiene il SubscribeCOVProperty richiesta e ha lo stesso Subscriber Process Identifier, Monitored Object Identifier, e Monitored Property Identifier. Se viene trovato un contesto COV esistente, la richiesta viene interpretata come una nuova sottoscrizione e gestita correttamente come se fosse stata creata una nuova sottoscrizione. Se non è possibile trovare un contesto COV che corrisponde alla richiesta, viene creato un nuovo contesto COV. Contiene l'indirizzo BACnet della PDU che invia il SubscribeCOVProperty richiesta e ha lo stesso Subscriber Process Identifier, Monitored Object Identifier, e Monitored Property Identifier. Il nuovo contesto è inserito nel Active_COV_Subscriptions proprietà dell'oggetto dispositivo. Se non è possibile creare un contesto, viene restituito un errore. Se viene creato un nuovo contesto o viene ricevuta una nuova sottoscrizione, il contesto COV viene inizializzato e definito con una durata come specificato nella Lifetime parametro. L'abbonamento viene automaticamente annullato se dopo molti secondi non viene ricevuta una nuova sottoscrizione. UN SimpleAck viene restituito e a ConfirmedCOVNotification o UnconfirmedCOVNotification viene creato il prima possibile dopo il completamento con successo di una richiesta di abbonamento o riabbonamento, come specificato nel Issue Confirmed Notifications parametro.

Dopo aver verificato la validità della richiesta, l'API ricerca tutti gli oggetti che attivano gli eventi che soddisfano le seguenti condizioni, a partire dall'oggetto (in ordine interno crescente delle istanze dell'oggetto) dopo l'oggetto specificato dal Last Received Object Identifier parametro, se presente hanno un Event_State proprietà il cui valore non è uguale a NORMAL, o avere un Acked_Transitions proprietà che ha almeno uno dei seguenti bit (TO-OFFNORMAL, TO-FAULT, TO-NORMAL) impostato FALSE. Viene creata una risposta positiva, che contiene i riepiloghi degli eventi per gli oggetti trovati in questa ricerca. Se non vengono trovati oggetti che soddisfano questi criteri, viene restituito un elenco di lunghezza 0. Ne vengono restituiti tanti quanti possono essere restituiti entro il APDU. Se esistono più oggetti che soddisfano i criteri ma non possono essere restituiti nel file APDU, poi il More Events il parametro è impostato su TRUE; in caso contrario, è impostato su FALSE.

Dopo aver verificato la validità della richiesta, l'API aggiunge le informazioni ricevute al file Address_Binding proprietà dell'oggetto dispositivo. Viene utilizzato per risolvere i numeri di istanza del dispositivo in indirizzi MAC BACnet necessari per la comunicazione con quel dispositivo.

Dopo aver verificato la validità della richiesta, l'API aggiunge le informazioni ricevute a un elenco ordinato interno. Questo elenco viene utilizzato per risolvere i nomi degli oggetti in identificatori di oggetti necessari per accedere a tali oggetti.

L'API trasmetterà il non riconosciuto Who-Has richiesta, normalmente utilizzando un indirizzo broadcast. Se la Device Instance Range Low Limit e Device Instance Range High Limit esistono parametri, quindi l'API, il cui dispositivo Object_Identifier il numero di istanza rientra nell'intervallo Device Instance Range Low Limit >= Object_Identifier Instance Number <= Device Instance Range High Limit, è qualificato per rispondere. Se la Object Name esiste il parametro, quindi l'API, che contiene un oggetto con an Object_Name valore della proprietà che corrisponde a Object Name parametro, risponde con un I-Have richiesta servizio. Se la Object Identifier esiste il parametro, quindi l'API, che contiene un oggetto con an Object_Identifier valore della proprietà che corrisponde a Object Identifier parametro, risponde con un I-Have richiesta servizio.

L'API trasmette il non riconosciuto Who-Is richiesta, normalmente utilizzando un indirizzo broadcast. Se la Device Instance Range Low Limit e Device Instance Range High Limit mancano i parametri, quindi l'API restituisce il loro dispositivo Object_Identifiers nelle risposte individuali tramite il I-Am servizio. Se la Device Instance Range Low Limit e Device Instance Range High Limit esistono parametri, quindi l'API, il cui dispositivo Object_Identifier il numero di istanza rientra nell'intervallo Device Instance Range Low Limit >= Device Object_Identifier Instance Number <= Device Instance Range High Limit, restituirà il proprio dispositivo Object_Identifier per mezzo del I-Am servizio.

In primo luogo, l'API verifica la validità del Object Identifier. Restituisce un result(-) errore con la classe di errore e il codice di errore corrispondenti se l'oggetto è sconosciuto. Questo hook di servizio supporta solo i file a cui si accede tramite STREAM. Successivamente, viene verificata la validità dell'accesso ai file locali sul disco rigido locale e a result(-) viene restituita una risposta con la classe di errore appropriata e il codice di errore se la posizione iniziale del file non è valida o se il file non è accessibile per qualsiasi motivo. Se il controllo di validità ha esito positivo, il numero specificato Request Record Count di ottetti viene letto dal file locale. Se il numero effettivo di ottetti letti è inferiore a quello specificato, allora il Returned Record Count del restituito result(+) indica il numero di ottetti letti. Se viene raggiunta la fine del file, il file End Of File parametro del restituito result(+) è impostato per TRUE.

This service hook is implemented using the SysFile interface of CODESYS and supports STREAM access only. As a result, the user application may want to change particularly this service hook for the file access.

In primo luogo, l'API verifica la validità del Object Identifier. Restituisce un result(-) errore con la classe di errore e il codice di errore corrispondenti se l'oggetto è sconosciuto. Questo hook di servizio supporta solo i file a cui si accede tramite STREAM. Successivamente, viene verificata la validità dell'accesso ai file locali sul disco rigido locale e a result(-) viene restituita una risposta con la classe di errore appropriata e il codice di errore se la posizione iniziale del file non è valida o se il file non è accessibile per qualsiasi motivo. Se la File Start Position parametro della richiesta di servizio supera la dimensione del file locale, quindi il file viene esteso per la scrittura degli ottetti in ingresso. Se la File Start Position parametro ha il valore -1, quindi il file locale viene aggiunto con gli ottetti in entrata. Se la scrittura nel file locale non riesce, allora un file corrispondente result(-) viene emessa la risposta. Se la scrittura nel file locale ha esito positivo, allora result(+) viene emesso, che contiene il corrispondente File Start Position.

Questo hook di servizio viene implementato utilizzando l'interfaccia SysFile di CODESYS e supporta STREAM solo accesso. Di conseguenza, l'applicazione utente potrebbe voler modificare in particolare questo hook di servizio per l'accesso ai file.

In primo luogo, l'API verificherà la validità della richiesta verificando se il Object Specifier della richiesta specifica un tipo di oggetto creabile (secondo la regola interna BACnet.IsBACnetObjectAMEVCreatable). Restituisce un errore corrispondente result(-) se questo non è il caso. Se specificato dal Object Specifier, viene verificata la validità del numero di istanza dell'oggetto e viene visualizzato un errore corrispondente result(-) viene restituito nel caso in cui il numero di istanza non esista più. Se un List of Initial Values non è specificato, le proprietà dell'oggetto creato vengono create utilizzando i valori predefiniti come è consuetudine per le proprietà che non sono specificate in un dato List of Initial Values. Se la creazione dell'oggetto non riesce, si verifica un errore corrispondente result(-) viene rilasciato, mentre il First Failed Element Number della risposta è impostato su 0. Se la creazione ha avuto successo, a result(+) viene emessa la risposta, che contiene l'identificatore dell'oggetto creato.

Questa attuale implementazione di questo hook di servizio dovrebbe essere vista come un suggerimento più completo per la sua implementazione. Poiché è una questione puramente locale dell'applicazione utente come viene gestita questa richiesta di servizio, è molto probabile che l'applicazione utente fornisca il proprio hook di servizio per un'altra gestione della richiesta.

In primo luogo, l'API verifica la validità del Object Identifier e restituisce un result(-) risposta all'errore con la classe di errore corrispondente e il codice di errore se l'oggetto è sconosciuto. Se l'oggetto specificato può essere eliminato, a result(+) viene emessa la risposta. Se la cancellazione degli oggetti non riesce (esempio: l'oggetto non può essere cancellato dinamicamente secondo la regola interna BACnet.IsBACnetObjectAMEVCreatable), o per qualsiasi altro motivo, quindi a result(-) viene emesso.

L'attuale implementazione di questo hook di servizio dovrebbe essere vista più come un suggerimento completo per la sua implementazione. Poiché il modo in cui viene gestita questa richiesta di servizio è una questione puramente locale dell'applicazione utente, è molto probabile che l'applicazione utente fornisca il proprio hook di servizio per un'altra gestione della richiesta. Per ulteriori informazioni, vedere: Requisiti di implementazione quando si utilizza la corrente BACnet API/Stack