Software

Von On-Premises zu Cloud - Die Transformation der Qualitätssicherung

13 Juli 2023 written by INTRAVIS
Transformation from on premises solutions to cloud solutions with Intravis Vision Inspection

Dieses Interview entstand für die Website Entwicklerheld.de, mit deren freundlicher Genehmigung wir es hier veröffentlichen dürfen.

Dev-Interview mit Jonas Deitmerg
In den Dev-Interviews spricht EntwicklerHeld mit Entwickler:innen bei unterschiedlichsten Unternehmen. Heute spricht Ilja Bauer, der CTO und Co-CEO von EntwicklerHeld, mit Jonas Deitmerg, Technical Lead bei INTRAVIS – von Dev zu Dev.

 

Ilja: Hallo, Jonas! Ich bin Ilja, einer der Gründer von EntwicklerHeld. 

Jonas: Hallo, Ilja! 

Ilja: Hi, freut mich, dass du hier zu unserem Dev-Interview gekommen bist! 

Jonas: Ja, ich bin sehr gespannt! Wir suchen ja schwerpunktmäßig in dem Bereich, für den ich mittlerweile zuständig bin. Seit drei Wochen bin ich nämlich Technical Lead von dem Team, das bei uns Cloud- und Industrie-4.0-Produkte entwickelt. 

Ilja: Dann erzähl doch direkt, was man so bei INTRAVIS macht. Du hast ja schon deine leitende Position erwähnt. 

Jonas: INTRAVIS ist ein Sondermaschinenbauer. Wir bauen industrielle Maschinen und Anlagen im Kunststoffverpackungsbereich. Außerdem entwickeln wir die passende Software. Eine besonders große Rolle spielt in diesem Bereich die Qualitätssicherung und Prüfung. Seit 30 Jahren ist das auch unser Fokus, mit welchem wir groß geworden sind und welcher uns auszeichnet. Die meisten unserer Prüfungen basieren auf Bildauswertung und Bildverarbeitung. 

Eine ausgezeichnete Produktqualität führt zu deutlich weniger Reklamationen und zu einer besseren Reputation. Durch den Einsatz von bis zu 100% Recyclingmaterial wird der Fertigungsprozess anspruchsvoller und unsere Inspektionssysteme helfen dabei den Prozess zu optimieren, Material einzusparen und damit letztendlich die Nachhaltigkeit zu steigern. Mittels klassischem Kantenfinder bzw. Kreisfinder werden Objektbreite bzw. Durchmesser bestimmt. Mittels moderner Anomalie-Erkennung werden Produktionsfehler wie z.B. Flecken erkannt.

Natürlich haben wir uns auch neben der Qualitätssicherung mit der Zeit sehr viel Expertise angeeignet. Zum Beispiel in der Maschinensteuerung. Das ist eine Welt für sich. Aber wir haben auch Automatisierungsgruppen bei uns in der Software, die mit SPS arbeiten. Auch eine geschlossene Welt, die für mich sehr fremd ist. (Lacht) Dann gibt es auch noch Human-Machine-Interfaces, womit man Nutzern eine Oberfläche zur Verfügung stellt, welche in der industriellen Welt auch ganz anders aussieht, als man es von einer App aus dem privaten Bereich kennt.

intravis-working-situation-employee-old-young-production-comissioning-software-1920x1280px

Ilja: Das glaub ich. Läuft die Sofware direkt dort vor Ort, quasi inhouse? Viele Unternehmen haben die Server ja abgeschottet und will man da etwas installieren, muss man immer vor Ort sein. Das macht es ja schwieriger. 

Jonas: Oh, so weit war ich noch gar nicht mit der Historie von INTRAVIS. Also alles, was wir viele Jahre gemacht haben, lief in der Maschine ab. In der Maschine befindet sich ein Hochleistungsrechner, auf welchem alles passiert. Es gibt vielleicht eine Internetverbindung für das Team, um sich mit der Maschine zu verbinden, aber das war auch das einzige in Bezug auf "Connected". IoT kann man dazu nicht sagen. Dann kam uns aber vor vielen Jahren die erste Produktidee für eine webbasierte Anwendung, um die Daten über die Produktion zu visualisieren. Das war dann eine On-Premises-Installation. Alles war auf den Servern unserer Kunden mitsamt Datenbank aufgesetzt. Aber davon sind wir mittlerweile weg. Jetzt haben wir den IntraVisualizer, der komplett bei Amazon Web Services (AWS) läuft. Die Maschinen wurden befähigt, eine Verbindung herzustellen und Daten hinzuschicken. Die Daten können wir in der AWS-Welt weiterverarbeiten und ein Frontend zur Visualisierung zur Verfügung stellen.

Ilja: Und wie war dein Werdegang bei INTRAVIS? 

Jonas: Die meiste Zeit war ich selbst bei INTRAVIS Embedded System Engineer, also einem hardwarenahem Bereich und habe auch Elektronik entwickelt. Es hat sich allerdings immer mehr in Richtung Firmware / Embedded Linux entwickelt. Wir betreiben unsere Maschinen mit einem Embedded-Linux-Rechner. Und der jongliert sozusagen mit diesen Welten, die ich beschrieben habe. Zum einen die Industrieumgebung, wo alles superrobust und lange funktionieren soll und am besten nie geupdatet wird, weil: »Never change a running System!«. Zum anderen die Cloud-Welt, die total schnelllebig ist und ein Update viel schneller geht, was viel näher am Puls der Zeit ist. Für das Vermitteln zwischen diesen zwei Welten war ich dann mit dem Edge Device zuständig. 

Ilja: Wie ging es dann weiter? 

Jonas: Dann habe ich mir AWS angeeignet. Und vor drei Wochen habe ich die technische Leitung übernommen. Ich habe schnell gemerkt, dass Frontend-Geschichten aber gar nicht meine Welt sind. 

Ilja: Okay, das klingt spannend. Weil du ja grad AWS gesagt hast. Manchmal sagen die Firmen ja einfach: »Wir nutzen AWS – sprich, wir haben da VMs laufen und machen das gleiche, was wir vorher gemacht haben.« Wie ist das bei euch? Nutzt ihr die Möglichkeiten, die AWS zur Verfügung stellt? 

Jonas: Mit allen Vor- und Nachteilen nutzen wir die AWS-Services, zu 100 Prozent. Die Vorteile überragen die Nachteile aber immens, zum Beispiel komplett skalierbare Zeitserien-Datenbanken. Man schüttet einfach Daten rein und die werden weggeschrieben.

Ilja: Und wie ist das auf der Kundenseite? Merken die, dass ihr in der Cloud lauft? Nicht nur technisch, sondern auch von der Abrechnung her? Pro Prüfprozess oder dergleichen? 

Jonas: Das Lizenzierungsmodell ist so ausgelegt, dass wir eine jährliche Lizenz abrechnen. Ein größeres Problem ist, den Kunden davon zu überzeugen, dass die Daten ihr Werk verlassen. Es gibt Kunden, die wollen das gar nicht. Nach der Regel: »Kein Bit verlässt diese Halle!«. Wir sind Sondermaschinenbauer, nach wie vor! Damit verdienen wir unser täglich Brot. Mit dem IntraVisualizer bekommt der Kunde aber eine zusätzliche Software-Lösung zur Analyse der Performance seiner Produktion.

Ilja: Müsst ihr auch bedenken, dass das Produkt in der Werkshalle beim Kunden, also On-Premises, laufen kann? Oder sagt ihr, die Zukunft entwickelt sich ohnehin in Richtung Cloud und dass ihr euch auf die Early Adopter konzentriert, für die das okay ist? Bei den anderen kann ja noch weiter das alte On-Premises-System genutzt werden. Wenn ich jetzt zum Beispiel als Entwickler oder Entwicklerin bei euch anfangen würde, wie viel Legacy hätte ich dann? 

Jonas: Die alte On-Premises-Version läuft nur noch bei Kunden, die diese schon haben und wird da auch noch supportet. Wir verkaufen die alte Version nicht mehr neu. Wir haben die Entscheidung getroffen uns in Richtung Cloud weiterzuentwickeln und die Kunden davon zu überzeugen, dass dies die Zukunft darstellt.


Die höchste Devise ist immer: »Die Produktion muss weiterlaufen!«


Ilja: Man kann dann ja auch einfacher Updates einspielen, weil man nicht unbedingt vor Ort sein muss, oder? 

Jonas: Ja, das ist das genau die Motivation für die Edge-Device-Komponente. Wir können ja nicht einfach auf einem Gerät in der Produktionslinie ein Update aufspielen und dann steht die Produktion. Das kostet in ein paar Minuten 3.000 €, in ein paar Stunden 10.000 € und dann sind es schnell 100.000 €. Die höchste Devise ist immer: »Die Produktion muss weiterlaufen!«. Mit dem Edge-Device haben wir uns da abgesichert. Hin und wieder haben wir Kunden, die bei einer Cloud-Lösung Bedenken haben. Aber das wird zum Glück immer weniger, weil wir schon viele Erfahrungen gesammelt haben und alle Bedenken klären können. 

Ilja: Was ich ja auch interessant finde: Ihr seid ja in der Industrie in der Qualitätssicherung. Wie sichert ihr die Qualität eurer eigenen Software? Woher kommen neue Features? Wo kommt zum Beispiel der Code hin? Wie wird er ausgerollt? Passiert das alles automatisch oder manuell? 

Jonas: Die nächsten Features, an denen wir arbeiten, resultieren vor allem aus Feedback von Kunden und den Anforderungen des Marktes. Die Features werden dann diskutiert, wobei auch unser Geschäftsführer und das Produktmanagement eingeschlossen werden. In Gesprächen kristallisieren wir die grobe Richtung heraus, sodass wir wissen, wohin es gehen soll: zum Beispiel sehr spezifische Notifications, wenn an der Maschine etwas fehlerhaft läuft. Das brechen wir mit unserer Iteration auf einen Meilenstein herunter. Das brechen wir weiter auf GitLab-Issues herunter. Das ist unser Format, mit dem ein Entwickler dann auch gut arbeiten kann. Dann schreiben wir Spezifikationen für die Schnittstellen zwischen den einzelnen Komponenten. Wir haben in der Vergangenheit viel gelernt, denn früher hat jeder Entwickler an verschiedenen Komponenten gearbeitet und erst dann haben wir uns um die Zusammenarbeit der Komponenten gekümmert. Kurz vor Release kann der Entwickler ein Feature implementieren und alles testen. Danach wird das neue Feature ausgerollt.

Ilja: Klingt nach einem sehr agilen Vorgehen und man kann schnell loslegen. Und man sagt ja immer, wichtig ist, das Richtige zu bauen, nicht irgendwas zu bauen! Macht man am Anfang schon Fehler, kann ja hinten auch nichts Gutes rauskommen. Die Bedürfnisse der Anwender sind unterschiedlich und die müssen berücksichtigt werden. 

Jonas: Das ist auch für unser Team relevant. Unser Hauptentwickler hat eine enge Feedback-Schleife und ist viel mit Kunden in Kontakt und im Werk. Und ich würde das gern im Team implementieren: Wir müssen noch näher an die Kunden! Das ist eines meiner Ziele!

Ilja: Schön, finde ich gut! Kommen wir zu euren Programmiersprachen. C++, Frontend, React, Javascript, das steht in eurem Profil. Mit Frontend lasse ich dich zufrieden, weil du gesagt hast, du möchtest vielleicht nicht darüber reden. (Beide lachen) 

Jonas: Ich denke, dass man einfach ein guter Allrounder sein sollte. Im Zusammenhang mit AWS gibt es gar nicht mehr bestimmte Kerntechnologien, die man da beherrschen muss. An einer Stelle kann man etwas mit Python programmieren. An einer anderen muss man in YAML deklarieren, wie etwas funktionieren soll. Oder es muss eine eigene SQL Engine aufgebaut werden und der Entwickler muss sich irgendwie deren Syntax beibringen, die aber nicht dokumentiert ist. Es ist also nicht so, dass ein Entwickler perfekt geeignet ist, wenn er die zwei Kerntechnologien C++ und JavaScript beherrscht. Es gibt also keine Technologie A und B, mit der man für alles gewappnet ist.

Ilja: Also muss man das beste Werkzeug für den Job suchen oder führt das zu zu viel Chaos?

Jonas: Zum Glück haben wir nicht so viele Unstimmigkeiten an den Stellen, wo mehrere Leute wirklich an demselben Code arbeiten. Und wenn man nicht am selben Code arbeitet, definiert man die Schnittstellen dazwischen und dann funktioniert auch alles einwandfrei.

Ilja: Ja, cool, verstehe ich. Ich habe am Ende immer eine provozierende Frage. Vielleicht hast du ja mitgekriegt, dass der CTO von Azure gesagt hat, dass C++ tot sei. Rust sei das neue C++ und jeder sollte nur noch in Rust schreiben. C++ hat seine Probleme, ansonsten wäre Rust ja nicht entstanden. Wie siehst du das?

“C/C++ is deprecated” Quelle

Jonas: Persönlich bin ich begeistert! Ich habe letztes Jahr ein Embedded-Projekt bei Intravis gestartet, welches auf Rust basiert. Man wird bei Rust regelrecht gezwungen, die Dinge richtig zu machen. Man schlägt sich mit dem Borrow-Checker herum, aber wenn dieser zufrieden ist, funktioniert auch alles. Aber es ist auf jeden Fall eine große Lernkurve! In Bezug auf Firmen im Embedded-Bereich gibt es durchaus einzelne Projekte, die mit Rust sehr gut umgesetzt werden können. Allerdings haben wir wenig Systemprogrammierung, wo Rust seinen Schwerpunkt hat, weshalb ich keine sehr große Notwendigkeit für Intravis sehe Rust zu benutzen. Trotzdem denke ich, dass C++ auch nicht die Zukunft sein wird.

Ilja: Schön, dass jemand mal sagt, dass es ganz, ganz langsam sterben wird.

Jonas: Ich komme aus der Elektronik-Welt und bin in die Cloud-Welt gewechselt. An dieser Achse kann man die Schnelllebigkeit bemessen. In der Elektronik-Welt gibt es Innovationen, aber ganz gemächlich. In der Cloud-Welt sieht dies komplett anders aus. Im Frontend fällt es kaum auf, aber die Welt ist extrem schnelllebig. Die Entwickler:innen sind es gewohnt alle 6 Monate das Framework zu wechseln. (Lacht) 

Ilja: Und dann bleibt nur noch eine abschließende Frage: Kaffee oder Tee? 

Jonas: Ich trinke Kaffee. 

Ilja: Sehr gut! 

Jonas: Aber ich weiß, dass wir sehr tolerant sind in der Firma und eine große Tee-Schublade haben.

Ilja: Ja, Toleranz ist immer gut! (Beide lachen) Jonas, es hat mir Spaß gemacht! 

Jonas: Mir auch, danke!