Fakt ist: Einen Großteil der Zeit, der an analytischen Laborgeräten verbracht wird, nimmt heute die Systempflege in Anspruch. Der digitale Wandel kann uns endlich wieder mehr Zeit für Kreativität und die eigentliche Laborarbeit geben – wenn wir ihn richtig gestalten.

Zunächst sollten wir eine vereinfachte und dennoch sichere Integration unserer Laborgeräte umsetzen, ohne den üblichen Konflikt zwischen Gerätehersteller und hausinterner Informationstechnik (IT). Die Softwareentwicklung und -pflege ist für einen Gerätehersteller wegen der äußerst komplex gewordenen IT-Landschaft und schlecht programmierten Entwicklungsumgebungen und Betriebssystemen unüberschaubar und aufwendig geworden. Er liefert deshalb am liebsten eigene PCs zusammen mit seiner Software aus und empfiehlt, von Patches und Virenscannern abzusehen. Das ruft die Haus-IT und Qualitätsmanager auf den Plan, die auf Einhaltung von IT- und Qualitätsmanagement-Richtlinien des Hauses beziehungsweise des Kunden bedacht sind. In der Regel sind diese Welten nur sehr schwer miteinander vereinbar.

Software-Patches und Sicherheitsupdates sind zwar wichtig für die Sicherheit, stellen heute aber stets ein Risiko für ein laufendes System oder den zuletzt validierten Status dar. Nicht ins Netzwerk eingebundene oder unzureichend geschützte Geräterechner verleiten umgekehrt zum Umgang mit USB-Sticks. Benutzerrollen lassen sich vielfach nicht professionell umsetzen oder sind zu aufwendig im täglichen Geschäft. Die immerwährende Spirale der Betriebssystem-Updates oder der Erneuerung defekter Hardwarekomponenten stellt die Nutzer vor große Herausforderungen und sind in jeder Hinsicht teuer. Das Ergebnis sind sehr oft individuelle Einzellösungen unter dem Radar. Gar nicht gut!

Dann wäre da noch der Umgang mit den Daten. Zu beklagen sind zu viele proprietäre Formate und uneinheitliche Datenstandards, die fast immer manuelle Datenvorbehandlungen wie Format- und Zeichenumwandlungen sowie Kopiervorgänge erfordern und den Anwender viel Zeit kosten. Anforderungen an gute wissenschaftliche und Laborpraxis sind damit nur sehr schwer zu erreichen.

Früher war alles besser?

full-screen

Abb. 1 Eine Mitarbeiterin benutzt das Beckman Microlab 620 MX Infrarot-Spektrophotometer. Aufnahme ca. 1978-1987 [1]

Was brauchen wir stattdessen? Hier erinnere ich mich gerne an meine Doktorandenzeit zurück, als ich mit Laborgeräten zu tun hatte, die gerade den ersten Schritt von der rein manuellen Gerätebedienung an Reglern und Knöpfchen zur Softwaresteuerung machten und die Funktionen gut strukturiert in der Software abbildeten – wie am Gerät selbst (Abb. 1). Alle Funktionen gab es auch per RS-232-Schnittstelle – nicht die schnellste, aber gut genug. Oft war es problemlos, die komplette Schnittstellenbelegung kostenlos vom Hersteller zu erhalten. Mein erstes Pascal-Programm hatte alles, was man brauchte: Die Auswahl aller Einstellungen zur Methodenentwicklung und die individuelle Gestaltung der Messreihen. Selbst als völliger Programmieranfänger hat mich die Programmerstellung nur etwa zwei Wochen gekostet – dem Spott der Kollegen zum Trotz, ich würde nach zehn Jahren noch basteln. Der PC sendete zu Beginn einer Messung die Methode an das Gerät, ein UV/VIS/NIR-Spektrometer, und bekam die Daten noch während der Messung mit abschließendem Handshake zurück. Das Programm absolvierte die Messungen der Probe, der Blindwerte und der Referenzspektren. Mehr war nicht nötig. Ich konnte mich auf die experimentelle Arbeit konzentrieren.

Meine weiteren Geräterfahrungen konnte ich an VARIAN-NMR-Spektrometern sammeln. Zum einen hatte sich die Wahl von UNIX/Linux als Betriebssystemplattform bewährt: Erstens weit genug weg von der Haus-IT, zweitens sicher und drittens genügsam mit Rechnerhardware. Die Skriptsprache „MAGICAL“, vollumfänglich auf nur 25 Seiten Manual beschrieben [2], erlaubte eine sehr einfache Automatisierung von Messabläufen, Zwischenberechnungen, graphischen Darstellungen und Datenhandhabung – eine Aneinanderreihung von Konsolen- und UNIX-Befehlen. Diese Makros laufen auch zwanzig Jahre später noch.

Noch ein letztes gutes Beispiel, und wieder von einem NIR-Spektrometer: Die Software ist in zwei Versionen verfügbar, einmal als graphische Benutzeroberfläche (Graphical User Interface, GUI) zur Entwicklung der Methoden und Datenanalysen, einmal als Laufzeitumgebung (Dynamic Link Library, DLL) mit geringerem Speicherbedarf und schnellerer Performance. Die DLL konnte (und kann) auf einem virtuellen Rechnercluster ausgeführt werden, so dass der Labor-Rechner entfiel. Damit konnten stark vereinfachte Benutzeroberflächen mit sehr geringen Anforderungen an die Bediener eingesetzt werden, etwa auf Basis von Scriptsprachen (damals Visual Basic oder VB.net).

Drei Dinge braucht der Mensch

Warum sind diese Beispiele erwähnenswert? Weil sie intuitiv sind – alle Geräteeinstellungen systematisch verfügbar, wie mit Knöpfchen, alle wesentlichen Einstellungen auf das nötige Maß beschränkt. Weil sie modular sind – Methode hin, Daten zurück, Datenauswertung im Programm der Wahl, mit offenen Standards. Und weil sie Hardware-abstrahiert sind – Methodenentwicklung und Methodenausführung laufen auf beliebigen Hard- und Softwaresockeln und sogar virtuell.

Weniger ist mehr.

Die IT bietet immer besser und schneller werdende Rechnerhardware und Displaytechnologie und damit zunehmend mehr Möglichkeiten für eine Benutzerführung. Die anfangs revolutionäre Menüführung („Windows“) verleitet heute eher zum Verstecken von Funktionen. Ich erlebte, dass manche Geräteeinstellungen gar nicht mehr im Menü aufrufbar sind, sondern nur im Moment der Speicherung einer neuen Methode kurzzeitig auf dem Bildschirm erscheinen und nur hier verändert werden können. In einem nur halbwegs komplexen Labor mit einigen Laborgeräten verliert man da schnell den Überblick und die Kontrolle.

full-screen

Abb. 2 Visualisierungsbeispiel mit Node-RED zur Darstellung von LED-Sensoren, Füllständen und eines Vibrationssensors. Node-RED ist ein Programmierwerkzeug, mit dem Hardware-Geräte, APIs und Online-Dienste auf neue und interessante Weise miteinander verbunden werden können. Screenshot BAM: https://nodered.org

Die Digitalisierung verspricht eine Verbesserung der Mensch-Maschine-Schnittstelle. Gut programmierte Apps fußen auf intuitiven und überschaubaren graphischen Benutzeroberflächen und verzichten so auf das Abarbeiten endloser Menüs (siehe Visualisierungsbeispiel mit Node-RED, Abb. 2). Man bekommt immer nur eine oder wenige Auswahlmöglichkeiten auf einmal. So wird es allein auf Basis der Informationsbeschränkung intuitiv, auch ohne Standardisierung. Das begründet den Erfolg der vielen Privat-Apps. Standardisierung wäre eine andere Möglichkeit, dort wo es einfach komplex bleiben muss.

Einstecken – fertig.

An dieser Stelle lohnt sich ein Blick in die Automationstechnik der Prozessindustrie: Wie im Labor ist auch die Ausstattung der Automatisierungslandschaft historisch gewachsen und hinsichtlich der Vielfalt der Feldgeräte (Sensoren und Aktoren), Schnittstellen und proprietären Formate sehr vergleichbar. Zusammen mit einer vereinfachten Gerätekommunikation (s. unten) wird der Standard „Module Type Package“ MTP vorangebracht [3]. Es beinhaltet eine herstellerneutrale, funktionale Beschreibung der Automatisierung von Prozessmodulen beispielsweise zur Integration in Prozessleitsysteme. Der Standard wurde entwickelt, um komplexe, ins sich geschlossene Einheiten (Module) mit einfachem Drag and Drop in eine Automatisierungsumgebung einzubinden, z.B. in ein Prozessleitsystem. Die MTP-Datei beinhaltet nicht nur die Belegung der Schnittstelle, sondern auch die Parametrierung bzw. Kalibrierung des Moduls. Auch Arbeitsabläufe (Workflows) oder Messmethoden lassen sich übertragen, zusammen mit den notwendigen Benutzerrollen und -hierarchien. Schließlich können bei der Einbindung alle weiteren notwendigen Informationen automatisch übergeben werden, wie Schalt- und Bedienbilder, Bedienungs-, Wartungs- und Reparaturanleitungen bzw. -videos oder Zertifikate, und es wird auch ein Kanal für den Datentransfer eröffnet. MTP kapselt alle für den Anwender komplexen Einstellungen, obwohl die Funktionen darunter eher komplexer geworden sind als am Beispiel des UV/VIS/NIR-Spektrometers eingangs dargestellt.

Als eine mögliche Ausprägung von Industrie 4.0 werden im Zuge der digitalen Transformation der Prozessindustrie auch Produktionskonzepte abgeleitet, und zwar für die sogenannte modulare Produktion [4], von denen das Labor auch profitieren kann. Mit einer Modularisierung von Produktionsanlagen nimmt die Flexibilität, Verfügbarkeit und Auslastung von Anlagen zu, weil sich Module, wie etwa Dosier-, Reaktions- oder Qualitätskontrollmodule, mit schnellen Rüstzeiten optimal für ein Produkt zu neuen Anlagen rekonfigurieren lassen. Unterschiedliche Produkte lassen sich dann viel schneller auf den Markt bringen, da die Anforderungen des Kunden nach schneller Verfügbarkeit neuer Spezialprodukte immer weiterwachsen. Das Modulkonzept verringert durch Kapselung der verfahrenstechnischen Funktionen die Komplexität. Die Komplexität der Produktion bleibt erhalten oder kann sogar zunehmen, wird jedoch auf das Innere des Moduls beschränkt.

Anfassen geht nicht.

Im Geschäftsbereich sind virtualisierte Softwareanwendungen und Betriebssysteme schon lange im Einsatz, insbesondere bei Servern. Dabei wird eine Virtualisierungsschicht zwischen der physischen Hardware, wie Bürocomputer, Rechnercluster im Rechenzentrum, etc. und ihren logischen Komponenten gelegt, also Betriebssystem oder Applikation, so dass die logischen Teile nicht mehr abhängig von der Hardware sind. Man spricht von virtuellen Maschinen. Auf diese Weise läuft Software nicht mehr lokal auf einem Rechner, sondern verteilt auf Rechnerverbünden – auch über das Internet als sogenannte Virtual Appliances verteilt. Sie kann nicht mehr abstürzen oder abbrennen [5].

Wesentliche Vorteile sind der Einsatz von Templates oder das schnelle Klonen von virtualisierten Anwendungen. Damit werden neue Backup-Möglichkeiten unter Einhaltung von Compliance-Richtlinien ermöglicht. Die Wiederherstellung der Gast-Betriebssysteme wird erheblich erleichtert und vereinfacht. Nach einem Softwarepatch oder einer Firmware-Erneuerung können erst einmal Funktionstests erfolgen, um die Validität eines Systems zu testen. Ein validierter Zustand jedes virtuellen Systems kann durch Wiedereinspielen der letzten validierten Version in wenigen Minuten wiederhergestellt werden, sollte dieses einmal notwendig sein. Für heutige Laborgeräte-Rechner wäre das nie möglich, ohne ein System komplett neu aufzusetzen und wieder auf den letzten validierten Zustand aufzurüsten. Virtualisierung ist daher eine sehr einfache Möglichkeit, auch im GMP-Umfeld Compliance zu bewahren. Auch besteht die Möglichkeit ein paralleles Testsystem zur Entwicklung, Simulationen, Schulung oder ähnlichem temporär mitlaufen zu lassen oder validierte Systeme zu klonen. Übrigens können auch alte Betriebssysteme (relativ gut abgesichert in der Cloud) weiterlaufen ­– gerne auch ein WIN 3.1. Das ist Investitionsschutz.

Fazit

Wir können uns durch den digitalen Wandel im Labor endlich wieder mehr Zeit für Kreativität gestalten. Diese Kreativität kommt den Menschen zugute, um Lösungen für komplexer werdende Anforderungen zu finden. Eine vereinfachte Einbindung und ein Zusammenspiel der Laborgeräte und der Infrastruktur wäre der erste Schritt. Intuitive Menüführungen erleichtern die Bedienung, ganz ohne Standards. Schließlich kann eine virtuelle Softwareumgebung laufende Systeme nachhaltig und sicher betreibbar machen und so auf lokale Rechnerhardware verzichten. Hier vollzieht sich gerade ein Wandel bei den Geräte- und Softwareherstellern, die offene Standards zunehmend wieder unterstützen. Offene Standards führen nicht zu Marktverlusten, sondern eröffnen neue Märkte und Raum für gemeinsame Weiterentwicklungen. Leuchtturmprojekte mit Anwendern können den Trend zur gemeinsamen „Sharingkultur“ stark beflügeln.

___________________________________________________________________________________________

Kategorie: Labormanagement | Smart Lab

Literatur:
[1] Historische Sammlung Beckman, Kasten 82. Wissenschaftsgeschichtliches Institut. Philadelphia. https://digital.sciencehistory.org/works/df65v7966
[2] MAGICAL (MAGnetics Instrument Control and Analysis Language), VNMR User Programming VNMR 6.1C Software, Varian, Palo Alto, CA, USA, 2000 – Nachfolge-Software https://openvnmrj.org/about/
[3] ZVEI - Zentralverband Elektrotechnik- und Elektronikindustrie e. V., White Paper „Modulbasierte Produktion in den Prozessindustrien – Auswirkungen auf die Automation, Empfehlungen des AK Modulare Automation zur NE 148 der Namur“, Februar 2015, https://www.zvei.org/presse-medien/publikationen/white-paper-modulbasierte-produktion-in-der-prozessindustrie/
[4] VDI/VDE/NAMUR-Richtlinie 2658 „Automatisierungstechnik von modularen Anlagen in der Prozessindustrie“, https://www.vdi.de/richtlinien?tx_vdiguidelines_guidelinelist%5Bfilter%5D%5BsearchTerm%5D=2658&cHash=210809745cf93c76cff6ec835851d5ed
[5] Maiwald, M., Voll integrierte und vernetzte Systeme und Prozesse - Perspektive: Smarte Sensorik, Aktorik und Kommunikation, ATP Magazin 60(10), 70–85, 2018, DOI: 10.17560/atp.v60i10.2376