Menu
Abteilungen
F&E - Software
Softwareentwicklung in der Stahlindustrie.
wAS MACHT MAN DENN DA?
"Gute Frage! Auch in der Stahlindustrie werden immer mehr spannende IT-Lösungen eingesetzt.
Wir entwickeln also Softwareprodukte mit dem Hauptfokus auf die Stahlindustrie. Die Lösungen sind an sich häufig nicht an die Branche gebunden, aber werden von uns dort eingesetzt. In der Regel entstehen neue Ideen aus unserem Kundengeschäft. Wir sehen Probleme bei Kunden, für die es noch keine oder keine guten Lösungen gibt...."
"Gute Frage! Auch in der Stahlindustrie werden immer mehr spannende IT-Lösungen eingesetzt. Wir entwickeln also Softwareprodukte mit dem Hauptfokus auf die Stahlindustrie. Die Lösungen sind an sich nicht an die Branche gebunden, aber werden von uns dort eingesetzt. In der Regel entstehen neue Ideen aus unserem Kundengeschäft. Wir sehen Probleme bei Kunden, für die es noch keine oder keine guten Lösungen gibt..."
Zum Beispiel?
Die Kalibrierung von vielen kleinen Anlagenteilen ist häufig ein sehr aufwändiger Prozess beim Kunden. Wir haben das mit 3D-Laserscannern und einer in C++ geschriebenen Software zur Objektvermessung gelöst. Bei einem anderen Kunden haben wir die Mitarbeiter davon erlöst, ständig den abgespulten Draht beobachten zu müssen, indem wir mit Machine Learning auf Videodaten die Fehlerzustände erkennen. Um den richtigen Ansatz zu finden, haben wir auch mit 2D-Laserscanner, Stereo- und Time-of-Flight-Kameras experimentiert, letztlich waren traditionelle High-Speed-Kameras aber am überzeugendsten.
„Eigentlich nicht. C++ verwenden wir, wenn wir für bestimmte Code-Teile die Performanz einer kompilierten Sprache benötigen. Unsere Lieblingssprache ist ganz klar Python. Die in Docker laufenden Microservices unseres Level2-Framework Insight360 haben wir in Python entwickelt.
Um ein wenig SQL kommen wir hier und da nicht herum, mit spitzen Fingern haben wir auch schon mal C# angefasst. Man kann auch durchaus mal andere Sprachen ausprobieren. Für ein Schnittstellen-Tool zwischen einer SQL-Datenbank und einer Rockwell-Steuerung haben wir z.B. mal Go genutzt. Letztendlich benutzen wir einfach das, was die beste Plattform für die Lösung bietet. Beim UI ist das mittlerweile fast immer Web mit Javascript.“
„Ja, schon allein weil es das Deployment enorm erleichtert, nur einen Server aktualisieren zu müssen, und der Client braucht nur einen Browser. Ich glaube, wir sind, was die Einführung von Web-Technologie in der Walzwerksautomatisierung betrifft, auch ganz vorne mit dabei. Da sind bisher noch klassische Client-Server-Anwendungen verbreitet. Und dank Technologien wie Vue und transpiliertem Javascript funktioniert das inzwischen sehr gut.“
„Das ist je nach Produkt und Projekt ganz verschieden. Im Mittel ist es etwa 30% Frontend, 70% Backend. Unsere Frontends sind in der Regel auch eher für High-Level-Funktionen und nur mittelbar produktionsrelevant. Die unmittelbar auf die Produktion einwirkenden HMIs machen die Kollegen der Automationsabteilung.“
„Das hat mehrere Aspekte. Zum einen erarbeiten wir die Lösungen entlang an konkreten Kundenprojekten. Das heißt natürlich, dass unser Kunde mit der Lösung glücklich sein muss. Auf der anderen Seite haben wir aber auch das Ziel, Produkte zu erstellen, die sich mit möglichst geringem Aufwand bei neuen Kunden einsetzen lassen. Das erfordert immer die Balance aus Generik und konkreten Kundenanforderungen. Zu guter Letzt wollen auch wir glücklich sein. D.h., unsere Software muss sich auch für uns als Entwickler gut anfühlen.“
„Software muss primär nicht für Computer, sondern für Entwickler geschrieben sein. Gut lesbar und schnell verstehbar. Das TAO of Python beschreibt das ganz gut:
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated. Der nächste wichtige Punkt ist die Wartbarkeit. Unsere Produkte wachsen mit den Kundenprojekten. Es gehört zu unserem täglichen Geschäft, dass wir unsere bestehenden Lösungen um neue Features erweitern. Das muss die Software erlauben. Sie muss gut refactorbar sein. Damit ergeben sich eigentlich schon die ganzen anderen Best Practices der Softwarearchitektur und -entwicklung wie von selbst. Bei wachsender Software passiert es natürlich auch, dass man mit Bereichen nicht mehr 100%ig zufrieden ist. Dann muss man das natürlich angehen, also auch querschnittliche Themen und Refactorings aktiv mit einplanen. Ein sehr wichtiger Aspekt ist das berechtigte Gefühl von Sicherheit: Keiner möchte schlecht schlafen nach einem Kundendeployment. Also nutzen wir Continuous Integration (CI) mit automatisierten Tests und Kunden-spezifischen Integrationsumgebungen. Das ist wichtig, um z.B. auch sicherzustellen, dass notwendige Datenmigrationen mit kundenspezifischen Daten sauber funktionieren. Deployments laufen auch immer vollständig automatisiert und reproduzierbar ab.“
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated. Der nächste wichtige Punkt ist die Wartbarkeit. Unsere Produkte wachsen mit den Kundenprojekten. Es gehört zu unserem täglichen Geschäft, dass wir unsere bestehenden Lösungen um neue Features erweitern. Das muss die Software erlauben. Sie muss gut refactorbar sein. Damit ergeben sich eigentlich schon die ganzen anderen Best Practices der Softwarearchitektur und -entwicklung wie von selbst. Bei wachsender Software passiert es natürlich auch, dass man mit Bereichen nicht mehr 100%ig zufrieden ist. Dann muss man das natürlich angehen, also auch querschnittliche Themen und Refactorings aktiv mit einplanen. Ein sehr wichtiger Aspekt ist das berechtigte Gefühl von Sicherheit: Keiner möchte schlecht schlafen nach einem Kundendeployment. Also nutzen wir Continuous Integration (CI) mit automatisierten Tests und Kunden-spezifischen Integrationsumgebungen. Das ist wichtig, um z.B. auch sicherzustellen, dass notwendige Datenmigrationen mit kundenspezifischen Daten sauber funktionieren. Deployments laufen auch immer vollständig automatisiert und reproduzierbar ab.“
„Das ist sehr unterschiedlich, je nachdem was das Problem ist. Es gibt Produkte, da ist uns schon im Vorfeld sehr klar, wie die Lösung grob aussehen wird. Die sind sehr gut schätz- und planbar. Wir haben aber auch Themen, die wirklich erst einmal Forschungsarbeit benötigen. Für eines unserer Produkte haben wir zum Beispiel 3 Jahre gebraucht, bis wir den richtigen Ansatz gefunden haben. Es gibt also kein one-size-fits-all Vorgehen für ein Projekt. Wir takten uns wöchentlich und nutzen Kanban, so können wir immer die dringenden Sachen angehen, ohne die wichtigen Sachen liegen zu lassen. Bei großen Themen mit fixen Deadlines fahren wir natürlich das komplette Programm mit Restaufwandsschätzungen, Burn-down-charts und allem drum und dran. Also wie immer: Die Lösung muss zur Aufgabe passen.
Wir besetzen die Themen auch immer so früh wie möglich mit mehreren Köpfen. Das hat sich bewährt und bringt viele Vorteile: Keine Kopfmonopole, homogenere Ergebnisse und – ganz wichtig – keine Anrufe bei Krankheit oder im Urlaub.“