Echtzeit ist kein Buzzword

In vielen Embedded-Projekten zählt nicht nur, ob etwas passiert, sondern wann. Eine Reaktion 50 Millisekunden zu spät kann in der Praxis bedeuten: falsche Messwerte, instabile Regelung oder im schlimmsten Fall ein Sicherheitsrisiko. Echtzeitfähigkeit ist kein Zusatzfeature – sie ist oft die Grundvoraussetzung.

Hardware bestimmt die Regeln

Embedded-Software lebt nicht im luftleeren Raum. Speicher, CPU, Stromverbrauch, Temperatur, EMV, Bus-Systeme, Sensorik: All das sind keine Randbedingungen, sondern das Spielfeld. Wer die Hardware ignoriert, schreibt Code, der im Labor funktioniert – und im Produkt scheitert.

Qualität heißt: reproduzierbar und testbar

Die größte Herausforderung ist selten das „Feature“, sondern die Robustheit. Embedded-Systeme laufen oft jahrelang, teilweise ohne Neustart, unter wechselnden Bedingungen. Das erfordert saubere Architektur, defensive Programmierung, Logging-Konzepte, Tests auf mehreren Ebenen (Unit, Integration, Hardware-in-the-Loop) und vor allem: Disziplin.

Die unterschätzte Rolle von Schnittstellen

Kaum ein Embedded-System steht allein. Es gibt Schnittstellen zur Cloud, zu Apps, zu Diagnose-Tools, zu anderen Steuergeräten. Fehler entstehen häufig nicht im Kernmodul, sondern an Übergängen: Protokolle, Timing, Datenformate, Versionierung. Genau hier trennt sich „läuft irgendwie“ von „läuft sicher“.

Wie tief muss man ins Kundenprodukt eintauchen?

Die kurze Antwort: tief genug, um das Produkt wirklich intelligent zu machen. Embedded-Entwicklung ist immer auch Domänenverständnis. Wer ein Medizingerät, eine Industriemaschine oder ein IoT-Produkt softwareseitig verbessern soll, muss verstehen, was das Gerät in der Realität tut: welche Fehlerbilder auftreten, welche Nutzer es bedienen, welche Grenzfälle existieren, welche Normen gelten. Nur dann entsteht Software, die nicht nur korrekt ist, sondern sinnvoll.

Fazit: Embedded ist Engineering, nicht nur Coding

Embedded-Projekte sind komplex, weil sie Technik, Physik, Zuverlässigkeit und Verantwortung verbinden. Genau deshalb ist Embedded Software kein Ort für „Trial and Error“, sondern für strukturierte Entwicklung, Erfahrung – und echtes Engineering.

Verpasst? Kein Problem: Hier findet ihr den Mitschnitt unserer Generalprobe – Übung macht schließlich den Meister. Welche Fragen habt ihr? Schreibt es in die Kommentare – wir antworten.

Link zum Video auf YouTube

Machine-Learning statt Algorithmen?

In unserer letzten Prototypenentwicklung setzten wir TensorFlow zur Nachbildung eines Algorithmus ein und lernten dessen Fehlertoleranz-Eigenschaften kennen. Unseren vorhandenen C-Code nutzten wir zunächst, um dessen Funktion über einen längeren Zeitraum zu loggen – Eingangs- und Ausgangswerte – etwa 20.000 Iterationen.

Mit diesen Trainingsdaten lernten wir ein TensorFlow-Modell an, quantisierten es und wandelten es für den Einsatz in TensorFlow Lite um. Die notwendige Python-Toolchain generierten wir mittels Ollama und einem LLM flott selbst. Das Ergebnis überraschte: Das Modell imitiert nach kleinen Anpassungen perfekt unseren Algorithmus auf der Zielhardware – einem ARM Cortex-M3.

Wo liegen die Vorteile?

Nun bringt ein in TensorFlow umgesetzter Algorithmus per se keine Vorteile sondern vor allem Herausforderungen: Wie qualifiziere ich ein Modell gegenüber einem Algorithmus? Wie formuliere ich meine Anforderungen, was sind meine Testfälle und wie führe ich Änderungen richtig durch? Warum also der Aufwand?

Wir führten ein Experiment durch: Was macht das Modell im Fehlerfall, wenn einer oder mehrere Eingangswerte fehlen. Unser Algorithmus kann damit nicht umgehen, wir müssten jeden Fehlerfall durchdenken und möglichst elegant abfangen. Unser Modell? Kann ebenfalls nicht mit einem Fehlerfall umgehen. Daher erweiterten wir die Trainingsdaten um exakt die erwarteten Fehlerfälle – lernten das Modell neu an. Und wir haben nicht schlecht gestaunt, dass unser Modell mühelos alle Fehlerfälle gemeistert hat. Diese Kombinatorik in unserem Algorithmus zu lösen wäre mehr Aufwand gewesen.

Natürlich steckt noch Arbeit im Verständnis und der richtigen Qualifizierung der Ergebnisse. Unser Experiment zeigt aber: In schwierigen Szenarien oder für Prototypen kann ein Maschine-Learning-Ansatz sehr schnell sehr gute Ergebnisse liefern und die Arbeit unserer Entwickler spürbar beschleunigen.

Übrigens

Schon 2020 haben wir unseren Messedemonstrator iSparcc (Video) mit einem TensorFlow-Modell Videodaten interpretieren lassen. Das trainierte Modell war in der Lage Miniatur-Stoppschilder zu erkennen und dynamisch auf seine Umgebung zu reagieren und war mehrfach auf der Embedded World zu sehen.