Von der 8‑Zoll‑Diskette zur Flottensteuerung: Klemens Pleiner (DS Automotion GmbH) über Baukastensoftware, Schnittstellen und Software, die Dinge bewegt

Ein DevJobs.at‑Rückblick auf „Klemens Pleiner, Basis Software Developer bei DS Automotion“

Es gibt Karrieregeschichten, die sich wie ein Lehrbuch über Neugier, Ausdauer und Sinnstiftung in der Softwareentwicklung lesen. Die Session „Klemens Pleiner, Basis Software Developer bei DS Automotion“ gehört genau in diese Kategorie. Wir bei DevJobs.at haben zugehört und mitgeschrieben: Wie ein Volksschulbesuch im Gemeindeamt der 1980er eine lebenslange Faszination auslöste. Wie aus ersten Zeilen in Amiga Basic ein Ritt durch Pascal, C und Assembler wurde. Wie der Schritt in die Anlagen‑ und Leitsteuerungssoftware folgerichtig kam. Und warum es ein spezielles Glück ist, wenn Code in der Realität Türen öffnet, Ampeln steuert – und vor allem Fahrzeuge sicher durch große Anlagen schickt.

In dieser Reportage zeichnen wir Pleiners Stationen nach, verdichten seine Aussagen zu handfesten Einsichten und halten fest, worauf es in einer hochspezialisierten Domäne wie der Leitsteuerungssoftware ankommt: modulare Komponenten, robuste Schnittstellen, Technologie‑Modernisierung – und eine gesunde Portion Spieltrieb.

Das erste „Wundergerät“: Faszination für das Generieren von Wissen

Ein Bild bleibt hängen: Ein „riesiger Blechk Kasten“ mit kleinem Monochrom‑Monitor und einem breiten Schlitz für 8‑Zoll‑Disketten. Im Gemeindeamt der Nachbargemeinde, irgendwo in den 80ern, zeigt man der Schulklasse, was ein Computer kann: Informationen speichern, abrufen – und „aus den gespeicherten Informationen auch neue berechnen“.

Pleiners Reaktion: Elektrisiert. Aus Daten neue Daten generieren – im Kontrast zur damaligen Papierwelt eine völlig neue Erfahrung. Und mit jedem weiteren Kontakt mit Computern wächst dieselbe Frage: Wie geht das da drinnen?

Diese technisch‑naive Neugier ist der rote Faden seiner Geschichte. Sie erklärt, warum der zwölfjährige Klemens am Amiga 500 mit Amiga Basic beginnt – und warum ihn die mitgelieferten Beispiele nur kurz aufhalten. Das Verstehenwollen zieht ihn tiefer.

Vom Amiga zu Assembler: Frühphase des Lernens

Mit 12 Jahren geht es los – nicht mit Spielen, sondern mit den Grundzügen des Programmierens. Amiga Basic, die einfachen Beispiele, das erste Gefühl für Steuerfluss und Logik. Doch die Lernkurve zeigt rasch nach oben. Pleiner will „tiefer einsteigen“ und wechselt auf den PC – mit Pascal, C und Assembler.

Der Höhepunkt dieser Frühphase: Gemeinsam mit einem Schulkollegen schreibt er ein Mini‑Betriebssystem in Assembler. Nicht weil es sein muss, sondern weil es geht – und weil man dabei eine Maschine versteht, Schicht für Schicht.

Die Konsequenz aus dieser Neugier ist konsequent: Informatikstudium. Nicht als formaler Haken, sondern als Quelle für das „theoretische Background‑Wissen“, das erklärt, warum man Dinge „geschickterweise so macht und nicht anders“. Das Studium liefert Begriffe, Modelle und Begründungen – die Praxis bleibt aber nie weit weg.

Studium, Arbeit, Selbstständigkeit: Die Lernschleife wird real

Noch während des Studiums beginnt Pleiner zu arbeiten, schließt ab, wird selbstständig. Später „von einem Kunden quasi angestellt“ – man könnte sagen: Das Projekt fängt den Experten ein. Diese Wechsel – Studium, Beruf, Selbstständigkeit, Anstellung – sind keine Brüche, sondern eine stete Verfeinerung der eigenen Rolle: vom neugierigen Tüftler zum Systembauer, der Verantwortung übernimmt.

Und dann, ein entscheidender Kontaktpunkt: Als externer Mitarbeiter bekommt Pleiner bei der DS Automotion GmbH „Anlagen‑Software Luft“. Die Domäne hält ihn fest.

Damit beginnt das Kapitel, das ihn heute prägt: Basisentwicklung in der Leitsteuerung – die Software, die man als Baukasten für alle möglichen Anlagen nutzt, um Kundenanforderungen zu realisieren.

Leitsteuerung: Vom Einzelkämpfer zur Flotte

Pleiners Bild ist einleuchtend: Ein Fahrzeug, „wenn man es einfach so hinstellt“, ist ein Einzelkämpfer. Die Aufgabe der Leitsteuerungssoftware ist, diese Einzelkämpfer im „Flottenverband durch große Anlagen fahren lassen“, sodass der Anlagenbetreiber seine Ziele erreicht – etwa „möglichst hohen Durchsatz“ oder „möglichst kurze Transportzeiten“ für Last‑Minute‑Transporte.

Das Basisteam baut dazu Komponenten, die in einem Baukastensystem bereitstehen. Der Grundsatz: Wiederkehrende Anforderungen werden als eigenständige Bausteine umgesetzt, die sich konfigurieren und in neue Anlagen „einstecken“ lassen. So entsteht eine Architektur, in der Kundenwünsche nicht jedes Mal neu entwickelt, sondern gezielt kombiniert werden.

Baukastendenken als Architekturprinzip

Der Baukasten ist mehr als eine Sammlung von Bibliotheken. Er ist eine Denkweise:

• Wiederkehrendes identifizieren: Wenn eine Anforderung „öfter als ein‑ bis zweimal“ auftritt, lohnt sich eine dedizierte Komponente.
• Trennung von Logik und Konfiguration: Der Baustein bleibt generisch, die Anlage wird durch Konfiguration spezialisiert.
• Plug‑and‑Play, aber in Echt: Komponenten „einstecken“ heißt, dass Integrationen und Schnittstellen vordefinierte Erwartungen erfüllen müssen.

Das Ergebnis ist ein System, das wiederverwendbar, wartbar und erweiterbar bleibt – genau die Eigenschaften, die man in einer Domäne braucht, in der Anlagen Jahrzehnte laufen und weiterwachsen.

Schnittstellen in alle Richtungen: Aufträge, Sensoren, Türen, Ampeln

Leitsteuerung ist ohne Schnittstellen nicht denkbar. Pleiner listet praxisnah auf, was regelmäßig gebraucht wird:

• Auftragsschnittstellen: Transportaufgaben „einlasten“ und den Fortschritt „an Fremdsysteme weitermelden“.
• Sensorschnittstellen: etwa ein Belegsensor an einem Lastübergabeplatz.
• Schnittstellen zu Fremdhardware: zum Beispiel Türen steuern, „damit Brandabschnitte nur dann geöffnet sind, wenn ein Fahrzeug durchfahren muss“, und danach wieder schließen.
• Ampelsteuerung: Personen in der Anlage zeigen, ob sie eine Fahrspur gefahrlos queren können.

Diese Beispiele verankern die Abstraktion im physischen Raum. Es geht nicht um reines Messaging, sondern um verlässliches Verhalten in einer Umgebung, in der Sicherheit, Timing und Zustände an harte Realitäten gekoppelt sind.

Wer Leitsteuerung entwickelt, baut die Brücken zwischen Softwarezustand und physischem Zustand – mit dem Bewusstsein, dass ein fehlerhaftes Timing nicht nur ein Logfile füllt, sondern reale Abläufe stört.

Modernisierung: Was früher „State of the Art“ war, verstaubt

Pleiners Erfahrungswert ist entwaffnend offen: „Das, was vor 20 Jahren State‑of‑the‑Art war, ist jetzt so verstaubt, dass das keiner mehr haben will.“ Die Konsequenz: kontinuierliches Portieren bestehender Funktionalität auf neue Technologien.

Er erwähnt konkret Auftragsschnittstellen „über Datenbankschnittstellen, über REST‑Schnittstellen, über Webtechnologien“ – also Technologien, die sich im Laufe der Jahrzehnte in Wellen etabliert haben. Wichtig ist nicht der Hype, sondern die langfristige Wartbarkeit. Wenn Anlagen seit 2004 laufen, muss Software die Fähigkeit haben, mitzuwachsen, ohne ihren Kernauftrag zu verlieren.

Modernisierung heißt hier:

• Bestehendes verstehen, bevor man es ersetzt.
• Schnittstellen konsolidieren, ohne Funktionslücken zu reißen.
• Technologie‑Schultern wählen, die lange tragfähig bleiben.

Teamarbeit ohne starre Grenzen: Aushelfen, wenn es zählt

Bei DS Automotion GmbH sind Teams „nicht total starr“ aufgeteilt. Immer wieder wird man „verborgt“ an Schwesterteams. Pleiner selbst arbeitet aktuell an einem großen Wartungsprojekt mit: Eine bestehende Anlage, „die seit 2004 hier läuft“, wurde um „sehr viele Fahrzeuge“ und „neue Gebäude“ erweitert. Die Aufgabe: neue Anforderungen für neue Transportflüsse in die Anlage bringen, damit sie „in den neuen Teilen genau das tut, was der Kunde haben möchte“.

Das ist gelebte Produkt‑ und Projektverantwortung: Komponenten bauen, aber auch in gewachsene Anlagen integrieren – und zwar dort, wo es gerade brennt. Für Entwicklerinnen und Entwickler bedeutet das Lernchancen über den Tellerrand hinaus, tiefere Systemkenntnis und das Feedback echter Betriebsrealität.

„Das Coolste ist, wir schreiben Software, die in der Realität Dinge bewegt.“

Man spürt, warum diese Domäne Menschen anzieht. Pleiner bringt es auf den Punkt:

Viele von uns kennen den intellektuellen Kick, wenn eine Serverapplikation läuft und die UI aufleuchtet. Aber hier fährt am Ende wirklich etwas – mit Gewicht, Richtung, Ziel. Diese Sichtbarkeit stiftet Sinn. Sie ist motivierend, gerade wenn Projekte lang sind und die Komplexität wächst.

Kultur: Kollegial, auf Augenhöhe, mit Freiraum

Pleiners Beschreibung der Zusammenarbeit ist unscheinbar und gerade deshalb glaubwürdig: „kollegial der Umgangston“, „nicht nur starr in unserem Team“, „einmal irgendwo anders aushelfen“, „mit Kollegen, auf denen man mit Augenhöhe kommunizieren kann“. Kein Buzzword‑Bingo, sondern ein Arbeitsumfeld, in dem man breit schauen und beitragen darf. Wer an komplexen Systemen baut, braucht genau das – die Freiheit, dort anzupacken, wo es dem Ganzen dient.

Wie wird man Programmierer? Neugier, Ausdauer – und spielerisches Denken

Pleiners Ratschlag beginnt mit einer Haltung: Fragen stellen. „Wie funktioniert das? Wie könnte ich dort neue Funktionalität reinbringen?“ Und zwar nicht nur am PC, sondern auch auf „Embedded Devices … Hardware, die irgendwo verbaut ist“, oder auf „Großrechnersystemen“. Programmierbar ist vieles – die Offenheit dafür ist der Startpunkt.

Danach kommt etwas, das man selten in glamourösen Tech‑Erzählungen liest: Durchhaltevermögen. Kleine Dinge sind „schnell erledigt“, größere brauchen „einen längeren Atem“, ganz große Projekte über „ein, zwei, drei Jahre“ fordern bewusste Motivation: „Wir steuern das Ziel an – also machen wir weiter.“

Formalisieren statt fabulieren

Ein bemerkenswerter Einblick betrifft die Problemlösungspraxis im Team. Wenn man bei DS Automotion GmbH anfängt, ist es „gut, dass man in einer C‑artigen Sprache Programmierkenntnisse mitbringt“. Aber: „Viele der Problemstellungen in unserer Problemdomäne sind sehr speziell.“ Man bringt keine fertige Ausbildung dafür mit.

Der Kern liegt im Denken:

• Probleme durchdenken – gern „spielerisch“. Pleiner erwähnt, dass sie „teilweise auch mit Spielzeug am Schreibtisch“ arbeiten.
• Das Denken formalisieren: „Wie kann man ein Problem formalisieren?“
• Die formalisierte Lösung „niederschreiben in Source Code“ – und fertig ist der Baustein.

Diese Haltung verbindet das Beste aus zwei Welten: neugieriges Ausprobieren und disziplinierte Formalisierung.

Hands‑on‑Learnings für Entwickler:innen – direkt aus der Leitsteuerung

Aus der Session lassen sich konkrete Einsichten ableiten, die über die Domäne hinaus gelten – und dennoch fest im Gesagten verankert sind:

• Neugier als Motor: Der Impuls, „aus Daten neue Daten zu berechnen“, kann eine ganze Laufbahn tragen.
• Tief tauchen lohnt: Von Amiga Basic zu C und Assembler – wer die unteren Schichten kennt, baut oben stabiler.
• Theorie macht praktikabel: „Warum man manche Sachen geschickterweise so macht“ – das liefert das Studium. Nicht als Dogma, sondern als Werkzeugkasten.
• Baukastenprinzip ernst nehmen: Wiederkehrendes kapseln, Konfiguration statt Kopie, klare Schnittstellen – so entstehen Systeme, die Jahrzehnte begleiten.
• Schnittstellen sind echte Verantwortung: Auftrag, Sensorik, Türen, Ampeln – Integrationen haben reale Folgen. Robustheit zählt mehr als Eleganz.
• Modernisieren ohne Verklärung: „Vor 20 Jahren State‑of‑the‑Art“ ist heute „verstaubt“. Portieren ist kein Makel, sondern Kernarbeit.
• Teams flexibel denken: Aushelfen, wenn es zählt – und dabei lernen, wie Komponenten im Feld wirklich wirken.
• Motivation managen: Große Projekte brauchen Atem. Das Ziel im Blick halten, auch über Jahre.
• C‑artige Sprachen als Basis: Nützlich für den Einstieg in diese Domäne – entscheidend bleibt aber das Denken in Problemen und Formalisierungen.
• Spieltrieb zulassen: Mit „Spielzeug am Schreibtisch“ Modelle bauen – weil Hände und Augen oft schneller verstehen als reiner Kopf.

Ein Tag im Basisteam – greifbar gemacht

Die Erzählung macht ein Arbeitsbild greifbar, das viele Entwickler:innen reizt: tagsüber Komponenten bauen, die man in Anlagen steckt; abends sehen, wie Fahrzeuge fahren. Dazwischen: Schnittstellen entwerfen, Sensoren anbinden, Türen sicher schalten, Ampeln dirigieren, Auftragsfortschritte an Fremdsysteme melden. Und wenn die Technologien reifen, Funktionalität sauber portieren – etwa zu Datenbankschnittstellen, REST‑Schnittstellen und Webtechnologien.

Pleiners derzeitige Aufgabe im Wartungsprojekt zeigt die Langfristigkeit, in der diese Systeme leben: Eine Anlage aus 2004 wächst weiter – mehr Fahrzeuge, neue Gebäude, neue Transportflüsse. Software ist hier keine Wegwerfware, sondern Infrastruktur. Sie muss verständlich, konfigurierbar und transportabel bleiben.

Warum diese Geschichte hängen bleibt

Nicht jede Entwicklerbiografie hat einen so klaren Spannungsbogen. Bei Klemens Pleiner sehen wir:

• die erste Begegnung mit einem „Wundergerät“,
• die frühe Tiefe (Assembler, Mini‑OS),
• den Übergang in die Theorie (Informatikstudium) im Dienste der Praxis,
• die Jahre der Selbstständigkeit und die Sogwirkung guter Projekte,
• die Ankunft in einer Domäne, in der Software Reales bewegt.

Und wir hören Zwischentöne: die Freude an kollegialem Miteinander, die Bereitschaft, Aufgaben zu tauschen, wenn es dem System dient, und die Bereitschaft, nicht nur zu programmieren, sondern Probleme zu modellieren.

Was wir aus „Klemens Pleiner, Basis Software Developer bei DS Automotion“ mitnehmen

Zusammengefasst, ohne Schnörkel:

• Softwareentwicklung ist ein Handwerk mit Haltung: neugierig, geduldig, formal denkend.
• Leitsteuerung verlangt Komponenten, die mehr leisten als Code: Sie verbinden digitale Zustände mit physischer Verantwortung.
• Technologiealtern und Modernisierung sind Normalfall – und ein Qualitätsmerkmal, wenn man sie beherrscht.
• Teamkultur ist ein Produktivitätsfaktor: auf Augenhöhe, beweglich, mit der Freiheit, dort anzupacken, wo es nötig ist.

Selten beschreibt ein Satz so gut, warum manche von uns Programmieren lieben.

Ausblick für Talente, die in diese Domäne wollen

Wer in eine Umgebung wie die der DS Automotion GmbH einsteigen möchte, findet im Gesagten klare Signale:

• Solide Grundlagen in einer C‑artigen Sprache helfen beim Start.
• Rechnet damit, dass vieles „sehr speziell“ ist – Lernbereitschaft schlägt Branchenerfahrung.
• Trainiert das „spielerische“ und das „formalisierende“ Denken: Modelle bauen, Hypothesen testen, präzise niederschreiben.
• Erlebt Modernisierung als Daueraufgabe – und als Chance, Systeme über Generationen tragfähig zu halten.
• Freut euch auf das seltene Privileg, dass euer Code am Ende etwas Physisches tut – Türen, Ampeln, Fahrzeuge.

Schluss: Sinn durch Wirkung

Wir verlassen die Session mit dem Gefühl, dass diese Laufbahn einen inneren Kompass hat: vom Staunen über das erste Wundergerät zur Freude am sichtbaren Effekt. Klemens Pleiner, heute Basis Software Developer in der Leitsteuerung bei der DS Automotion GmbH, zeigt, wie persönliche Neugier, solide Grundlagen und eine systematische, modulare Denkweise zusammenkommen. Und er erinnert uns an etwas, das im Tagesgeschäft leicht verblasst: Die schönste Software ist die, die etwas in der Welt bewegt.

• 

  

  Kevin Greßlehner, IT Techniker bei DS Automotion

  Kevin Greßlehner von DS Automotion spricht im Interview über seinen ursprünglichen Zugang zur IT Technik und gibt einen Überblick über seinen Job im Unternehmen sowie Tipps für Anfänger.

  Jetzt ansehen
• 

  

  Gerald Hahn, Requirements Engineer bei DS Automotion

  Gerald Hahn von DS Automotion berichtet im Interview über das Requirements Engineering: wie er in die Branche eingestiegen ist und was er Anfängern raten würde.

  Jetzt ansehen
• 

  

  Lukas Fiel, Test Automation Engineer bei DS Automotion

  Lukas Fiel von DS Automotion erzählt im Interview von seinem Werdegang von den eigenen Projekten bis hin zum Test Automation Engineering und welche Tipps er für Neueinsteiger bereithält.

  Jetzt ansehen