Blog · 7. August 2026
Fremde Firmware übernehmen, ohne sie kaputtzumachen
Die Steuerung einer laufenden Geräteserie der KODRA GmbH stand ohne ihren Entwickler da; wir haben Hardware und Firmware übernommen und betreuen die Serie seither. Die Erfahrung daraus in einem Satz: Eine Übernahme scheitert selten am fehlenden Wissen — sie scheitert an der Ungeduld.
Die Versuchung, sofort zu ändern
Der Anlass einer Übernahme ist fast nie Neugier, sondern ein drängender Wunsch: ein Fehler im Feld, ein abgekündigtes Bauteil, eine Kundenanforderung. Die Versuchung ist deshalb immer dieselbe — sofort den Wunsch umsetzen, in einem Quellcode, den man noch nicht versteht. Genau daran gehen Übernahmen kaputt: Die Änderung wirkt, aber sie wirkt an drei Stellen, von denen man zwei nicht kannte.
Erst verstehen — und das laufende Gerät in Ruhe lassen
Bevor irgendetwas angefasst wird, wird das Verhalten des laufenden Geräts dokumentiert: was es beim Einschalten tut, wie es auf jede Bedienung reagiert, was in den Grenzfällen passiert. Ein Referenzgerät bleibt dabei unangetastet — es ist die Wahrheit, gegen die später jede eigene Änderung gemessen wird.
Beim Lesen des Codes gilt eine Regel, die Überwindung kostet: Eigenwilligkeiten stehen lassen. Der seltsame Timer, die scheinbar doppelte Prüfung, die Konstante ohne Kommentar — meist hatte der Vorentwickler einen Grund, und der stand in keinem Dokument, sondern in seinem Kopf. Wer aufräumt, bevor er versteht, löscht Wissen, das nirgends sonst existiert.
Der erste Meilenstein einer Übernahme ist deshalb unspektakulär: ein eigener Build, der sich auf dem Gerät verhält wie der Serienstand. Solange das nicht gelingt, ist jede Änderung ein Blindflug.
Dann festhalten: der Stand kommt in die Versionsverwaltung
Der Stand, der heute gefertigt wird, kommt versioniert in Git — Quellcode, Schaltplan, Layout, Fertigungsunterlagen. Ab diesem Punkt ist reproduzierbar, was ausgeliefert wird, und kein Wissen hängt mehr an einer einzelnen Festplatte oder einem einzelnen Kopf. Jede Änderung trägt von da an eine Begründung im Änderungsprotokoll: was, wann, wo — und warum.
Erst dann ändern — und klein anfangen
Die erste eigene Änderung ist bewusst eine kleine: eine, deren Wirkung sich vollständig übersehen lässt. Sie ist weniger für das Gerät da als für den Prozess — sie beweist, dass Bauen, Aufspielen, Testen und Zurückgehen funktionieren, bevor die Änderung ansteht, um die es eigentlich geht. Fehlt der Quellcode ganz, heißt Übernahme übrigens meist: die Firmware neu schreiben, gegen das dokumentierte Verhalten des laufenden Geräts — auch dann ist die Verhaltensdokumentation vom Anfang das wichtigste Arbeitsmittel.
Und bei Ihnen?
Läuft bei Ihnen eine Serie, deren Firmware nur noch eine Person versteht — oder schon niemand mehr? Schreiben Sie uns — uns interessiert, wie Sie diesen Stand heute sichern, bevor es drängt.
Transparenzhinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und vor der Veröffentlichung fachlich geprüft.