Pelletofen-Steuerung: Refactoring, Testsystem & Tool-Migration

Eine gewachsene Firmware – und kein Testsystem

Der LASCO LATherm LA150P ist ein mobiler Pellets-Warmlufterzeuger mit bis zu 150 kW Heizleistung – im Einsatz in der Landwirtschaft, in Industriehallen und auf Baustellen. Die Steuerung läuft auf einer selbst entwickelten Platine mit einem STM32-Mikrocontroller und regelt alles, was den Kessel ausmacht: Start, Pelletförderung, Temperaturregelung, Rostreinigung, Störungsbehandlung.

Software wie diese entsteht selten am Reißbrett. Sie wächst über Produktgenerationen mit, wird erweitert, wenn ein Kunde etwas braucht, und angepasst, wenn sich die Hardware ändert. Das Ergebnis läuft – nur weiß irgendwann niemand mehr genau, warum es läuft. Und ohne Testsystem traut sich dann auch niemand mehr, etwas daran zu ändern.

Genau an diesem Punkt bin ich dazugekommen. Beim Durchsehen der Codebasis und in den Gesprächen mit LASCO haben sich sechs Baustellen herauskristallisiert:

• Das HIL-Testsystem (Hardware-in-the-Loop) für die Platinen-Prüfung sollte reaktiviert, erweitert und an die konkreten Anforderungen der Tester angepasst werden – u. a. mit einem Feature, das bei einem fehlgeschlagenen Test nicht von vorne beginnt, sondern gezielt an der Fehlerstelle fortsetzt.
• Das Testprogramm für den Produktionsprüfstand sollte komplett neu entwickelt werden – strukturiert und wiederverwendbar als Basis für spätere Regressionstests.
• Die Steuerungssoftware war über mehrere Produktgenerationen schrittweise weiterentwickelt worden und sollte nun modularisiert, dokumentiert und in eine skalierbare Struktur überführt werden.
• Kernprozesse wie Kesselablauf, Rostreinigung und Fallschachtreinigung sollten robuster neu strukturiert und erstmals vollständig dokumentiert werden.
• Die Entwicklungsumgebung sollte auf die kostenfreie, herstellereigene STM32CubeIDE umgestellt werden.
• Versionsverwaltung, Ticketsystem und Build-Pipeline sollten eingeführt werden, um Weiterentwicklungen strukturiert abwickeln zu können.

In Phasen, damit die Produktion weiterlaufen kann

Der Kessel wird gebaut und verkauft, während man an seiner Software arbeitet. Ein großer Umbau am Stück kam deshalb nicht in Frage. Ich habe das Projekt in fünf Phasen zerlegt, jede mit eigenem Abnahmekriterium – nach jeder Phase gab es einen Stand, mit dem LASCO hätte weiterarbeiten können, auch wenn wir dort aufgehört hätten.

1. Das HIL-Testsystem wieder zum Laufen gebracht

   Zuerst wollte ich wieder messen können, bevor ich irgendetwas ändere. Ich habe das bestehende Hardware-in-the-Loop-System analysiert, repariert und nach den Wünschen der Tester neu konfiguriert. Die Verbesserung, die im Alltag am meisten gebracht hat: Ein fehlgeschlagener Test wirft den ganzen Durchlauf nicht mehr zurück auf Anfang, sondern setzt an der Fehlerstelle fort. Das verkürzt jede Diagnose spürbar.

2. Das Testprogramm neu geschrieben

   Das ursprüngliche Testprogramm für den Produktionsprüfstand war nicht mehr auffindbar. Also neu – und diesmal so strukturiert, dass der Code später auch als Basis für eine neue Produktivversion der Firmware taugt. Doppelte Arbeit vermeidet man am besten, bevor sie entsteht.

3. Auf STM32CubeIDE migriert

   Die Codebasis hing an einer lizenzpflichtigen IDE. Ich habe sie auf die kostenfreie, herstellereigene STM32CubeIDE umgezogen, dabei die Projektstruktur aufgeräumt und ein sauberes Build-System aufgesetzt. Ab da konnte jeder im Team ohne Lizenzfrage bauen.

4. Refactoring und Versionsverwaltung eingeführt

   Erst mit Testsystem und Build im Rücken habe ich mich an den eigentlichen Code getraut. Refactoring Schritt für Schritt, alles in ein Git-Repository überführt, dazu ein Ticketsystem und eine Build-Pipeline, die sich später erweitern lässt. Nichts davon ist spektakulär – aber es ist der Unterschied zwischen „wir trauen uns nicht" und „wir ändern das eben".

5. Die Kernprozesse neu implementiert

   Kesselablauf, Rostreinigung und Fallschachtreinigung habe ich auf Basis der tatsächlichen Betriebsabläufe von Grund auf neu geschrieben – und zum ersten Mal formal spezifiziert. Diese Spezifikation ist nebenbei das geworden, was im Projekt am längsten überdauert: eine verlässliche Betriebsreferenz, in die alle Beteiligten schauen können.

Eingesetzte Hardware, Toolchain und Schnittstellen

Für alle, die es genau wissen wollen – womit die Anlage arbeitet und womit ich gearbeitet habe:

Eine Basis, auf der man weiterbauen kann

Am Ende stand eine Softwarebasis, die dokumentiert, testbar und erweiterbar ist. Das Sichtbarste daran ist paradoxerweise das Unsichtbare: Der Kessel tut, was er vorher auch getan hat. Der Unterschied liegt darin, dass man jetzt weiß, warum – und dass man es ändern kann, ohne zu raten.

Was ich aus dem Projekt mitgenommen habe: Bei gewachsener Firmware ist die Versuchung groß, sofort am Code anzufangen. Der schnellere Weg führt fast immer über das Testsystem. Sobald man wieder messen kann, wird aus jedem Umbau eine überprüfbare Änderung statt einer Wette.