Echtzeit, Sicherheit, Leistung, Medizin-Box und Eisenbahn-Bild

Flexible Safety RTOS mit RustSafety-Software in Rust, mit Schutz zwischen Tasks und planbarem Echtzeitverhalten

Der zertifizierte Echtzeit-Kernel mit seinen Services kommt für Rust-Entwickler. Dieselben Vorteile wie für ANSI-C, im Zusammenspiel mit der Sprachsicherheit von Rust.

Q4 2026: nicht zertifizierter Stand verfügbar

Das Pilotprojekt erörtern

Was Rust-Entwickler bekommen

Die Services des Kernels stehen in Rust wie in ANSI-C zur Verfügung. Drei Vorteile stehen im Vordergrund.

Schutz pro Task

Einzelne Tasks sind gegeneinander geschützt. Der Kernel schützt jede Task vor Eingriffen anderer Tasks.

Schutz pro Taskgruppe

Zusammengehörige Tasks werden gemeinsam geschützt und lassen sich als Einheit gliedern.

Sprachsicherheit plus Isolation

Rust verhindert viele Fehler bereits beim Übersetzen. Der Kernel begrenzt die Auswirkungen eines Fehlers in einer Task auf diese Task.

Rust-native API: Der Compiler prüft, was das RTOS nicht prüfen kann

Die Flexible Safety RTOS-API ist auf das "Ownership-Modell" von Rust ausgelegt. Daten, die zwischen Tasks ausgetauscht werden, wechseln den Besitzer, sodass ein Absender das, was er gesendet hat, nicht weiter nutzen kann. Gemeinsame Ressourcen sind nur zugänglich, solange ein Task die Sperre hält. Viele Fehlerquellen scheitern bereits bei der Kompilierung und nicht erst im Einsatz, was weniger defensive Prüfungen und einen geringeren Überprüfungsaufwand für Eigentumsfehler bedeutet.

Eigentumsrechte an Nachrichten und Puffern

Wenn eine Aufgabe eine Nachricht über eine Warteschlange sendet, geht das Eigentumsrecht auf den Empfänger über. Der Absender kann die Daten nicht mehr lesen oder ändern. Der Compiler lehnt Code ab, der dies versucht.

Exklusiver Zugriff auf gemeinsam genutzte Ressourcen

Gemeinsam genutzte Daten können so gekapselt werden, dass sie nur über eine Sperre zugänglich sind. Der Compiler sorgt dafür, dass eine Task gemeinsam genutzte Daten nicht lesen kann, ohne die Sperre zu halten.

Prüfungen zur Kompilierungszeit an der API-Grenze

Eine unsachgemäße Verwendung von Task-Erstellung, Ressourcen-Handles oder Zeitparametern kann bereits während der Erstellung zu Fehlern führen, anstatt erst im Einsatz.

Weniger Laufzeitprüfungen und weniger defensiver Code

Die Teams wenden weniger Aufwand für die Überprüfung von Eigentumsfehlern auf, was die Safety-Analyse unterstützt.

Eindeutige Fehlerbehandlung

Der „Result“-Typ von Rust macht die Fehlerpfade im RTOS explizit, sodass kein Rückgabecode versehentlich ignoriert wird.

Pilotkunde gesucht

Wir suchen einen Pilotkunden für das erste Rust-Projekt mit dem Flexible Safety RTOS. Der Pilot arbeitet mit dem Stand von Q4 2026. Wir begleiten das Projekt technisch und stellen direkten Kontakt zu unseren Entwicklern her.

Technische Begleitung durch unser Entwicklungsteam
Direkter Zugang zu unseren Entwicklern
Frühe Mitgestaltung des Rust-Supports

Roboter belädt Lastwagen mit den Blöcken Idee, Config, und Security

Zeitplan

Ein nicht zertifizierter Stand kommt vor der Zertifizierung. So können Entwickler früh evaluieren und mit ersten Projekten starten.

Q4 2026
Nicht zertifizierter Stand verfügbar. Geeignet für Evaluierung und erste Entwicklung.
Q1 2027
Start eines Pilotprojekts mit Kunden.
Q4 2027
Zertifizierung des Rust-Stands.

Note: Bis zur Zertifizierung gelten für Safety-Projekte andere Voraussetzungen als für den zertifizierten Stand. Den Einsatz stimmen wir früh gemeinsam ab.

Kontakt

Für ein technisches Scoping-Gespräch (30 bis 45 Minuten) klären wir Anwendungsfall, Hardware, Toolchain und Safety-Ziele.

Das Pilotprojekt erörtern

Home > Products > Flexible Safety RTOS > Rust