Nebenläufigkeit, textbasierte DSLs und Soft-Roboter

Jedes Embedded-Projekt stößt irgendwann an dieselbe Grenze: Nebenläufigkeit. Ein Motor muss weiterlaufen, während ein Sicherheitsmonitor die Sensoren überwacht, ein Kommunikationsstack dem Host antwortet und ein Timer eine automatische Aktion auslöst. Sobald zwei dieser Komponenten interagieren, füllt sich der Code mit Threads, Mutexen, Bedingungsvariablen – und einer Klasse von Fehlern, die nur alle paar tausend Betriebsstunden auftreten.

Es gibt zwei bekannte Auswege. Die erste Möglichkeit besteht darin, den gesamten Steuerungscode manuell zu schreiben – und ich habe bereits argumentiert, warum das nicht skalierbar ist. Die zweite Möglichkeit ist, das gesamte Problem einer Code-generierenden KI zu überlassen – und ich habe bereits argumentiert, warum das für produktive eingebettete Systeme ebenfalls nicht akzeptabel ist.

Dieser Beitrag befasst sich mit dem dritten Weg: die Beschreibung des Verhaltens in einer textbasierten domänenspezifischen Sprache (DSL) und die Überlassung der mechanischen Arbeit einem deterministischen Generator. Ich nenne diese Art von Werkzeug einen Soft-Roboter – und die Beziehung, die er zum Entwickler eingeht, ist weder manuelle Arbeit noch blinde Delegation. Es ist Co-Entwicklung.

Warum eine textbasierte DSL den Prozess verändert

Der offensichtliche Vorteil einer DSL ist die Abstraktion. Der weniger offensichtliche – und im Arbeitsalltag weitaus wertvollere – Vorteil ist, dass das Modell reiner Text ist.

Eine .umt-Datei wird in Git wie jede andere Quelldatei behandelt. Sie lässt sich sauber vergleichen: Fügt ein Kollege eine Transition hinzu, zeigt der Pull Request genau eine hinzugefügte Zeile an, nicht zweihundert Zeilen neu generierter switch-Blöcke. Sie lässt sich problemlos mergen, durchsuchen und übersteht jeden Editor und jede CI-Pipeline. Ein grafisches Modellierungstool mit Binär- oder XML-Speicher bietet all dies nicht; die Unterschiede zwischen zwei XMI-Dateien sind keine Designprüfung, sondern lediglich irrelevant.

Text bedeutet auch, dass das Modell die einzige Quelle der Wahrheit für Mensch und Maschine zugleich ist. Ein Reviewer liest das Verhalten direkt. Der Generator liest dieselbe Datei und erzeugt die Implementierung. Dokumentation, Review-Artefakt und Build-Input sind identisch – nichts kann sich verschieben, da es keine separate Komponente gibt, die sich verschieben könnte.

Deklaration von Parallelität statt Implementierung

UMTSM basiert auf UML-Zustandsautomaten 2.5 und unterstützt den vollen Funktionsumfang – einschließlich derer, die Parallelität deklarativ machen: orthogonale Regionen, Fork/Join-Synchronisierung, do-Aktivitäten mit Abschlussereignissen und tiefe/flache/persistente Historie.

Das verändert die Bedeutung von „parallelem Code schreiben“. Anstatt Parallelität zu implementieren, deklarieren Sie sie:

sm Conveyor
{
    state Running
    {
        region Motion
        {
            init -> Moving;

            state Moving
            {
                BeltStalled -> Fault;
            }
        }

        region Safety
        {
            state Monitoring
            {
                do / checkLightCurtain;

                [is_breached] -> Fault / stopBelt();
            }
        }
    }
}

Zwei Regionen vom Typ Running werden parallel ausgeführt. Der generierte C++-Code enthält die Thread-Verwaltung, den Mutex-Schutz für gemeinsam genutzte Daten und die Synchronisierung nach Abschluss eines Bereichs – deterministisch, immer gleich und jedes Mal erzeugt. Der Entwickler muss nie einen std::mutex für die Zustandsverwaltung der Zustandsmaschine schreiben und nie eine Race Condition in einer Infrastruktur debuggen, die er nicht selbst entworfen hat.

Der Soft-Roboter: Automatisierung ohne Kontrollverlust

Industrieroboter haben die Ingenieure am Fließband nicht ersetzt. Sie führen ein präzises Programm wiederholbar aus, und der Ingenieur behält die volle Kontrolle darüber, was gefertigt wird. Ein Schweißroboter, der improvisiert, würde sofort aus der Fabrik entfernt.

Ein deterministischer Codegenerator ist das Software-Äquivalent – ​​ein Soft-Roboter. Er ist schnell und ausdauernd wie ein KI-Assistent, improvisiert aber im Gegensatz zu diesem nie. Dieselbe .umt-Eingabe erzeugt byte-für-byte identische Ausgabe. Jede Zeile des generierten Codes lässt sich auf eine Zeile des Modells zurückführen. Wenn das Verhalten fehlerhaft ist, erfolgt die Korrektur im Modell, unter Versionskontrolle, in einem überprüfbaren Diff.

Diese Balance verspricht der Titel dieses Beitrags: Der komplexe Steuerungscode wird nicht manuell geschrieben, die Kontrolle aber auch nie abgegeben. Der Entwickler ist für das Design verantwortlich – Zustände, Ereignisse, Schutzmechanismen, Aktionen – ausgedrückt in einer Sprache, die genau dafür entwickelt wurde. Der Soft-Roboter übernimmt die Übersetzung in die korrekte Infrastruktur für nebenläufige Programmierung. KI hat weiterhin ihren Platz am Tisch, wie bereits erwähnt: Sie kann beim Entwurf und der Überprüfung des Modells helfen. Die endgültige Umsetzung in Code obliegt jedoch einer Maschine, die Verantwortung trägt, nicht einer, die lediglich überzeugt.

Fazit

Parallelität wird weder durch aufwendig handgeschriebenen Code noch durch die Übertragung von Entscheidungsbefugnissen an einen Generator handhabbar. Sie wird handhabbar, wenn das Verhalten in einem textbasierten Modell abgebildet ist – vergleichbar, überprüfbar, versioniert – und ein deterministischer Soft-Roboter dieses Modell in eine Infrastruktur umwandelt, die der Entwickler andernfalls in jedem Projekt unvollkommen neu implementieren müsste. Der Entwickler entscheidet; der Roboter implementiert; das Modell sorgt für Transparenz.

Bei Fragen oder Projekten im Zusammenhang mit UMTSM können Sie uns gerne kontaktieren. Kontakt aufnehmen.