Warum Rust die Zukunft der Gerätesteuerung für Laborgeräte ist

Warum Rust die Zukunft der Gerätesteuerung für Laborgeräte ist

Gerätesteuerung für Laborgeräte mit Rust ist kein hypothetisches Szenario – sie findet bereits statt. Im Januar 2025 wurde Ferrocene als erste Rust-Toolchain nach IEC 62304 Klasse C für Medizinprodukte-Software qualifiziert und räumte damit die letzte grosse regulatorische Hürde für sicherheitskritische Anwendungen in den Life Sciences aus dem Weg. Nach Jahren, in denen ich die Gerätesteuerung für die Plattform eines grossen IVD-Unternehmens in C++ entwickelt habe, kann ich mit Überzeugung sagen: Rust ist für jedes neue Projekt zur Gerätesteuerung der bessere Weg nach vorn.

Das C++-Problem bei Laborgeräten

C++ ist seit Jahrzehnten die Standardsprache für die Firmware von Laborgeräten. Die Sprache ist schnell, flexibel, und jede Ingenieurin und jeder Ingenieur im Gerätebereich kennt sie. Sie hat jedoch einen grundlegenden Mangel, den keine Programmierrichtlinien, statischen Analysewerkzeuge oder Code-Reviews vollständig beseitigen können: fehlende Speichersicherheit.

Microsoft und Google haben unabhängig voneinander bestätigt, dass rund 70 % ihrer Sicherheitslücken auf Speichersicherheitsprobleme zurückgehen – Pufferüberläufe, Use-after-free-Fehler, hängende Zeiger (Dangling Pointers) und Data Races. Dieselbe Fehlerklasse plagt auch Software zur Gerätesteuerung, doch die Folgen sind andere. Ein Browserabsturz ist ein Ärgernis. Ein Liquid-Handling-System, das wegen einer Race Condition im Thread der Motorsteuerung das falsche Volumen dispensiert, kann monatelang erhobene Daten aus klinischen Studien unbrauchbar machen.

In regulierten Umgebungen, die IEC 62304 und FDA 21 CFR Part 11 unterliegen, erfordert jeder Speichersicherheitsfehler eine Ursachenanalyse, eine CAPA und möglicherweise eine Korrekturmassnahme im Feld. Die Kosten eines einzigen Use-after-free-Fehlers in produktiver Geräte-Firmware bemessen sich in Hunderttausenden von Dollar und monatelangen regulatorischen Verzögerungen.

Was C++ Ihnen bietet

• Abstraktionen ohne Laufzeitkosten (Zero-Cost Abstractions) und deterministische Leistung
• Ein über Jahrzehnte gewachsenes Bibliotheks-Ökosystem für wissenschaftliches Rechnen
• Ingenieurinnen und Ingenieure, die die Sprache tiefgehend beherrschen
• Ausgereifte Toolchains und Debugger für jede Zielplattform

Was C++ Sie kostet

• Manuelle Speicherverwaltung, bei der jede Allokation ein potenzieller Fehler ist
• Data Races, die nur unter bestimmten zeitlichen Bedingungen im Produktivbetrieb auftreten
• Undefiniertes Verhalten, um das Compiler stillschweigend herumoptimieren
• Statische Analysewerkzeuge, die nur 30–40 % der Speichersicherheitsprobleme erkennen
• MISRA-Konformitätsaufwand, der die Entwicklung verlangsamt, ohne Sicherheit zu garantieren

Warum Rust die Ausgangslage für die Gerätesteuerung von Laborgeräten verändert

Rust bietet dieselben Zero-Cost Abstractions und dieselbe deterministische Leistung wie C++ – es wird zu nativem Maschinencode kompiliert und hat keinen Garbage Collector. Es fügt aber etwas hinzu, das C++ grundsätzlich nicht leisten kann: Garantien für Speicher- und Threadsicherheit zur Kompilierzeit durch das Ownership-System.

Speichersicherheit ohne Laufzeitkosten

Der Borrow Checker von Rust stellt zur Kompilierzeit sicher, dass:

• jeder Wert genau einen Eigentümer (Owner) hat
• Referenzen nicht länger leben als die Daten, auf die sie verweisen
• veränderlicher Zugriff exklusiv ist – kein Aliasing veränderlicher Daten

Damit werden ganze Fehlerkategorien – Use-after-free, Double-free, Pufferüberläufe, Data Races – beseitigt, bevor der Code überhaupt ausgeführt wird. Ein Firmware-Ingenieur, der an einem sicherheitskritischen Software-Stack für Medizinrobotik arbeitet, berichtete, dass «90 % dessen, was die Stack-Analyse prüfen musste, einfach vom Compiler erledigt wird».

Furchtlose Nebenläufigkeit für Echtzeitsysteme

Laborgeräte sind von Natur aus nebenläufig. Ein typisches Liquid-Handling-System führt Folgendes aus:

• Regelkreise für die Bewegungssteuerung mit 1–10 kHz
• PID-Regler für die Temperaturregelung
• Drucküberwachung für Aspiration und Dispensierung
• Kommunikation mit der Host-Software über USB oder Ethernet
• Überwachung der Sicherheitsverriegelungen

In C++ erfordert die Koordination dieser Threads eine sorgfältige manuelle Synchronisation mit Mutexen, Bedingungsvariablen und atomaren Operationen. Machen Sie dabei einen Fehler, entsteht ein Data Race, der nur bei einem von 10'000 Durchläufen auftritt – genau die Art von Fehler, die die Qualifizierungstests besteht, aber im Feld versagt.

Rust macht Data Races zu einem Kompilierfehler. Das Typsystem verfolgt, welche Daten zwischen Threads geteilt werden, und erzwingt sichere Zugriffsmuster. Das ist kein Lint und keine Best Practice – es ist eine harte Garantie des Compilers.

use std::sync::Arc;
use std::sync::Mutex;

struct MotionController {
    position: f64,
    velocity: f64,
    target: f64,
}

// The compiler enforces that MotionController is only accessed
// through the Mutex - no accidental unsynchronized reads
fn control_loop(controller: Arc<Mutex<MotionController>>) {
    loop {
        let mut ctrl = controller.lock().unwrap();
        let error = ctrl.target - ctrl.position;
        ctrl.velocity = error * 0.1; // P controller
        ctrl.position += ctrl.velocity * 0.001; // 1kHz update
        // Mutex automatically released here - no forgotten unlocks
    }
}

Leistungsbenchmarks – Rust ist C++ ebenbürtig

Eine Studie von KDAB aus dem Jahr 2026 ergab, dass 98 % der Multithread-Anwendungen in Rust beim Testen keine Race Conditions aufwiesen, verglichen mit 35 % bei C++. Beim reinen Durchsatz sind Rust und C++ praktisch gleichwertig – beide werden mit demselben LLVM-Backend zu nativem Code kompiliert.

Für Embedded-KI-Workloads, die in modernen Geräten immer häufiger vorkommen, zeigen Benchmarks der Rust Embedded AI Working Group, dass Rust-basierte Systeme bis zu 12 Millionen Sensorereignisse pro Sekunde mit einer Latenz von unter 50 Mikrosekunden verarbeiten. Das ist der Leistungsrahmen, der für die Echtzeit-Gerätesteuerung erforderlich ist.

Regulatorische Konformität – der Durchbruch mit Ferrocene

Der grösste Einwand gegen Rust in regulierten Umgebungen war schon immer die Qualifizierung der Toolchain. «Wir können Rust nicht verwenden, weil wir den Compiler nicht zertifizieren können» war bis Januar 2025 ein berechtigtes Argument.

Ferrocene, entwickelt von der Berliner Firma Ferrous Systems, ist die erste Rust-Compiler-Toolchain, die qualifiziert ist nach:

• IEC 62304 Klasse C – der höchsten Sicherheitsklasse für Medizinprodukte-Software
• ISO 26262 ASIL D – der höchsten Sicherheitsintegritätsstufe im Automobilbereich
• IEC 61508 SIL 4 – der höchsten Sicherheitsintegritätsstufe im industriellen Bereich

Die Toolchain unterstützt x86-64 Linux und Armv8-A Bare Metal sowie QNX Neutrino – und deckt damit die wichtigsten Plattformen moderner Laborgeräte ab. Der Quellcode und die vollständigen Qualifizierungsdokumente sind unter MIT-/Apache-2.0-Lizenzen als Open Source verfügbar.

Es handelt sich weder um einen Prototyp noch um einen Punkt auf einer Roadmap. Es ist eine für den Produktiveinsatz qualifizierte Toolchain, die dieselben Standards erfüllt wie die C/C++-Compiler, auf die sich Labore seit Jahrzehnten verlassen.

CISA treibt die Branche voran

Der regulatorische Druck reicht über die Normen für Medizinprodukte hinaus. CISA setzte Organisationen eine Frist bis zum 1. Januar 2026, um eine Roadmap zur Speichersicherheit zu veröffentlichen, und empfahl ausdrücklich die Migration von C und C++ zu speichersicheren Sprachen wie Rust. Für Hersteller von IVD- und Medizinprodukten ist dies ein Signal, dass sich die Regulierungsbehörden darauf zubewegen, speichersichere Sprachen vorzuschreiben – und nicht nur zu empfehlen.

Rust im wissenschaftlichen Rechnen – reale Verbreitung

Rust gewinnt nicht nur in der Theorie an Bedeutung. Die Community des wissenschaftlichen Rechnens baut produktive Infrastruktur auf:

Deimos – eine Open-Source-Plattform für wissenschaftliche Datenerfassung und Laborsteuerungen, deren Software und Firmware vollständig in Rust geschrieben sind. Sie kombiniert Präzisionsmesshardware mit Zeitsynchronisation im Sub-Mikrosekundenbereich, adaptiver Filterung und Echtzeit-Berechnungspipelines. Ihre Bibliothek InterpN führt hochperformante N-dimensionale Interpolation ohne Heap-Allokation durch – entscheidend für eingebettete Gerätesteuerungen.

SciRS2 – ein reines Rust-Framework für wissenschaftliches Rechnen, das im März 2026 Version v0.3.1 erreichte, mit über 19'700 Tests in 29 Workspace-Crates für numerisches Rechnen, Signalverarbeitung und maschinelles Lernen.

Der Workshop Scientific Computing in Rust 2025 bot Vorträge zu Themen von Monte-Carlo-Simulationen in der Quantenfeldtheorie bis hin zu beschleunigtem Rechnen – ein Beleg dafür, dass das wissenschaftliche Ökosystem von Rust rasch reift.

Die Verbreitung von Embedded Rust beschleunigt sich

Der Anteil von Rust an produktiven Embedded-Systemen ist 2025 auf rund 4,7 % gestiegen, gegenüber 2,1 % im Jahr 2023. Diese Entwicklung ist bedeutsam. Volvo liefert Rust-basierte ECU-Software im XC90 und im Polestar 3 aus. Espressif Systems hat eigene Teams, die Rust-Tooling für ESP32-Mikrocontroller entwickeln. ARM, Samsung und mehrere IoT-Hersteller verwenden Rust für Firmware.

Das Muster ist branchenübergreifend einheitlich: Teams führen Rust zunächst an den Systemrändern ein – Parser, Kommunikations-Stacks, Geräteschnittstellen – und dringen dann mit wachsendem Vertrauen tiefer in die Steuerungslogik vor. Genau dieser Einführungspfad ist für die Firmware von Laborgeräten sinnvoll.

Das Argument der Entwicklererfahrung

Ein Sprachwechsel ist teuer. Die Frage ist, ob sich die Investition auszahlt.

Nach der Arbeit mit C++ und Rust in Projekten zur Gerätesteuerung ist das Produktivitätsargument eindeutig:

Der Debugging-Aufwand sinkt drastisch. Die Fehler, die in C++-Geräte-Firmware die meisten Ingenieursstunden verschlingen – sporadische Abstürze, Speicherkorruption, Race Conditions –, lassen sich in Rust schlicht nicht kompilieren. Ein Firmware-Team eines Unternehmens für Medizinrobotik berichtete, dass Rusts «einheitlich akzeptierte Art der Fehlerbehandlung, die im gesamten Ökosystem verwendet wird» eine Konsistenz bietet, die bei Produkten mit einer Lebensdauer von 15–20 Jahren besser skaliert als manuelle Code-Reviews.

Der Compiler ist Ihr Reviewer. Die Fehlermeldungen von Rust sind bekanntermassen hilfreich. Wenn der Borrow Checker Ihren Code ablehnt, erklärt er Ihnen genau, warum, und schlägt oft eine Korrektur vor. Das ist eine ganz andere Erfahrung als undefiniertes Verhalten in C++, bei dem der Compiler fehlerhaften Code stillschweigend akzeptiert und Sie den Fehler drei Monate später im Labor eines Kunden entdecken.

Cargo ist ein Kraftverstärker. Das Abhängigkeitsmanagement in C++ ist nach wie vor ein zersplittertes Durcheinander aus CMake, Conan, vcpkg und manuellem Vendoring. Cargo bietet in Rust vom ersten Tag an einheitliche Builds, Abhängigkeitsmanagement, Tests und Dokumentation. Für Firmware-Teams im Gerätebereich, die Wochen mit dem Einrichten von Cross-Compilation-Toolchains verbringen, ist das von Bedeutung.

Die Lernkurve ist real, aber vorgelagert. Rust ist schwieriger zu erlernen als C++. Der Borrow Checker wird Sie in den ersten Wochen frustrieren. Doch die Schwierigkeit fällt zu Beginn an – sobald Sie die Ownership-Semantik verinnerlicht haben, fängt der Compiler Ihre Fehler ab, statt dass Ihre Kunden sie finden.

Wie QPillars Software zur Gerätesteuerung angeht

Bei QPillars entwickeln wir intelligente Software-Infrastruktur für Labore – einschliesslich Gerätesteuerungsschichten, die physische Hardware mit KI-gestützter Automatisierung verbinden. Unsere Architektur trennt die Echtzeit-Steuerungsebene von der Anwendungsebene und verwendet das MCP-Protokoll für die Kommunikation von KI-Agenten.

Rust fügt sich nahtlos in diese Architektur ein. Die Steuerungsebene erfordert genau die Eigenschaften, die Rust bietet: deterministische Leistung, Speichersicherheit und furchtlose Nebenläufigkeit. Die Anwendungsebene kann in höheren Programmiersprachen wie TypeScript oder Python verbleiben, wo die Entwicklungsgeschwindigkeit wichtiger ist als Steuerung im Mikrosekundenbereich.

Es geht nicht darum, alles in Rust neu zu schreiben. Es geht darum, auf jeder Ebene des Stacks das richtige Werkzeug einzusetzen – und für die sicherheitskritische Gerätesteuerung ist Rust zunehmend das richtige Werkzeug.

Häufig gestellte Fragen

Ist Rust schnell genug für die Echtzeit-Gerätesteuerung von Laborgeräten?

Ja. Rust wird über dasselbe LLVM-Backend wie C++ zu nativem Maschinencode kompiliert und hat keinen Garbage Collector, wodurch es sich für harte Echtzeit-Regelkreise eignet. Benchmarks zeigen, dass Rust beim reinen Durchsatz mit C++ gleichzieht und zugleich eine deterministische Ausführung bietet – entscheidend für Bewegungssteuerung, Flüssigkeitshandhabung und Sensorerfassung mit Raten im Kilohertzbereich.

Kann Rust in FDA-regulierter Medizinprodukte-Software eingesetzt werden?

Ja. Seit Januar 2025 ist die Rust-Toolchain Ferrocene nach IEC 62304 Klasse C qualifiziert – der höchsten Sicherheitsklassifizierung für Medizinprodukte-Software. Sie verfügt zudem über Qualifizierungen nach ISO 26262 ASIL D und IEC 61508 SIL 4. Damit entfällt die wichtigste regulatorische Hürde für den Einsatz von Rust in FDA-regulierten Umgebungen.

Wie geht die Gerätesteuerung für Laborgeräte mit Rust im Vergleich zu C++ mit Nebenläufigkeit um?

Das Ownership-System von Rust macht Data Races zu einem Kompilierfehler statt zu einem Laufzeitfehler. In C++ hängt die Threadsicherheit von korrekter manueller Synchronisation ab. Eine KDAB-Studie aus dem Jahr 2026 ergab, dass 98 % der Multithread-Anwendungen in Rust beim Testen keine Race Conditions aufwiesen, gegenüber 35 % bei C++. Für Geräte-Firmware, die nebenläufige Regelkreise, Sensorüberwachung und Kommunikationsaufgaben ausführt, ist diese Garantie bahnbrechend.

Wie steil ist die Lernkurve für C++-Ingenieure, die auf Rust umsteigen?

Die Lernkurve ist vorgelagert. Die meisten C++-Ingenieure berichten von 2–4 Wochen Reibung mit dem Borrow Checker, bevor sie produktiv werden. Die konzeptionelle Überschneidung – RAII, Zero-Cost Abstractions, kein GC, Kontrolle auf Systemebene – ist beträchtlich. Die wichtigste Umstellung besteht darin, die Ownership- und Lifetime-Semantik zu verinnerlichen, was bessere Entwurfsmuster erzwingt, die sich langfristig auszahlen.

Gibt es Rust-Bibliotheken für wissenschaftliches Rechnen und Laboranwendungen?

Das Ökosystem wächst rasch. Deimos bietet eine vollständige Open-Source-Plattform für wissenschaftliche Datenerfassung und Laborsteuerungen in Rust. SciRS2 umfasst 29 Crates für numerisches Rechnen, Signalverarbeitung und maschinelles Lernen mit über 19'700 Tests. Das Ökosystem rund um embedded-hal stellt Hardware-Abstraktionsschichten für Mikrocontroller bereit, die häufig in Geräte-Firmware eingesetzt werden.

Die wichtigsten Erkenntnisse

• Rust bietet die Leistung von C++ mit Garantien für Speicher- und Threadsicherheit zur Kompilierzeit – und beseitigt damit die Fehlerklasse, die für 70 % der Sicherheitslücken in C/C++-Systemen verantwortlich ist.
• Die Toolchain Ferrocene erhielt im Januar 2025 die Qualifizierung nach IEC 62304 Klasse C und beseitigte damit die letzte grosse regulatorische Hürde für Rust in der Firmware von Medizinprodukten und IVD-Geräten.
• Echtzeitsysteme in Rust verarbeiten über 12 Millionen Sensorereignisse pro Sekunde bei einer Latenz von unter 50 Mikrosekunden – und erfüllen damit die Leistungsanforderungen von Regelkreisen in der Gerätesteuerung von Laborgeräten.
• Produktive Plattformen wie Deimos liefern bereits Rust-basierte wissenschaftliche Datenerfassung und Laborsteuerungen mit Zeitsynchronisation im Sub-Mikrosekundenbereich.
• Die Entwicklung der Branche ist eindeutig: CISA schreibt Roadmaps zur Speichersicherheit vor, die Verbreitung von Embedded Rust hat sich innerhalb von zwei Jahren von 2,1 % auf 4,7 % verdoppelt, und Start-ups, die neue Geräte entwickeln, setzen vom ersten Tag an auf Rust.

---

Verfasst von Iacob Marian, Technischer Leiter und Mitgründer bei QPillars. Veröffentlicht am 2026-03-18.