Dies ist ein Pitch. Kein Whitepaper, kein Tutorial, kein fertiges Produkt. aiOS existiert als Architektur, als Vision und als konkreter Plan fuer ein Software-Engineering-Projekt an der Ruhr-Universitaet Bochum. Was folgt, ist die Argumentation, warum es gebaut werden sollte — und wie.
Das Problem in 30 Sekunden
Herner Strasse 299, Bochum-Riemke. Zweiter Stock, Halle B29. Ein KFZ-Meister klemmt Messkabel an einen Golf 7, startet die Zuendung. Auf dem Laptop erscheint eine Sinuswelle — 10.000 Datenpunkte pro Sekunde. Irgendwo in dieser Kurve steckt die Information, dass die Steuerkette in 3.000 Kilometern reissen wird.
Der Meister sieht die Kurve. Die Erkenntnis sieht er nicht.
Das Problem
Zwischen dem Messsignal und seiner Bedeutung fehlt eine ganze Softwareschicht. USB-Oszilloskope werden jedes Jahr praeziser und guenstiger. Die Software dahinter zeigt Kurven, speichert Dateien — und hoert dort auf, wo die eigentliche Arbeit beginnt.
Status Quo
Signale werden manuell interpretiert. Jede Diagnose haengt von der Erfahrung des einzelnen Mechanikers ab. Wissen ist nicht skalierbar, nicht reproduzierbar, nicht uebertragbar.
aiOS-These
Ein Betriebssystem zwischen Hardware und Mensch. Automatische Geraeteerkennung, Echtzeit-Analyse, KI-gestuetzte Anomalieerkennung, Berichte in Kundensprache. Open Source, erweiterbar, containerisiert.
Die Betriebssystem-Metapher
USB-Stick in den Laptop stecken. Das System erkennt das Geraet, mountet es, laesst dich Dateien oeffnen. Kein Gedanke noetig — zwischen physischer Hardware und menschlicher Wahrnehmung liegt ein Abstraktionsstapel, der Komplexitaet in Verstaendlichkeit uebersetzt.
Ersetze USB-Stick durch Oszilloskop. Ersetze Dateien durch Zeitreihensignale. Die Abstraktionsschicht dazwischen? Existiert nicht. Kein System erkennt automatisch, was angeschlossen wurde. Keines analysiert den Datenstrom in Echtzeit. Keines formuliert Ergebnisse so, dass ein Werkstattkunde sie versteht.
Der Pitch
aiOS baut diese fehlende Schicht — nicht als einzelnes Feature, sondern als Plattform. Vier Schichten, dieselbe architektonische Logik wie ein Betriebssystem: Hardware-Abstraktion unten, Systemdienste in der Mitte, Anwendungen oben.
Vier Schichten, ein Prinzip
Die Architektur ist bewusst simpel. Jede Schicht hat eine klar definierte Aufgabe. Keine Schicht kennt die Details der Schicht darunter — nur deren Interface.
Timing: Warum jetzt und nicht vor fuenf Jahren
Drei Technologien mussten gleichzeitig reif werden. Keine einzelne ist revolutionaer. Zusammen ergeben sie eine Plattform, die 2020 unmoeglich gewesen waere.
USB-Oszilloskope mit 24-Bit-Aufloesung kosten einen Bruchteil stationaerer Geraete von vor einem Jahrzehnt. LLMs generieren verstaendliche Texte in unter 100 Millisekunden. Docker-Container laufen lizenzfrei auf jedem Laptop. Das Fenster ist offen — die Frage ist nur, wer hindurchgeht.
Der Plan: Ein Semester, fuenf Sprints
Umsetzung
aiOS soll als Software-Engineering-Projekt am SE Lab der Ruhr-Universitaet Bochum entstehen. Fuenf Studierende, fuenf Sprints, ein Semester. Betreut vom Lehrstuhl unter Prof. Dr. Thorsten Berger, begleitet von der AI-Gruppe als Industriepartner.
Das SE Lab erzwingt Disziplin: Requirements-Dokumente, Architektur-Reviews, Teststrategien, Sprint-Reviews mit echtem Kundenfeedback. Die Docs-Seite mit Tutorials ist kein Nice-to-have — sie ist Liefergegenstand.
docker compose up startet alles — inkl. Docs.Tech Stack
Jede Entscheidung folgt einem Prinzip: bewaehrte Technologie, keine Vendor-Lock-ins, maximale Erweiterbarkeit.
Frontend
Angular 19 mit TypeScript. D3.js fuer Echtzeit-Signalvisualisierung. WebSocket-Client fuer Live-Streaming direkt im Browser.
Backend
FastAPI (Python 3.12+) mit Pydantic v2 fuer Schema-Validierung. Async WebSocket-Handler fuer tausende gleichzeitige Datenpunkte.
Daten
PostgreSQL 16 fuer strukturierte Persistenz. Redis 7 als Cache und PubSub-Broker. MinIO (S3-kompatibel) fuer Rohdaten-Blobs.
Infrastruktur
Docker Compose orchestriert alles. Jedes Plugin ein eigener Container. REST-API-Registrierung mit JSON-Schema I/O. Sandbox mit Timeout und Memory-Limit.
Die ehrliche Risiko-Matrix
Ein Pitch ohne Risiko-Analyse ist Werbung. aiOS hat drei bekannte Schwachstellen — und fuer jede einen Mitigationsplan.
Hardware-Abhaengigkeit
MittelaiOS ist nur so gut wie die Geraete, die Daten liefern. Mitigation: Adapter-Pattern entkoppelt die Plattform von einzelnen Herstellern. Aber die Adapter muessen geschrieben werden — das kostet Aufwand pro Geraetetyp.
KI-Halluzinationen
HochEin LLM mit falschem Befund ist schlimmer als kein LLM. Mitigation: Konfidenz-Scores auf jedem Report, Warnhinweise bei niedriger Sicherheit, menschliche Validierung als letzte Instanz. Kein Report ohne Review-Flag.
Community-Paradox
MittelEin Marktplatz ohne Plugins ist nutzlos, Plugins ohne Nutzer entstehen nicht. Mitigation: Das Kernteam liefert fuenf bis zehn Referenz-Plugins die sofort Mehrwert schaffen — bevor externe Contributor uebernehmen.
Warum Open Source
Diagnose-Wissen gehoert nicht in Silos. Jede Werkstattkette, die proprietaere Software verkauft, monopolisiert Erfahrung, die auf Jahrzehnte geteilter Praxis basiert. aiOS dreht diese Logik um.
Open Source als Strategie
Die beste Analyse-Methode fuer ein bestimmtes Symptom kommt vielleicht von jemandem, der heute noch in einer Vorlesung sitzt. Open Source macht genau das moeglich: Wissen fliesst dahin, wo es gebraucht wird — nicht dorthin, wo jemand eine Lizenz verkauft.
Die Architektur, die Plugin-Spezifikation, die Docs — alles offen. Lizenz: MIT. Fork-freundlich. Contribution-Guidelines ab Sprint 0.
aiOS entsteht offen
OmnAIView auf GitHub, SE Lab an der RUB, OmnAIScope-Hardware — alles verlinkt.
GitHub: OmnAIViewWeiterfuehrend
OmnAIView auf GitHub: github.com/omnai-project/OmnAIView
SE Lab, Ruhr-Universitaet Bochum: se.rub.de
OmnAIScope: omnaiscope.auto-intern.de