Historical Access

Durch Unterstützung der OPC UA Historical Access Funktionalität ermöglicht der WinCC OA OPC UA Server seinen Clients den Zugriff auf historische Daten.

Tipp:

Unterstütze Typen des Historical Access:

  • Data Access
  • Alarms and Conditions

Zur Bereitstellung der Daten wird der Server-Adressraum um historische Nodes/Notifiers erweitert. Dieses Kapitel beschreibt wie das Historical Access Feature aktiviert werden kann.

Server-Adressraum

Der Adressraum des WinCC OA OPC UA Servers wird mit Hilfe der OPCUARead und OPCUAWrite Gruppen aufgebaut (siehe auch Datenpunktgruppen für weitere Informationen). Jedes Datenpunktelement das einer dieser Gruppen zugewiesen ist, wird im Adressraum auf ein entsprechendes Element abgebildet.

Um zu definieren, für welche dieser Elemente Historical Access verfügbar sein soll, müssen die gewünschten Datenpunktelemente zusätzlich der OPCUAHARead-Gruppe zugewiesen werden. Das bedeutet, dass historische Werte nur von Elementen abgefragt werden können, die sowohl in OPCUARead (bzw. OPCUAWrite) als auch in OPCUAHARead definiert sind. Datenpunktelemente die nur in OPCUAHARead definiert sind, werden vom Server ignoriert.

Datenpunktelementen dessen historische Werte abgefragt werden sollen, müssen Sie außerdem noch ein _archive-Config zuweisen (siehe auch History DB bzw. RDB-Archivierung).

Für historische Alarme wird keine _archive config benötigt, da die Alarme in der historischen Datenbank gespeichert werden, wenn dies in der Alarmklasse konfiguriert ist. Für historische Basisereignisse muß der auslösende dyn_string DPE einen _Archiv config haben, sonst können die historischen Ereignisse nicht aus der Datenbank abgerufen werden.

Anmerkung: Sie können die Datenpunktgruppe (Default: OPCUAHARead) welche für die historischen Daten des OPC UA Servers verwendet soll mit Hilfe des Config-Eintrags [opcuasrv] opcuaHAReadGroup ändern.

Zugriff auf historische Daten

Unterstützte Datentypen

Mit Ausnahme von LocalizedText und Blob sind alle vom WinCC OA OPC UA Server unterstützten Datentypen auch für Historical Access verfügbar. Eine genaue Auflistung finden Sie unter Datenaustausch - Zuordnung Datentypen.

Beispiel

  1. Erstellen Sie die notwendigen Datenpunktelemente die auf den Server-Adressraum abgebildet werden sollen. Für dieses Beispiel wurden die Datenpunktelemente Node1, Node2 und Node3 erstellt.
  2. Erstellen Sie ein _archive-Config an jenen Datenpunktelementen für die Historical Access verfügbar sein soll (in diesem Beispiel: Node1).
  3. Weisen Sie die Datenpunktelemente (Node1, Node2, Node3) entweder OPCUARead oder OPCUAWrite zu. Diese Elemente werden somit auf den Server-Adressraum abgebildet.
  4. Fügen Sie die notwendigen Datenpunktelemente (Node1) der Gruppe OPCUAHARead zu. Das bedeutet, dass der Zugriff auf historische Daten nur bei diesem Datenpunktelement möglich ist.
  5. Starten Sie den WinCC OA OPC UA Server. Historische Daten von Node1 können jetzt von OPC UA Clients abgefragt werden.
Anmerkung: Durch Verwendung von [opcuasrv] historyNumValuesPerNode können Sie die maximale Anzahl an Werten definieren, die vom Server pro readRaw-Request geliefert werden soll.

Abfragen von Daten des Servers

Der WinCC OA OPC UA Server unterstützt die readRaw-Funktion. Mit Hilfe dieser Funktion können OPC UA Clients historische Daten vom WinCC OA OPC UA Server abfragen. Mit einem readRaw-Aufruf können mehrere Items gleichzeitig abgefragt werden.

Folgende Parameter stehen bei der readRaw-Function zur Verfügung:

continuationPoint
Der Continuation Point der letzten Abfrage.
timestampsToReturn
Der Zeitstempel (Quelle, Server oder beides) der zurückgeliefert werden soll.
numValuesPerNode
Die maximale Anzahl an Werten die pro Element zurückgegeben werden soll
startTime
Startzeitpunkt des abzufragenden Zeitraums
endTime
Endzeitpunkt des abzufragenden Zeitraums
returnBounds
Dieses Flag gibt an, ob Bounding Values zurückgegeben werden sollen oder nicht
Anmerkung: Der WinCC OA OPC UA Client verwendet ebenfalls die readRaw-Funktion um historische Daten eines Servers abzufragen. Nähere Informationen zur Verwendung der Funktion finden Sie unter OPC UA Client - Historical Access und _OPCUA.Command.HistoryRead. Eine detaillierte Beschreibung von readRaw können Sie dem OPC UA Standard entnehmen.

Continuation Point

Der Continuation Point wird vom Server verwaltet. Falls die Anzahl an zurückgelieferten Elementen größer als der vom Client festgelegte Wert ist, muss der Continuation Point verwendet werden. Die entsprechenden Daten werden vom Server gespeichert. Werden die übrigen Elemente vom Client unter Verwendung des Continuation Points angefordert, so werden die restlichen Werte vom Server-Speicher geliefert, ohne dass ein weiteres dpQuery erforderlich ist.

Historical alarms and conditions

Unterstützte Alarmtypen

Jede Konfiguration, die von der Funktion Alarme und Bedingungen unterstützt wird, wird auch für die historischen Alarme und Bedingungen unterstützt (siehe Historical Access).

Beispiel

  1. Erstellen Sie die entsprechenden Datenpunktelemente, die auf den Adressraum abgebildet werden sollen, und konfigurieren Sie ein gültiges Alarm-Handle darauf. Für dieses Beispiel wurde das boolesche DPE Alarm_CameAndWent.boolean des DPT TestUAAlarmServer erstellt und ein _alert_hdl mit der Alarmklasse "CAME or WENT must be acknowledged" konfiguriert.

  2. Weisen Sie das Datenpunktelement (Alarm_CameAndWent.boolean) der OPCUAAlarm und OPCUAHARead DpGroup zu.

  3. Verwenden Sie nun den UaExpert, um sich mit dem Server zu verbinden, fügen Sie die EventView hinzu und ziehen Sie den Knoten Server -> TestUAAlarmServer_@notifier Notifier in die Konfiguration.

    Abbildung 1. UaExpert - Event Notifier Konfigurations-Export
  4. Lösen Sie nun das folgende Szenario auf dem DPE Alarm_CameAndWent.boolean aus:
    • CAME
    • QUITTIEREN
    • WENT
    • QUITTIEREN
    Im UaExpert sind die folgenden empfangenen Ereignisse zu sehen:
    Abbildung 2. UaExpert - Received Events Export
    Erläuterung zu den empfangenen Zeilen (für eine detaillierte Information, was ActiveState, AckedState, BranchId und Retain ist, konsultieren Sie bitte in die OPC UA Spezifikation):
    1. Die Zeile für das durch das CAME-Ereignis des Alerts ausgelöste came-Ereignis (ActiveState=true, AckedState=false, Retain=true, BranchId=null)
    2. Die Zeile für das Ereignis "acked came", ausgelöst durch die Bestätigung des CAME (ActiveState=true, AckedState=true, Retain=true, BranchId=null)
    3. Die Zeile für das "went"-Ereignis, ausgelöst durch das WENT-Ereignis des Alerts (ActiveState=false, AckedState=false, Retain=true, BranchId=null)
    4. Die Zeile für das Ereignis "acked came" in einem neuen Zweig, ausgelöst durch das Ereignis WENT des Alerts (ActiveState=true, AckedState=true, Retain=true, BranchId=UUID)
    5. Die Zeile für das "acked came"-Ereignis in der Verzweigung, ausgelöst durch die Quittierung des WENT (ActiveState=true, AckedState=true, Retain=false, BranchId=UUID)
    6. Die Zeile für das Ereignis "Acked went", ausgelöst durch die Bestätigung des WENT (ActiveState=false, AckedState=true, Retain=false, BranchId=null)

  5. Lösen Sie nun eine historische Ereignisabfrage im UaExpert für den Zeitbereich des obigen Beispiels aus. Im UaExpert sind die folgenden empfangenen historischen Ereignisse zu sehen:

    Abbildung 3. UaExpert - Historical Events Export

Unter Verwendung des [opcuasrv] historyNumValuesPerNode Konfigurationseintrag können Sie die maximale Anzahl von Werten festlegen, die der Server pro readEvents-Anfrage bereitstellt.

Abrufen von Daten vom Server

Der WinCC OA OPC UA Server unterstützt die Funktion readEvents. Daher können OPC UA Clients diese Funktion verwenden, um historische Ereignisse vom WinCC OA OPC UA Server abrufen. Es ist möglich, mehrere Items mit einem readEvents-Aufruf abzufragen. Da OPC UA Alarme auch OPC UA Events sind, werden die Alarme auch mit der readEvents Funktion empfangen.

Die Funktion readEvents stellt die folgenden Parameter zur Verfügung:

continuationPoint
The continuation point data from a previous Read call.
numValuesPerNode
The maximum number of values per node to return.
startTime
The start time of the time period to read.
endTime
The end time of the time period to read.
filter
The wanted attributes of the historical events
Einschränkung: Only the SelectClauses are supported, WhereClauses are not supported at the moment.

Fortsetzungspunkt

Der Fortsetzungszeitpunkt wird vom Server verwaltet. Wenn die Anzahl der zurückgegebenen Ereignisse größer ist als der vom Client angegebene Wert, muss der Fortsetzungspunkt verwendet werden. Die Ereignisse werden vom Server zwischengespeichert. Wenn die verbleibenden Ereignisse vom Client über den entsprechenden Fortsetzungspunkt angefordert werden, wird der Speicher des Servers verwendet, um die restlichen Ereignisse abzurufen. Daher ist keine zusätzliche Abfrage erforderlich.