Scripts erzeugen Scripts

(elkement. Erstellt: 2017-01-31. Tags: MS Access, Datenauswertung, Engineering, MS Excel, Logfile, Logging, Software-Entwicklung, SQL. Englische Version.)

Das ist wieder einmal ein Beitrag zur Kategorie Technik – wobei die Grenzen zu 'IT' nicht sehr deutlich definiert sind, wie mein letzter Blogartikel über die Datenkrake zeigen.

Ich bin ja bei uns die Theoretische Abteilung und zuständig für Softwareentwicklung, Simulationen und Messdatenauswertung für unser Wärmepumpensystem (und das anderer Siedler, auch 'Kunden' genannt).

Es gibt einen wesentlichen Unterschied zwischen reinen IT-Projekten (z.B. PKI-Consulting) und 'Ingenieursprojekten mit IT': In letzterem Fall kenne ich und definiere ich die Anforderungen der Software zu 100% selbst – im Zentrum steht immer 'irgendetwas mit Energie'; im anderen Fall arbeite ich an Software oder Infrastruktur für Anforderungen, die jemand anderer definiert.

Glücklicherweise lässt sich fast alles, was ich jemals in der IT gemacht habe, auch 'energiebezogen' wiederverwerten: Heizungen und Steuerungen werden Teil des Internet of Things – IT-Sicherheit ist ein zentrales Thema. 2015 habe ich diese Website komplett umgebaut, endlich in .NET und ASP endlich deaktiviert. Als Spin-Off davon wurde auch meine numerische Simulation unseres Wärmepumpensystems eine .NET-Applikation: Jede Komponente im Hydraulikschema wird zu einem Objekt; fast ein Lehrbuchbeispiel. 2014 wurde aus einer immer schwerer zu bändigen Excel-Datei mit Makros endlich eine SQL-Server-Datenbank. Die Datenkrake wurde seither schrittweise erweitert, Excel-Plots wurden automatisiert erstellt etc.

Hin und wieder kommen mir diese Datenkraken-Skills auch in den 'eigentlichen' IT-Projekten zugute – damit meine ich meine PKI-Projekte. Die IT-Kategorie hier ist ja irgendwie zu einer Art Timeline verkommen mit Status-Updates zum Thema 'Machst Du noch PKI?'. Es kann ja ganz nützlich sein, ein Certificate Practice Statement entsprechend dem RFC semi-automatisch zu erzeugen. Aber ich würde mich nie als Experten für Datenanalyse, SQL, o.Ä. bezeichnen: Ich bin eigentlich wieder dort angekommen, von wo ich vor vielen Jahren losgezogen bin.

Als IT-Berater bin ich immer wieder gefragt worden: Wie kommt man als Physiker in die IT? Die logische Begründung ist die unvermeidbare Programmiererfahrung des Physikers. Ja, auch ich habe vor vielen Jahren an Software mitentwickelt auf der Uni an einem unübersichtlichen Haufen Software, ganz ohne Frameworks, Methodologien und Qualitätssicherung – für die Automatisierung der Messung der elektrischen Eigenschaften supraleitender dünner Schichten. Aber ich war experimenteller Physiker und meine Arbeit war nicht wahnsinnig 'computational' – genauso wenig erforderte meine spätere Beschäftigung mit angewandter Kryptografie (Public Key Infrastructure) tiefe mathematische Kenntnisse im täglichen Umgang. Eigentlich sehe ich die Parallele zwischen Physik und IT eher darin, dass Software sehr schnell genauso komplex wie unvorhersehbar wie ein von vielen Parametern beeinflusstes Naturphänomen. Man benötigt Geduld, Durchhaltevermögen und Freude daran, sich beim Troubleshooting durch einen Hyperraum von Möglichkeiten zu tasten – was in der Praxis heißt, den immer gleichen Prozess mit kleinen Änderungen immer wieder durchzuspielen.

Auch wenn sich das für Nicht-Geeks sehr langweilig anhört: Aus meiner Sicht sind diese Software-Basisarbeiten genau dann lohnend und interessant, wenn das große Ganze – der eigentliche Zweck, das 'Zielsystem' – lohnend ist. Und Letzteres sind für mich Wärmepumpen, Stromzähler, PV-Generatoren o.Ä. Da investiere ich gerne Stunden in das Debugging des Verhaltens fragwürdiger Firmware-Updates – genauso wie ich damals zumindest die Grundlagen von Turbo Pascal lernen musste, um Tieftemperaturmessungen durchzuführen.

2017 konzentriere ich mich auf die langsame Weiterentwicklung (und das Troubleshooting) der Datenkrake – und die langsame Annäherung von Messdatenauswertung (Echtkrake) und Simulation (virtueller Krake).

Hier einmal eine Bestandsaufnahme der aktuellen Features der Datenkrake – das ist der eigentliche Zweck dieses Artikels:

  • Dokumentation aller Sensoren bzw. Messwerte verschiedener Datenlogger (Wärmepumpe / UVR16x2, Smart Meter, PV-Wechselrichter…) in einer Access-Datenbank – einer kleine Proto-Krake.
  • Dokumentation aller Änderungen an Sensoren und Logfiles, wie: Durcheinander geworfener Logfile-Spalten, neue Namenskonventionen für Logfiles, oder ausgetauschte Sensoren. Z.B. wurde die manuelle 'Lineal'-Ablesung des Füllstandes im Eisspeicher ersetzt durch einen automatisierten Füllstandsmesser.
  • Ein Powershell-Script holt sich alle Roh-Logfiles und macht das unvermeidliche Datumsformat- und Dezimalkomma-oder-Punkt-Voodoo (performanter als eine entsprechende nachträgliche Änderungen im SQL-Server).
  • Dann erzeugt diese Powershell-Script die SQL-Scripts, die den eigentlichen Import und die Berechnungen in der Datenbank durchführen – ein Set von Scripts und eine SQL-Datenbank pro Siedler (Kunde). Z.B. werden die CREATE TABLE oder ALTER TABLE Befehle für die jeweils benötigen Felder aus der Felddokumentation in der Access-Proto-Krake erzeugt.
  • Diese SQL-Scripts sorgen dann dafür, dass nur Daten der richtigen (neuesten) Logfiles importiert werden – in eine Zwischentabelle. Jede SQL-Datenbank kann damit ggf. von Null weg neu aus den CSV-Dateien und der Access-Dokumentation erzeugt werden.
  • Die Zwischentabelle ist nötig, um Fehler korrigieren zu können: Z.B. werden vom Logger selbst als Fehler gekennzeichnete Werte (9999) identifiziert, oder Werte werden auf der Basis einer Tabelle besonderer Ereignisse (Sensor X war zwischen Y und Z Uhr nicht aktiv) auf NULL gesetzt.
  • Zum Schluss läuft dann endlich das wichtigste SQL-Script: Die eigentlichen Berechnungen von Mittelwerten, von Energien aus aktuellen Leistungen (Kollektorernte, Heizenergie…), Arbeitszahlen, Laufzeiten etc. Dafür sind einige 'Ebenen' an SQL-Views nötig.
  • Das Frontend dazu ist natürlich … Microsoft Excel! Tabellen von täglichen, monatlichen und jährlichen Kennwerten werden so dargestellt, dass man einfach zwischen verschiedenen Zeiträumen umschalten kann.
  • Diagramme werden verwendet, um Tagesgänge darzustellen (wie ändert sich das Eisvolumen?) oder Balkendarstellungen der monatlichen oder jährlichen Energiebilanzen. Die im Diagramm benötigten Felder und der Zeitraum werden in einer Definitionstabelle für die Diagramme ausgewählt, so dass die eigentlichen Plots dann automatisch geändert werden können. Details wie Farben und Strichbreite werden direkt im Diagramm geändert.

So seltsam wie diese Architektur klingt – bis jetzt war es möglich durch diese relative Unabhängigkeit der 'Teildatenbanken' das ganze System Schritt für Schritt weiterzuentwickeln … in einem Umfeld, in dem Veränderung die einzige Konstante ist … bedingt durch externe Einflüsse wie unvorhersehbare Auswirkungen von Firmware-Updates.

Datenkrake - Plottomat

Persönliche Website von Elke Stangl, Zagersdorf, Österreich, c/o punktwissen.
elkement [ät] subversiv [dot] at.