EOS Architektur / EOS Theorie

Was macht EOS besonders

Wenn man mit EOS arbeiten möchte, hilft es die Gründe zu verstehen, warum EOS anders aufgebaut ist und wie die Datenbank Architektur aufgebaut ist. Des weiteren ist es wichtig das Konzept von Typen-Klassen, Instanzen und wie Eigenschaften vererbt werden zu verstehen und in welchen Kontexten bei EOS hierarchische Strukturen aufgebaut werden können.

Mit diesem Verständnis erklären sich fast alle übrigen Schritte des Umgangs mit unserer Software, inklusive dem Erstellen von Sichten, Tabellen, dem Umgang mit Formeln und vielen weiteren Elementen auf die wir später eingehen werden.

Andere Systeme

EOS hat

1. starke Abweichungen zu Systemen in Hinsicht auf das Logging

2. starke Abweichungen zu Systemen die nur Auswertung betreiben

Es gab Hintergründe EOS ganz anders zu gestalten und anders aufzubauen als es bei z.B. Prozesshistorien Server, iba, arcron oder pi geschah.

Anders als EOS sind viele andere Systeme ursprünglich zuerst als Datenlogger entstanden. Daten sollten in den Anfängen also lediglich erfasst werden und das lief eine Weile. Dann entstand irgendwann der zusätzliche Anspruch Protokolle und Berichte generieren zu können, womit den jeweilgen Produkten Protokollmodule hinzugebaut wurden. Und auch dise Phase dauerte erst an. Aber erst mit zunehmender Automatisierung, neuer Rechenleistung und Energiebewusstsein kam zu guter letzt dann auch noch der Anspruch hinzu ebenfalls Berechnungen betrachten zu können, um so aus gelesenen Strom- und Spannungswerten z.B. die sich ergebende Leistung betrachten zu können, sodass erst ab dieser Phase Berechnungsmodule hinzu entwickelt wurden.

Datenlogger und seine Folgen

In der Folge war eine Architektur entstanden in der Messwerte auf einer wohlgemerkt langsamen Festplatte geloggt wurden. Mit der Not nun auch Berechnungen zu erfassen, gab es zwei Möglichkeiten. Das ändern der Datenarchitektur, um schnelles lesen und schnelles Berechnen on the fly erlauben zu können, oder das Verwenden vorhandener Strukturen und dies ergab anfangs auch Sinn. So wurde die alte Sturktur beibehalten und von Auftraggebern geforderte Berechnungen dann parallel zu den Datenlogger Daten in den selben Datenstrukturen mit erfasst. Der Vorteil war natürlich dass fast belieb viele Daten berechnet werden konnten, weil Festplatten-Speicherplatz ein sehr kostengünstiges Medium darstellt. Doch was geschieht, falls sich nach langer Zeit herausstellen sollte dass eine kompliziertere Formel fehlerhaft und eine lange Serie von Werten falsch geschrieben war mit evtl. weiteren bereits abgeleiteten Werten.

Solche Erkenntnisse führen in so einer Architektur dazu, dass alle berechneten Felder und alle sich darauf beziehenden weiteren Berechnungen für teils sehr lange Zeiträume neu berechnet werden müssen. Wir sprechen hier von Auswirkungen, erneute Berechnung über mindestens Minuten, häufiger Stundenandauern. Doch nicht nur Fehler, auch suboptimale Formeln, die angepasst werden müssen, führen zu den Problemen.

Viele Sonden, viele Fehler

EOS, als Nachfolger von CARE wurde im Zuge eines Auftrags von Gazprom entwickelt. Ein Vorteil, sowie eine Herausforderung in dieser Situation war, dass Gazprom Anlagen hatte, die sich ständig im Umbau befanden. Ständig wurde etwas erneuert und ständig wurden neue Berechnungsformeln hinzugefügt, die durch viele unterschiedlich alte, mal genaue, mal ungenaue Messgeräte schnell kompliziert wurden, was besonders schwierig wurde, da dort statt 60 gleicher Sonden, schnell eher mit 300 Sonden zu rechnen war. Wurden Summen über Volumenströme einzelner Sonden mit dem Eingangsvolumenstrom verglichen, stimmten die Summen alleine wegen der hohen Anzahl erstmal nicht, so dass mit einem Korrekturfaktor gerechnet werden musste, der natürlich mit jeder Modifikation oder Anpassung der Anlage ebenfalls angepasst werden musste und viele Neuberechnungen als Kettenreaktion nach sich zog. Zusätzlich gab es bei 300 Sonden statistisch viel häufiger ausfallende Sonden und diverse weitere Gründe die zu Messwerte-Ausfällen führten, häufig ausgetauschte Hardware und somit permanenten Bedarf zusätzliche Handwerte und Korrekturen einzupflegen.

Nachteil zuvor etablierter Architekturen

Hier kam der Nachteil oben genannter Architektur sehr schnell ans Licht. Denn statt mit dem System normal zu Arbeiten, war es meist morgens, nach kurzen Korrekturen erstmal für lange Zeiten mit Neuberechnungen beschäftigt und nicht nutzbar. Jede Formeländerung, jeder eingetragene Handwert konnte somit zu langanhaltenden Systemblockaden führen.

Nicht nur das. Jede Anpassung einer Formel musste nicht nur an einer, sondern gleich an 300 Stellen vorgenommen werden.

Es wurde schnell klar, dass man sich nicht um einzelne Objekte kümmern möchte, sondern wiederverwendbare Typicals mit bereits vordefinierten vererbbaren Eigenschaften haben will (gemäß Klassen der objektorientierten Programmierung) aus denen man Objekte / spezifische Instanzen generieren kann. In unserer Sprache also eine Klasse der Sonden, mit definierten Eigenschaften mit hinterlegten änderbaren Berechnungen, die auf alle instanziierten (Sonden-)Objekte angewendet wird.

Neuer Ansatz

Und hier aus dieser Situation entstand der Ansatz unseres Systems. Während bei vielen anderen die Datenspeicherung im Vordergrund standen, waren es in EOS von Anfang an die Auswertung und Berechnung. Statt Berechnungen auf die Festplatte zu schreiben, nehmen wir hierfür den viel schnelleren Arbeitsspeicher (RAM). Daten, also Rohdaten werden weiterhin auf die Festplatte geschrieben, das resultat der Berechnungen, sowie gie Messwerte selbst, werden bereits nach der Initialisierung im Arbeitsspeicher abgelegt. Dies war nicht leicht, denn der verfügbare Speicher im Arbeitsspeicher deutlich geringer als der von Festplatten ist, so dass man mit dieser Aufteilung sehr gut vorausplanen muss um genau die richtigen Daten vorzuhalten. Doch aus der Not entstand ein gut durchdachter und heute sehr flexibler Ansatz. Unsere Architektur ermöglicht uns sehr schnell zwischen Rohdaten-Rastern mit Erfassungen im Bereich von Millisekunden aber auch Rastern im Bereich von Minuten, Stunden oder Tagen zu wechseln. Unser System hat mit dem Wechsel der Architektur nicht nur eine, sondern mehrere neue Schichten erhalten und ermöglicht in diesem Zuge nicht nur Neuberechnungen in Bruchteilen der ehemals üblichen Zeit, d.h. in Sekunden statt in Stunden und ermöglicht darüber hinaus noch das Einpflegen von Handwerten ohne der sonst üblichen langen Neuberechnungs-Pausen. Statt alte Daten immer nur zu überschreiben, behalten wir nicht nur alte Daten, sondern sehen auch noch bei jeder Korrektur, wann und von wem sie erfolgt ist.

Zusammengefasst halten wir nicht nur ein einziges, sondern viele Raster vor, und haben selbst mit Datensätzen über langen Zeitraum mit mehr als 1000 Messwerten pro Messpunkt und 10.000 Berechnungen ein performantes und sehr flexibl managebares System. Wir können flexibel on the fly komplizierteste und kaskadierende Berechnungen anpassen, Datenwerte korrigieren und hinzufügen, während Orginaldaten ebenfalls unverändert bleiben und können zusätzlich fast on the fly historische Rohdaten der letzten Dekaden laden und in die uns gewohnten Sichten mit enthaltenen neusten Formeln und Berechnungen integrieren und analysieren.

Außerdem haben wir das Konzept einer objektorientierten Modellierung entwickelt. Mit dieser Struktur ist es uns ermöglicht sich wiederholende Strukturen in Form von Klassen abzubilden, von denen andere Klassen abgeleitet werden können und aus denen dann erst ganze Objektgruppen entstehen, die alle Eigenschaften zentral verwaltet haben, so dass die Änderung einer Formel für 300 Sonden auch wirklich nur die Änderung einer Formel bedeutet.