2021-03-06

Dauerhaftes Datenlogging mit GxP im Blick – Idee und Grobplanung -

Nehmen wir an wir wollen für einen Versuchsstand einige Umgebungswerte dauerhaft überwachen. Kann man einen Datenlogger bauen der:

  • Ein Set aus ein paar Umgebungsdaten (Temperatur, Luftdruck, relative Luftfeuchte)
  • jede Minute
  • mit Zeitstempel speichert
  • alle neuen oder alle bisherigen Daten über eine Schnittstelle ausgibt?

Ja, kann man. Kann man wahrscheinlich sogar fertig kaufen. Die Einzelsensoren für die jeweiligen Messwerte gibt es zumindest als Massenware. Für diese drei Messwerte gibt es z. B. dem BME280. Das ganze Prinzip lässt sich natürlich beliebig auf andere Sensoren anpassen. Für einen Zeitstempel kann eine Echtzeituhr, z. B. DS1307 als Referenz genommen werden. Das ist zu einfach.

Ziehen wir die Daumenschrauben an, GPW verlangt für Forschungsdaten eine Ablage nach dem FAIR-Prinzipien („Findable, Accessible, Interoperable, Re-Usable“), gehen wir Richtung GMP landen wir beim ALCOA-Prinzip: Attributable (Zuordenbar), Legible (permanent lesbar), Contemporaneous (aktuell) Original (in originaler Form), Accurate (richtig).

Elektronik hält nicht ewig und Sensoren mit Umgebungskontakt werden mit dem Alter auch nicht besser. Es muss irgendeine Art von Pufferbatterie in dem Gerät verbaut werden damit des mit der Echtzeituhr und dem Zeitstempel klappt. Machen wir Lifecycle Management und legen die Betriebsdauer auf vier Jahre fest.

Die Grundanforderungen sind also diese:

  • Sensormodul BME280
  • Echtzeituhr DS1307
  • 4 Jahre Geräteeinsatz
  • Alle Daten aus dieser Zeit speichern
    • Manipulationssicher (keine Änderung bereits aufgezeichneter Daten)
    • Zeitstempel
    • Geräte ID (Seriannummer o.ä.)
    • Gerätezustand
    • Messwerte
    • Kalibrierwerte
    • Fehlererkennung/Korrektur bei gespeicherten Daten, redundante Speicherung
  • Archivmodus nach Außerbetriebnahme. Keine neue Datenaufzeichnung mehr, ein Auslesen aber weiterhin möglich.
  • Möglichkeit die Systemzeit für den Zeitstempel über Schnittstelle zu kontrollieren und ggf. zu korrigieren
    • Änderungen an der Systemzeit müssen mit aufgezeichnet werden und nachvollziehbar sein
  • Standalone Betrieb mit Auslesen bei Bedarf oder Systemeinbindung PLC/PC mit azyklischem Zugriff.

Basteln wir aus diesen Anforderungen das Datenfeld das gespeichert werden muss, damit wir eine Aussage über den nötigen Massenspeicher machen können.

  • Eine DS1037 liefert einen kompletten Zeitstempel in 7 Byte
  • Die Seriennummer können wir beliebig wählen, 2 Byte (16 bit) sollten reichen
  • Für den Gerätezustand wählen wir großzügig ein Statusword mit 2 Byte
  • Der BME280 liefert pro Messung 8 Byte an Daten
  • Die Kalibrierwerte des BME280 umfassen 32 Byte
  • CRC16 braucht für eine Prüfsumme 2 Byte

Ergibt in Summe 53 Byte an Daten pro Messpunkt. Auf vier Jahre gerechnet sind das ~105 MB, das ist eher handlich, was die Datenmenge angeht. EEPROMS scheiden damit aber zur Datenspeicherung aus. Flashspeicher ist das nächste Mittel der Wahl, SD-Karten gibt es mit mehr als 256 GB Kapazität, da liegen wir deutlich drunter. Die nötigen Datenraten von 53 Byte/min sind auch von den technischen Daten der Karten abgedeckt. Allerdings mögen SDHC/XC-Karten eine Blockgröße von 512 Byte, die werden komplett geschrieben oder gelesen. Da laufen wir in den Punkt “Manipulationssicher”, der gilt auch für das Gerät selbst bei internen Operationen. Daten, die einmal geschrieben sind, werden nicht mehr geändert. Wir schreiben also immer einen kompletten Block auf die SD-Karte pro Messpunkt auf die SD-Karte und fassen den danach nur noch lesend an. Dann brauchen wir für die 4 Jahre Datenerfassung ~1 GB. Weil sich die SD-Karten bis 2 GB anders (vor allem unhandlicher) ansprechen lassen und so langsam vom Markt verschwinden kommen nur Karten Typ SDHC/XC zum Einsatz.

Hier gibt es dann einen schöne Qualifizierungs- und Validierungsgedankengang. Die Spezifikation für SDXC schreibt exFAT als Dateisystem vor, damit lässt sich das nur einmalige Beschreiben eines Blocks nicht garantieren. Ohne exFAT Dateisystem und saftige Lizenzgebühren darf ich mich aber nicht mit dem SDXC-Logo schmücken. Die Lösung ist die technische Betrachtung und ein rechtliches Detail. SD-Karten dürfen, wenn man keine Lizenzzahlungen tätig nur über ihren SPI-Modus angesprochen werden, der ist zu langsam für die meisten Anwendungen, für einen Datenlogger mehr als ausreichend. Wir verzichten also auf das SD-Logo, begnügen uns mit SPI-Zugriff. Außerdem machen wir die Karte für den Anwender unerreichbar, indem sie ins Gehäuseinnere verlagert wird, das bietet sich schon aus Gründen der Manipulationssicherheit an. Bleibt noch die Forderung nach exFAT. Die hat keine technischen Gründe aufseiten des Speichers, dem sind die abgelegten Datenstrukturen egal. Gefordert ist exFAT, weil die Karten sofort in allen kompatiblen Geräten funktionieren sollen. Karte rein, Speicher verfügbar. Betreiben von SDXC-Karten außerhalb der Spezifikation ist also kein technisches Risiko.

Im Prinzip kann auch SPI-Flashspeicher verwendet werden. Das hat aber zwei Nachteile in angenommenen Fall. Beim Selbstbau von Geräten sind SMD-Bauteile immer eine Herausforderung in der Anwendung. Sensoren stehen meist auf Breakoutplatinen zur Verfügung, Flashspeicher selten. Außerdem gibt es noch die Überlegung des Notfallzugriffs auf die Daten bei Beschädigung des Gerätes aus Sichtpunkt der Datenintegrität. Eine SD-Karte lässt sich einfach entnehmen und am Computer bei Kenntnis der Datenstruktur mit gängigen Lesegeräten auswerten. Die Datenintegrität ist also so lange gegeben bis das Medium entweder physisch zerstört oder mutwillig gelöscht wird.

Wir haben jetzt genug Details um Lasten- und Pflichtenheft auszuformulieren. Der Einzelkämpfer wird das wahrscheinlich etwas weniger Formal angehen und die Geräteplanung mit der Hardwareauswahl verbinden.

© Oliver Grünzel 2019
Impressum & Datenschutz