Wenn Laborgeräte zu vernetzten Systemen werden: Warum Softwarearchitektur über die Zukunftsfähigkeit entscheidet

Vom einzelnen Messgerät zum digitalen Gesamtsystem

Moderne Labortechnik besteht längst nicht mehr nur aus präzisen mechanischen und elektronischen Komponenten.

Laborgeräte erfassen Messwerte, steuern komplexe Prozesse, speichern Parameter und kommunizieren mit anderen Systemen. Anwender erwarten, dass sie Ergebnisse auf unterschiedlichen Endgeräten abrufen, Abläufe dokumentieren und Daten für weitere Auswertungen bereitstellen können.

Ein Beispiel für diese Entwicklung ist die BÜCHI Labortechnik AG, die neben Laborinstrumenten auch Anwendungen für Android, Windows und iOS sowie cloudbasierte Dienste anbietet.

Damit entsteht eine spannende Herausforderung:

Wie entwickelt man Software, die über viele Jahre wartbar bleibt, neue Geräte integrieren kann und gleichzeitig zuverlässig, sicher und nachvollziehbar arbeitet?

Die Antwort liegt nicht allein in der Wahl einer Programmiersprache, sondern vor allem in einer durchdachten Softwarearchitektur.

1. Die eigentliche Herausforderung liegt zwischen den Systemen

Betrachten wir ein typisches Szenario aus der Laborautomation.

Ein Laborgerät führt einen Prozess aus. Dabei entstehen Messwerte, Gerätezustände und Ereignisse. Diese Informationen werden an eine Anwendung übertragen, in einer Datenbank gespeichert, visualisiert und möglicherweise an übergeordnete Systeme weitergegeben.

Daraus ergeben sich mehrere Anforderungen:

• Die Kommunikation mit dem Gerät muss zuverlässig funktionieren.
• Messwerte benötigen einen eindeutigen Bezug zu einem Prozess, einer Probe oder einem Auftrag.
• Ausfälle der Netzwerkverbindung dürfen nicht unbemerkt zu Datenverlust führen.
• Die Benutzeroberfläche soll auch bei komplexen Abläufen verständlich bleiben.
• Softwareaktualisierungen müssen möglich sein, ohne bestehende Funktionen unkontrolliert zu verändern.
• Zugriffe, Konfigurationen und Prozessänderungen müssen angemessen abgesichert und nachvollziehbar sein.

Gerade die Kombination aus Hardware, Software und langlebigen Produkten macht die Architektur anspruchsvoll.

2. Domain-Driven Design: Erst den Prozess verstehen

Bei industriellen Anwendungen beginnt gute Softwareentwicklung mit dem Verständnis der Fachdomäne.

Was ist ein Messvorgang? Was unterscheidet einen Prozessschritt von einem Gerätezustand? Wann gilt eine Messung als abgeschlossen? Welche Informationen müssen unveränderbar erhalten bleiben?

Domain-Driven Design (DDD) hilft dabei, solche fachlichen Zusammenhänge explizit zu modellieren.

Statt die Anwendung ausschliesslich um Datenbanktabellen und technische Schnittstellen herum aufzubauen, stehen fachliche Begriffe und Regeln im Mittelpunkt.

Das ist besonders wichtig, wenn Software über Jahre erweitert wird und unterschiedliche Teams daran arbeiten.

Ein fachlich verständliches Modell reduziert Missverständnisse zwischen Entwicklung, Produktmanagement und Anwendern.

3. Hexagonale Architektur: Geräte und Technologien austauschbar halten

In der Labortechnik ändern sich Technologien oft schneller als die fachlichen Prozesse.

Ein neues Gerät nutzt möglicherweise ein anderes Kommunikationsprotokoll. Eine Desktopanwendung wird um eine Weboberfläche ergänzt. Eine lokale Datenbank soll künftig mit Cloud-Diensten synchronisiert werden.

Hier bietet die hexagonale Architektur einen sinnvollen Ansatz.

Die zentrale Geschäftslogik wird von technischen Abhängigkeiten getrennt. Gerätekommunikation, Datenbanken, Benutzeroberflächen und externe Dienste werden über definierte Schnittstellen angebunden.

Dadurch lässt sich beispielsweise ein Gerät durch einen Simulator ersetzen, ohne die fachliche Logik zu verändern.

Das bringt konkrete Vorteile:

• Bessere automatisierte Testbarkeit
• Austauschbare technische Komponenten
• Klarere Verantwortlichkeiten
• Geringere Abhängigkeit von einzelnen Herstellern oder Technologien
• Einfachere schrittweise Modernisierung

Allerdings muss nicht jede Anwendung sofort in zahlreiche Dienste aufgeteilt werden.

Eine sauber strukturierte modulare Anwendung kann langfristig sinnvoller sein als eine unnötig komplexe Microservice-Architektur.

Entscheidend sind die tatsächlichen Anforderungen an Verfügbarkeit, Skalierung, Entwicklungsorganisation und Wartbarkeit.

4. .NET als Grundlage langlebiger Anwendungen

.NET und C# eignen sich für viele dieser Aufgaben, insbesondere dort, wo komplexe Geschäftslogik, APIs, Hintergrundverarbeitung und unterschiedliche Schnittstellen zusammenkommen.

Mit ASP.NET Core lassen sich beispielsweise Dienste entwickeln, die Messdaten entgegennehmen, validieren, verarbeiten und für andere Anwendungen bereitstellen.

Eine mögliche Architektur umfasst:

Geräteintegration: Adapter zur Kommunikation mit Laborgeräten und externen Systemen.

Anwendungslogik: Fachliche Regeln, Prozesssteuerung und Validierung.

Persistenz: Speicherung von Messdaten, Prozesshistorien und Konfigurationen.

APIs: Bereitstellung der Daten für Webanwendungen, mobile Anwendungen und Drittsysteme.

Monitoring und Security: Überwachung, Protokollierung, Zugriffskontrolle und Fehlerbehandlung.

Die Herausforderung besteht dabei weniger darin, diese Komponenten einzeln zu programmieren, sondern ihre Verantwortlichkeiten und Schnittstellen klar festzulegen.

5. Softwarequalität beginnt vor dem ersten Test

Je enger Software mit realen Prozessen verbunden ist, desto wichtiger werden nichtfunktionale Anforderungen.

Dazu gehören unter anderem:

• Zuverlässigkeit und Wiederherstellbarkeit
• Datenintegrität und Nachvollziehbarkeit
• Informationssicherheit
• Wartbarkeit und Erweiterbarkeit
• Definierte Reaktionen auf Fehler und Verbindungsabbrüche
• Reproduzierbare Builds und automatisierte Tests

Ein automatisierter Test sollte nicht nur prüfen, ob ein Messwert korrekt gespeichert wurde.

Er sollte beispielsweise auch überprüfen, was passiert, wenn derselbe Messwert erneut übertragen wird, eine Verbindung während eines Vorgangs abbricht oder eine Anwendung nach einem Neustart ihren Zustand wiederherstellen muss.

Solche Szenarien müssen bereits bei der Architektur berücksichtigt werden.

6. KI-Agenten verändern die Entwicklung, nicht die Verantwortung

KI-gestützte Entwicklungswerkzeuge können heute weit mehr als einzelne Codezeilen ergänzen.

Sie können bestehende Codebasen analysieren, Implementierungen vorbereiten, Tests generieren, Dokumentation erstellen und bei der Identifikation technischer Schulden unterstützen.

Gerade bei langlebiger industrieller Software eröffnet dies interessante Möglichkeiten.

Allerdings entsteht daraus eine neue Herausforderung: Wenn Software schneller erzeugt werden kann, muss ihre Qualität mindestens genauso systematisch überprüft werden.

Ein möglicher Ansatz besteht darin, Entwicklungsaufgaben mit klaren Architekturregeln, unabhängigen Prüfmechanismen, automatisierten Tests und definierten Abnahmekriterien zu verbinden.

Der KI-Agent übernimmt damit Teile der Umsetzung, während die Architektur die Leitplanken setzt.

KI beschleunigt die Entwicklung. Sie ersetzt jedoch weder ein belastbares fachliches Modell noch die Verantwortung für Sicherheit, Qualität und langfristige Wartbarkeit.

7. Technische Schulden sind eine Architekturentscheidung

Viele Softwareprobleme entstehen nicht durch eine einzelne falsche Entscheidung, sondern durch die Summe zahlreicher kurzfristiger Kompromisse.

Eine direkte Datenbankabfrage in der Benutzeroberfläche erscheint zunächst praktisch. Eine zusätzliche Sonderregel lässt sich schnell ergänzen. Eine Schnittstelle wird ohne klare Versionierung erweitert.

Mit der Zeit entstehen jedoch Abhängigkeiten, die jede weitere Änderung erschweren.

Deshalb gehört der bewusste Umgang mit technischen Schulden zu den zentralen Aufgaben der Softwarearchitektur.

Nicht jede technische Schuld muss sofort beseitigt werden. Sie sollte aber sichtbar, bewertbar und kontrollierbar sein.

Fazit: Architektur ist mehr als eine technische Zeichnung

Die Digitalisierung von Labor- und Produktionssystemen zeigt, wie wichtig das Zusammenspiel von Fachprozessen, Geräten, Daten und Anwendungen geworden ist.

Gute Softwarearchitektur bedeutet deshalb nicht, möglichst viele moderne Technologien einzusetzen.

Sie bedeutet, Systeme so zu gestalten, dass sie fachlich verständlich, technisch beherrschbar und langfristig erweiterbar bleiben.

Mit dem zunehmenden Einsatz von KI-Agenten wird diese Fähigkeit eher wichtiger als weniger wichtig.

Denn schneller erzeugter Code ist nur dann ein Fortschritt, wenn daraus auch bessere Software entsteht.

Weiterführende Quellen

• BÜCHI Labortechnik: Software und Apps
• BÜCHI Labortechnik: Produkte und Technologien
• Microsoft: Architecture Guide für .NET-Anwendungen
• Martin Fowler: Domain-Driven Design
• Alistair Cockburn: Hexagonal Architecture