Der Profi für Automatisierungstechnik

Fundiertes Know-how trifft auf kreative Konzeption

• 1997 habe ich meinen Gesellenbrief als Energieelektroniker für Anlagentechnik in der Tasche gehabt – sprich: ich kann einen Schaltschrank von Grund auf verdrahten und weiß, wie es sich anfühlt, wenn man nachts um drei wegen eines Stillstands aus dem Bett geklingelt wird.
  Genau in dieser Zeit als Betriebselektriker hat mich die Automatisierungstechnik gepackt und nicht mehr losgelassen.


• 2001 habe ich diese Begeisterung zum Beruf gemacht und bin nach Göppingen gezogen, um bei Sigmatek Kundenapplikationen zu programmieren. Fünf Jahre lang durfte ich dort durch unzählige Maschinenarten und Branchen schauen – und genau dort habe ich auch zum ersten Mal verstanden, was objektorientierte Entwicklung in der SPS-Welt eigentlich bedeutet, lange bevor das in der Branche selbstverständlich war.


• 2006 hat mich Bachmann aus Vorarlberg gefragt, ob ich den Kundenkreis rund um Nürnberg betreuen will – die Gelegenheit, wieder zurück in meine Heimat zwischen Frankenwald und Fichtelgebirge zu ziehen, hat mich keine Sekunde zögern lassen.
  Hier, zwischen zwei der schönsten Mittelgebirge Frankens, bin ich seitdem geblieben – nicht nur beruflich, sondern auch, weil ich mit dem Mountainbike oder zu Fuß kaum eine bessere Gegend kenne, um den Kopf wieder freizubekommen. Neun Jahre lang habe ich für Bachmann Kunden begleitet, Probleme gelöst und nebenbei gelernt, wie unterschiedlich Maschinenbauer an Software herangehen.


• 2015 habe ich dann den Sprung in die Selbstständigkeit gewagt. Seitdem arbeite ich als freiberuflicher Entwickler für kleine und große Unternehmen – und je länger ich das mache, desto klarer wurde mir: Code, der nicht getestet ist, ist nur eine Behauptung. Also habe ich mich 2016/2017 intensiv mit Softwaretest auseinandergesetzt und die ISTQB-Zertifizierungen zum Certified Tester Advanced Level Test Analyst und Technical Test Analyst abgeschlossen.


• Diese Kombination – jahrzehntelange Praxis in der SPS-Welt und ein methodisches Verständnis von Softwaretest – ist letztlich der Ursprung von SCCX. Denn so gut die IEC-61131-3-Welt im Maschinenbau auch funktioniert, bei Codeabdeckung und automatisiertem Testing steckt sie oft noch in den Kinderschuhen. Mit SCCX bringe ich genau das in TwinCAT- und LASAL-Projekte: nachvollziehbare, in CI/CD-Pipelines integrierte Code Coverage – nicht aus akademischem Interesse, sondern weil ich selbst zu oft erlebt habe, was passiert, wenn niemand wirklich weiß, was getestet wurde und was nicht.