Eine Variable im Historian kann eine Zahl sein. Das wird sicher ein häufiger Einsatz sein.
Variablen - oft Zahlen, sind Fest oder Fließkommawerte. Es können auch Texte sein.
Felder sind möglich, ein Beispiel kann eine Liste von Zahlen sein.
Komplexe Dinge wie Strukturen die mehrere auch unterschiedliche Zahlen enthalten sind auch möglich.
Bei komplexen Daten ist es sinnvoll den Trigger - das ist der Wert dessen Änderung einen Eintrag mit Zeitspempel im Historian auslöst - unabhängig zu bestimmen. Am Einfachsten wird das mit dem Produkt PLC Engine umgesetzt. Dort können zusätzlich auch Umrechnungen vorgenommen werden. Das kann notwendig sein wenn ein analoger Fließkommawert im Historian verarbeitet werden soll. Fast alle Signalgeber haben ein Rauschen, der Wert ändert sich ständig um einen sehr kleinen Wert. Eine Grenzwertprüfung verhindert das zu häufige Datenschreiben. In der Technik wird das auch Deadband genannt.
Komplexe Daten können umfangreich sein. Wird das im Historian verwendet so sollte die Hardware entsprechend leistungsfähig sein. Komplexe Datenstrukturen können nicht so einfach z.B. in Trendkurven angezeigt werden. Der Vorteil ist aber das ein zeitsynchroner Dateneintrag viele Dinge beinhalten kann.

Der Historian kann auch auf einem anderen System betrieben werden als das auf dem der OPC Server arbeitet. Das kann so weit gehen das mehrere OPC Server Daten in einen Historian geben. Einzig eine bestimmte Variable im Historian kann schreibend nur von einer Datenquelle aus gefüllt werden. Lesen, also die History nutzen - können Mehrere. Jede Variable im Historian hat immer eine Datenquelle.
Wichtig wird das wenn die OPC Datenquellen auf kleinen Embedded Systemen arbeiten. Datenspeicher haben diese Systeme selten, Festplatten praktisch niemals. Dann bietet es sich an den Historian auf einem PC oder in einer Cloud zu betreiben. Mehrere Stationen nutzen den dann gemeinsam.
Der Datenverkehr von einem OPC Server zum Historian beim Aufzeichnen ist klein. Es werden nur neue geänderte Daten übertragen. Die Belastung der Netzwerke ist sehr gering.
Auch wenn ein OPC Server nun Historydaten anfordert so bleibt die Datenrate eher klein. Denn die Berechnungen der Daten erfolgt im Historian. Es werden nicht einfach alle Daten zum OPC Server gegeben und der filtert und berechnet dann, sondern der Historian übernimmt diese Arbeiten. Die Speicherformate des Historian sind so definiert das kaum Berechnungen nötig sind. Die Originaldaten werden direkt über bei der Aufzeichnung mit erstellten Indexdateien angesprochen. Das garantiert auch auf einfachen preiswerten Rechnern eine sofortige Datenausgabe.

Die Software stellt die Historyfunktionen allen Systemen bereit die in der Lage sind das zu nutzen. Das sind:

• OPC UA
  OPC UA kennt Historyfunktionen. Bei allen Variablen die in der Historian Konfiguration angegeben sind werden die entsprechenden Funktionen angeboten. Ein UA Client kann vorgeben in welchem Raster die Daten der History abgerufen werden. Diese Anfragen bildet der Historian auf die wirklich verfügbaren Daten ab und liefert die aus.
  Wichtig: Allein aus Sicherheitsgründen können Daten nur hinzugefügt und gelesen werden. Verändern oder Löschen der Daten wird nicht zugelassen.
• BACnet
  Mehrere BACnet Elemente wie die Trendelemente greifen auf die Daten zu. Natürlich muss in der Historian Konfiguration das entsprechend angegeben sein.
  Wie bei OPC UA können die Daten nur hinzugefügt und gelesen werden. Sicherheit geht vor.
• REST API für Trendkurven
  Eine REST Schnittstelle ist für Anforderungen im Web Bereich vorgesehen, sie kann aber überall genutzt werden wenn ein Programm REST unterstützt.
  Es gibt Regeln für REST, aber keinen festen Standard. Tani bieten eine REST API Schnittstelle an. Diese Schnittstelle bleibt langzeitstabil. Auch starke Weiterentwicklungen im Historian werden bestehende Anfragen weiter ausführen.
  Es wird ein einfaches Webelement in Quellen mitgeliefert das eine Trendansicht abbildet. Die Kommunikation zum Historian nutzt das REST Interface. Sie können dieses Trendelement beliebig nutzen und auch weitergeben.
  Das Trendelement stellt gleichzeitig auch eine gute Diagnose der Daten im Historian dar.
  Wie im bereits existierenden Web Toolkit gibt es zwei Varianten für das Trend Element: Für Webserver die PHP nutzen und für das Node.js System.

Einfach alle Daten immer aufzeichnen macht wenig Sinn. In Anlagen werden oft tausende von Daten genutzt. So müssen die Variablen die eine Historyfunktion bieten konfiguriert werden.

Die Variablen die der Historian verarbeitet stammen aus einem Prozess, häufig aus einem OPC Server. Im OPC Server hat eine Variable oft einen langen Pfad. Zur einfacheren Verwaltung nimmt der Historian eigene - oft sprechendere - Namen. Die Zuordnung legen Sie selbst fest, eine 1:1 Zurodnung ist möglich. Das Bestimmen der jeweiligen Variable erfolgt wie gewohnt einfach - mit Browsing. Es gibt viele Optionen zum Aufzeichnen: Zeitraster, wann eine neue Datei genommen wird und vieles mehr. Ein einfacher Assistent beim Einrichten nutzt Standardwerte, die können bei Bedauf auch später jederzeit angepasst werden.
Zusätzlich zu den Daten die eine Trendansicht braucht können Sie weitere Werte direkt zur Aufzeichnungszeit mit berechnen lassen. Das sind Minimal und Maximalwerte, der Durchschnitt une einine mehr. Reicht das nicht aus so haben Sie in der PLC Engine umfangreiche Umrechnungs und Normierungsfunktionen.

Tani legt Wert auf Offenheit. Die Dateiformate die der Historian nutzt liegen in dieser Beschreibungsdatei. Damit können auch ohne das REST Interface oder den kompletten OPC Server zu nutzen die Daten von eigenen Programmen verarbeitet werden. Viele der Dateien aus denen eine Variable besteht werden vom Historian zur Laufzeit nur am Dateiende beschrieben. Das erleichtert den Zugriff, Lesen ist immer möglich.