Tools
Die wahre Kunst liegt darin, verschiedene Werkzeuge sinnvoll miteinander zu kombinieren.
Gerade in der Embedded-Software-Entwicklung ist der Begriff „Tool-Chain“ allgegenwärtig – und treffend:
Eine Information durchläuft unterschiedliche Entitäten, Methoden und Werkzeuge.
Sie wird geteilt, geformt, angereichert – bis aus Input schließlich Output wird.
Das ist im Grunde das, was wir alle täglich tun: Informationen verarbeiten, weitergeben, aufwerten.
In vielen Fällen ist es sinnvoll – manchmal sogar zwingend notwendig –, diese Abfolge klar zu definieren und zu dokumentieren.
Ob Ablaufdiagramm einer Software, Geschäftsprozess oder einfache Arbeitsanweisung:
Die verständliche Darstellung solcher Verkettungen ist die Basis jeder fundierten Analyse.
Schon die vollständige Darstellung eines scheinbar einfachen Freigabeprozesses kann bestehende Grenzen und Routinen hinterfragen – und damit echte Veränderung anstoßen.
Im Folgenden stelle ich eine Auswahl an Werkzeugen und Themenbereichen vor, die für meine Arbeit immer wieder entscheidend waren – oder es aktuell sind.
Ich zögere nicht, neue Tools einzusetzen oder bestehende Werkzeuge für andere Kontexte nutzbar zu machen.
LaTeX
Im Studium war es noch ein „Nice-to-Have“ – inzwischen gehört es zu meinen wichtigsten Werkzeugen: ein flexibles, leistungsfähiges Textsatzsystem.
Ob konsistente Formatierung über mehrere Autor*innen hinweg, gezielte Änderungen einzelner Passagen ohne manuelle Korrektur aller Seitenumbrüche oder die Erstellung dynamischer PDFs – mit einem guten System wird all das reproduzierbar, wartbar und effizient.
Auch komplexe Anforderungen wie Serienbriefe mit variablen Inhalten, automatisch erzeugte Inhaltsverzeichnisse oder klickbare Seitennavigation lassen sich damit elegant umsetzen.
Was früher umständlich war, geht heute strukturiert, automatisiert und zuverlässig. Ein echter Produktivitätsgewinn – besonders bei langlebigen oder regelmäßig aktualisierten Dokumenten.
Whiteboard
Notfalls tut es auch eine Glasscheibe.
Wichtig ist: Alle sprechen dieselbe Sprache – und sehen dasselbe Bild vor sich.
Klarheit im Vorfeld spart Nerven, Zeit und Missverständnisse. Denn: Die Erklärung im Nachhinein kostet oft deutlich mehr als die kurze Klärung davor.
Ich habe beobachtet, dass Teams deutlich kompakter, präziser und nachhaltiger kommunizieren, wenn sie regelmäßig gemeinsam skizzieren.
Ein Whiteboard – ob physisch oder digital – ist dabei oft der einfachste, aber wirkungsvollste Ort für diese Art des Austauschs.
yED
Entscheidungsbäume, UML-Diagramme, Blockschaltbilder, einfache Ablaufpläne –
yED ist ein erstaunlich mächtiges und dennoch kostenfreies Tool zur grafischen Darstellung komplexer Zusammenhänge.
Besonders praktisch: Auch interaktive Diagramme lassen sich direkt als HTML exportieren.
Was du siehst, ist was du bekommst – ganz im Sinne von WYSIWYG.
Für wirklich komplexe oder dynamische Strukturen nutze ich zusätzlich skriptbasierte Tools – aber für viele Alltagsanwendungen ist yED effizient, intuitiv und vollkommen ausreichend.
GUI
Grafische Benutzeroberflächen sind oft der schnellste Weg, komplexe Konfigurationen zugänglich zu machen.
Beispielsweise lässt sich mit vergleichsweise geringem Aufwand ein Konfigurator entwickeln, der aus einer Vielzahl von Eingaben einen konkreten Befehlssatz erzeugt.
Ich habe einmal abends eine GUI programmiert, mit der ein Kunde das Öffnungsprofil einer Elektronik – also Weg und Geschwindigkeit – direkt über sechs Stützpunkte im Diagramm definieren konnte.
Die Werte dazwischen wurden automatisch interpoliert. So konnten innerhalb kürzester Zeit zahlreiche kleine Anpassungen getestet werden – ganz ohne erneute Rücksprache oder technische Hürden.
Gerade weil das Thema sehr subjektiv und schwer kommunizierbar war, war die grafische Schnittstelle ein echter Durchbruch.
Der eigentliche Mehrwert lag nicht nur in der technischen Lösung, sondern in der Selbstwirksamkeit, die der Kunde erlebte – und die als Value-Gain kaum zu überschätzen ist.
Datenbanken
Die meisten von uns bekommen von den zugrunde liegenden Datenstrukturen wenig mit – zumindest so lange, bis es herausfordernd wird.
Datenstrukturen analysieren, optimieren, Konsistenz zwischen verschiedenen Datensätzen herstellen, ER-Diagramme aufbauen, Aggregationen verstehen – all das macht selten Spaß, aber es lohnt sich.
Denn wer versteht, wie Informationen im Hintergrund abgebildet werden, erkennt nicht nur die Grenzen eines Systems, sondern oft auch neue Möglichkeiten.
Wie viele der gesammelten Informationen werden tatsächlich genutzt?
Und welche ließen sich ohne zusätzlichen Aufwand heute schon für die Anforderungen von morgen generieren?
CAD / Fusion360 / EAGLE
Ich habe im Laufe der Entwicklung zahlreiche Leiterkarten entworfen – von einfachen Adaptern bis hin zu komplexen 3D-Starr-Flex-Layouts mit mehreren Mikrocontrollern und Schnittstellen.
Selbst ungewöhnliche Konstruktionen wie Biegebalken aus Leiterbahnen auf Aluminiumkern: Geht – mit dem richtigen Aufbau.
Auch im Bereich mechanisches Prototyping arbeite ich regelmäßig mit CAD-Systemen – vor allem mit Fusion 360.
Ob für 3D-Druck, CNC-Fräsen oder Laserschneiden: Das Tool hat sich für mich als flexibel und zuverlässig erwiesen.
Ich bewege mich dabei bewusst im Bereich des zweckmäßigen Prototypings – schnell, funktional, lösungsorientiert.
SPICE Simulation
Ich würde mich nicht als Simulationsexperten bezeichnen –
aber mit SPICE konnte ich bereits mehrfach kritische Störungen nachvollziehen und Lösungsansätze plausibilisieren.
Manche Berechnung ist aufwendiger als eine schnelle empirische Wertermittlung –
nur möchte man eben keine winzigen Bauteile auf teuren Prototypenplatinen mehrfach austauschen müssen.
Einmal konnte ich per Simulation einen Schaltungsteil untersuchen, an dem ich Zweifel hatte.
Das Projekt war zeitkritisch, der verantwortliche Ingenieur hielt die Schaltung für unproblematisch – die Platinen wurden bereits bestellt.
Noch bevor sie eintrafen, konnte ich den Fehler vorhersagen und einen fundierten Lösungsvorschlag präsentieren.
Die Simulation hat mehrere Tage gekostet – doch ein äquivalenter Testaufbau wäre kaum realisierbar gewesen.
Der Aufwand hat sich letztlich ausgezahlt: in Zeit, in Geld – und im Vertrauen in das Tool.
CAM / CNC / Robotik
Mit Automatisierung habe ich mich über viele Jahre intensiv beschäftigt –
vor allem mit Sechsachs-Knickarmrobotern von KUKA und ABB.
Zykluszeitenoptimierung, Palettierung, Kameraprüfung, Zellenerweiterungen, Entnahme, Lackierung, Beflammung, Fräsung, 2K-Schäumung:
Ich habe an unterschiedlichsten Prozessen gearbeitet – sowohl in der Entwicklung als auch in der Optimierung.
Was mich von Anfang an fasziniert hat, war die Verbindung zwischen Eingabe am Monitor und der Bewegung einer realen Anlage.
Diese Faszination hat bis heute nicht nachgelassen.
Prototyping
In der Entwicklung – aber auch im privaten Umfeld – bin ich immer wieder im Prototyping aufgegangen.
Ob Papierprototypen für Formstudien, funktionslose GUIs zur Vorbereitung von Anwendersoftware, abstrahierte Schaltungsteile zum Test neuer Bauteile oder komplette Versuchsaufbauten:
Machen, bis es geht. Zeigen, dass es geht. Besprechen, wie es gehen wird.
Prototyping ermöglicht steile Lernkurven und schafft früh Klarheit über das Machbare.
Ein Projekt ganz ohne Prototyp? Denkbar – aber oft riskant.
LabView
Ich habe bisher keine neuen Projekte in LabVIEW von Grund auf entwickelt, finde mich aber in bestehenden Anwendungen gut zurecht und kann darin auch einfache Anpassungen vornehmen.
Mehrere Anwendungen wurden unter meiner fachlichen Leitung umgesetzt – insbesondere für Prüf- und Flashstationen, die auf meine eigenen Platinen zugeschnitten waren.
So konnte ich Bauteile direkt auf ICT-Vorrichtungen testen, flashen und auslesen.
Teilweise wurden dabei individuelle Identifikationsmerkmale mitgeflasht oder Korrekturwerte aus Messergebnissen nachträglich eingespielt.
In jedem Fall wurden alle relevanten Daten erfasst, dokumentiert und automatisiert in einer Datenbank gespeichert – häufig im Zusammenspiel mit einer Funktionsprüfung.
Vorrichtungen / Versuchsaufbauten
Das „Drumherum“ eines Produkts – und oft ebenso entwicklungsintensiv wie das Produkt selbst.
Ich finde es faszinierend, wie viel Innovation und Sorgfalt in Hilfsmitteln steckt, die häufig im Schatten des eigentlichen Produkts stehen.
Diese Leidenschaft zieht sich durch viele meiner Projekte – sei es bei Prüfaufnahmen, Montagehilfen oder automatisierten Testvorrichtungen.
Leider wird der Vorrichtungsbau in vielen Unternehmen primär als Kostenfaktor gesehen – und nicht als das, was er sein kann:
Ein echter Beitrag zur Wertschöpfung.
Dabei lassen sich mit einer modularen, gut durchdachten Basis nicht nur Entwicklungsaufwände reduzieren, sondern auch Qualität und Prozesssicherheit deutlich steigern.
Vernünftige Aufnahmen, beherrschbare Prozesse, reproduzierbare Ergebnisse – genau hier beginnt nachhaltige Effizienz.
SPS / Automatisierung
Zwischen Prototyping, Vorrichtungsbau und Robotik findet man sie: die Steuerungen.
Ob schneller Aufbau mit LOGO! oder Easy – oft reicht schon ein kleiner Baustein, um viel zu bewegen.
Einmal fiel nachts eine veraltete Siemens S5 aus – keine Ersatzteile, kein Backup, keine Dokumentation.
Daran hing die Materialversorgung mehrerer Maschinen.
Innerhalb kürzester Zeit habe ich gemeinsam mit zwei Kollegen eine Notsteuerung auf Basis einer LOGO! mit Erweiterungsmodul aufgebaut und programmiert:
Einer kümmerte sich um die Verdrahtung, der andere lieferte die detaillierte Funktionsbeschreibung.
Was als kurzfristige Lösung gedacht war, lief – und zwar noch sehr lange. Vielleicht läuft es heute noch.
Auch in Step7 und TIA finde ich mich grundsätzlich zurecht, habe darin aber bislang nur wenig praktische Erfahrung gesammelt.
Microcontroller
Hunderte Stunden Entwicklung, Kodierung, Inbetriebnahme und Debugging – direkt auf Embedded-Hardware.
Meist arbeite ich auf eigenen Custom-PCBs – vom low-level C auf Registerebene bis hin zu abstrahiertem C++ auf hoher Ebene.
Wenn nötig, tauche ich auch innerhalb von Bibliotheken in Assembler-Spurensuche ab.
Ich habe mit Mikrocontrollern verschiedenster Plattformen gearbeitet: Microchip, STM, ESP – sowohl 8-Bit- als auch 32-Bit-Architekturen.
Dabei kamen unterschiedlichste Busse und Protokolle zum Einsatz: SPI, I²C, UART, CAN, USB – je nach Anforderung.
Multiplexing, Bit-Banging, präzises Timing – all das gehört für mich zur täglichen Werkzeugkiste bei der Firmware-Entwicklung.
Fotografie
Privat „knipse“ ich gerne – wie ein Freund einmal sagte.
Von Zeit zu Zeit entsteht dabei auch eine richtige Fotografie.
In der technischen Darstellung und Dokumentation ist Fotografie mehr als ein ästhetisches Mittel – sie ist ein Werkzeug.
Stroboskopie, Makroskopie, Polarisation, Fokusstacking, Störeinflüsse aus der Umgebung oder IR-Transmissivität:
Wer die technischen Aspekte der Aufnahme kennt, kann gezielter darstellen, was wirklich gesehen werden soll.
Ich erinnere mich gut an ein leistungsfähiges, aber kaum genutztes Keyence-Prüfsystem, das ich einmal optimieren durfte – ein gutes Beispiel dafür, wie Technik und Bildverständnis ineinandergreifen können.
Dataverse
In Vorbereitung auf ein Projekt habe ich mich intensiv mit der Microsoft-Lernumgebung beschäftigt und mehrere Module absolviert. Ziel war es, das Zusammenspiel von Dynamics, SharePoint, OneDrive, Teams und Copilot zu verstehen – vorher hatte ich wenig Einblick, hinterher deutlich mehr.
Parallel war ich ohnehin dabei, das Dokumentenmanagement neu zu denken – also habe ich einen Prototypen entwickelt:
Eine Dataverse-Tabelle als zentrale Struktur, ein einfaches Front-End mit Benutzersteuerung zur Verschlagwortung und Versionierung von PDFs, sowie eine Verknüpfung zu Microsoft Copilot.
Über einen Chatbot in Teams konnte anschließend direkt die aktuelle Version eines Dokuments abgefragt und heruntergeladen werden – ohne Netzlaufwerksuche, ohne lokale Kopien.
Beispiel: „Formular 123“ einfach im Chat anfordern – stets aktuell, sofort verfügbar.
Klingt gut? Hat auch richtig Spaß gemacht.
OSINT
Das Thema ist für mich noch neu – bisher gab es noch kein konkretes Projekt mit Anwendung.
Ich habe jedoch bereits einen freien Online-Kurs beim Basel Institute on Governance abgeschlossen und dabei einen spannenden Einstieg in Methoden und Denkweisen von OSINT erhalten.
Als nächstes steht für mich das Thema Finanzanalyse auf dem Plan – insbesondere die Identifikation von Anomalien in Zahlungsströmen.
Wenn sich passende Anwendungsfelder ergeben, werde ich die erlernten Methoden gern einfließen lassen.
ASM, C, C++, C#, Java, ...
Software entsteht nicht in einer bestimmten Sprache – sie entsteht durch Konzepte, Strukturen und Architektur.
Programmiersprachen sind Werkzeuge, keine Identitäten.
Ich habe mit all diesen Sprachen bereits gearbeitet – manche sehr häufig, andere nur gelegentlich.
Was zählt, ist das Verständnis für Zusammenhänge, Muster und Prinzipien.
Sich in einer Sprache und in bestimmten Frameworks gut auszukennen, bringt Effizienz.
Aber Softwareentwicklung ist mehr als Syntaxwissen – es ist Problemlösung.
Deshalb: Ich bin kein „C++-Entwickler“. Ich entwickle Software – und setze sie dann in einer passenden Sprache um.
Das ist ein Unterschied.