DevOps für Maschinenbauer

Einleitung

“Häufige Releases und Bugfixes? Und das bei Maschinen, die im Feld oder in der Produktion bei Kunden stehen? Das funktioniert wohl bei den großen Internetplattformen, aber nicht bei uns.”

So oder so ähnlich hört man es bei vielen Maschinenbauunternehmen, wenn man sie nach der Häufigkeit der Software-Releases fragt. Besonders wenn es um Updates bei Maschinen geht, die im Feld oder in der Produktion des Kunden stehen. Einer der Hauptgründe, warum man häufige Releases fürchtet ist ein Stillstand oder ein Ausfall der Maschine beim Kunden, was wiederum zu Produktionsausfällen und Frust führen kann. Gemeinhin gilt die Devise: “Never touch a running system”. Lieber einmal zu wenig ein Update einspielen, als Gefahr laufen, Stillstandzeiten bei produktiven Maschinen hervorzurufen.

Doch der Wandel durch die Digitalisierung verlangt zukünftig zügig neue Releases ausrollen zu können; sei es für Fehlerbehebungen oder um neue, innovative digitale Funktionen nachzuliefern, die der Kunden umgehend nutzen kann. Hierbei können vollkommen neue Geschäfts- und Erlösmodelle für die Unternehmen entstehen, indem man z.B. digitale Funktionen kostenpflichtig gestaltet.

Aktuelle Herausforderungen und Probleme

Getrieben durch die digitale Transformation nimmt Software einen immer größer werdenden Anteil an der Wertschöpfung ein

Die digitale Transformation und die Digitalisierung im Allgemeinen bedingt, dass der Anteil der Software im Produkt beständig wächst bzw. wachsen sollte. Dies führt im gleichen Maße dazu, dass Software einen immer größer werdenden Anteil an der Wertschöpfung einnimmt. Eine der wesentlichen Herausforderungen hierbei ist, dass man als Maschinenbauer in der Lage sein muss, diese Software - genauso wie den klassischen Maschinenbau - zu entwickeln, weiterzuentwickeln, zu optimieren und zu betreiben. Oft fehlt es an der entsprechenden Kompetenz, die nicht so schnell mitwächst. Hinzu kommen klassische Managementmethoden (z.B. Wasserfall oder Stage-Gate), die schnelle und agile Entwicklungszyklen nicht ermöglichen.

Software lebt und muss beständig weiter entwickelt werden

Software ist kein statisches Produkt oder eine Komponente, die man in der Maschine verbaut und anschließend nie wieder anfassen muss. Software ist lebendig und bedarf kontinuierlicher Pflege und Weiterentwicklung. Eingesetze Softwarekomponenten, Betriebssysteme und Open-Source oder Drittsoftware müssen immer auf einem aktuellen Stand gehalten werden, um mögliche Sicherheitslücken gering zu halten (Stichwort: Information Security).

Mangelnde Qualität der Software und daher mangelndes Vertrauen

Oft wird Software zwar gut entwickelt, doch beim Testen der Software treten häufig Lücken auf. “Mal eben ein neues Feature entwickeln - das habe ich schnell gemacht”. Wer kennt das nicht: Aus einem aktuellen Kundenbedürfnis heraus schnell in die Entwicklungsabteilung rufen, was noch gebraucht wird. Das Zeitfenster: Wie immer kurz. Und schon ist es passiert! Der entsprechende Test (Unit Test) für das neue Feature wurde nicht gleich mitgeschrieben. Ebenso hat man nicht geprüft, wie die neue Version der Software mit anderen Softwarebausteinen interagiert. Das System macht am Ende nicht, was es soll, es entsteht Frust und führt zu fehlendem Vertrauen in die Software. Man scheut daher das Remote-Update der Maschinen beim Kunden.

Erhöhte Servicekosten durch Vor-Ort-Einsätze

Die zuvor beschriebenen Qualitätsprobleme führen zu erhöhten Servicekosten, da Fehlerbehebungen und Software-Updates vor Ort eingespielt werden müssen, damit auf eventuelle Fehlfunktionen reagiert werden kann. Oftmals kommt hinzu, dass es zwar eine Remote-Verbindung zur Maschine gibt, diese aber i.W. nur einen Fernzugriff via z.B. TeamViewer zulässt und keine Updatefähigkeit besitzt. Somit können schnelle Bug Fixes nicht zeitnah ausgeliefert werden. Fehlerbehebung kann so nur stark sequentiell bertrieben werden, da jede Maschine individuell behandelt werden muss.

Keine Skalierung der Produktion und Produkte durch manuelle Prozesse (z.B. Einrichtung und Erst-Inbetriebnahme)

Ist die Software erst einmal entwickelt, ist der nächste Schritt diese in die Produktion zu überführen. Dabei ist es nicht ungewöhnlich, dass jede Maschine kundenindividuell parametrisiert und konfiguriert werden muss. Der klassische Weg nutzt hierfür ein Speichermedium wie etwa einen USB-Stick. Dieser beinhaltet die “Standard-Software” die manuell installiert werden muss. Während des Installationsprozesses müssen dann die spezifischen Parameter und Konfigurationen manuell eingestellt werden. Dies führt zum einen zu einer geringerer Effizienz und bietet zum anderen aufgrund des manuellen Prozesses Potenzial für Fehler. Ein solcher Prozess skaliert nicht.

Lösungsansätze

Um dem stetig wachsenden Anteil der Software an der Wertschöpfung entgegenzutreten, sowie zeitnahe Fehlerbehebungen und Updates für Maschinen im Feld / in Produktion sicherzustellen, empfiehlt sich die Etablierung eines DevOps-Prozesses im Unternehmen. DevOps vereint die Begriffe “Dev” (Development, Entwicklung) und “Ops” (Operations, Vorgänge). DevOps vereint Menschen, Prozesse und Technologien.

DevOps wirkt sich durch die Planungs-, Entwicklungs-, Bereitstellungs- und Betriebsphasen auf den Anwendungslebenszyklus aus. Jede Phase hängt von den anderen ab, keine der Phasen ist rollenspezifisch. In einer idealen DevOps-Kultur ist jede Rolle in bestimmtem Ausmaß an jeder Phase beteiligt. Dies führt zu einer kürzeren Time-to-Market, erhöhter Qualität, erhöhtem Wissenstransfer und der Fähigkeit agil auf Probleme und Herausforderungen zu reagieren.

Ein wesentlicher Aspekt bei der Entwicklung neuer Software bzw. der Weiterentwicklung ist das Testen. Das Testen von Software muss gerade bei einem Maschinenbauer auf verschiedenen Ebenen ablaufen:

• Unit-Tests: Jeder Software-Baustein muss entsprechend testbar sein und mit einem entsprechenden Testprogramm versehen sein. So können schon erste Fehler im Quellcode selber erkannt werden.
• Integrations-Tests: Bei den Integrationstests werden unterschiedliche Softwarebestandteile zusammengeführt und integriert. Hier soll sichergestellt werden, dass die unterschiedlichen Komponenten nahtlos zusammenarbeiten. Besonderes Augemerk richtet sich hierbei auf die Integration von Low-Level-Software (z.B. SPS-Software) und der entsprechenden Bediensoftware (Human Machine Interface).
• System-Tests: Diese Testebene ist insbesondere für Maschinenbauer essentiell. Auf dieser Ebene wird das gesamte System bestehend aus Software und Hardware miteinander getestet (z.B. SPS mit entsprechender SPS-Software + Bedienterminal mit entsprechender Bediensoftware). Hier soll ausgeschlossen werden, dass spezifische Hardwarekonfigurationen dafür sorgen, dass die Software nicht ordnungsgemäß funktioniert.
• Akzeptanz-Tests: Nachdem die Software in Produktion gebracht wurde und mit individuellen und kundenspezifischen Parametern und Konfigurationen versehen wurde, wird das Gesamt-System nochmals final getestet

Um einen nahtlosen Übergang von der Entwicklung in die Produktion und von dort in den After Sales zu schaffen, müssen Prozesse automatisiert werden. Ein erster Ansatzpunkt ist das sog. Continuous Integration. Bei jeder Änderung des Quellcodes wird ein automatisierter Integrationstest durchgeführt (Unit Tests werden ebenfalls vorab durchgeführt). Dies führt zu frühzeitiger Erkennung von Problemen im Entwicklungsprozess. Der nächste Schritt ist das Continuous Deployment. Es werden kontinuierlich produktive Softwarestände generiert, die für Produktion und Service verfügbar sind.

In der Produktion bedeutet das, dass man in der Lage ist, kundenspezifische Software automatisiert auf die Hardwarekomponenten der Maschine zu bringen und dort zu installieren. Spezifika können z.B. Passwörter, Schlüssel, Parameter für die SPS, etc. sein. Hierfür bringt man im “Provisionierungsprozess” die Standard-Software mit den entsprechenden Spezifika zusammen. Mit Hilfe automatisierter Tests kann dann nach Installation die Richtigkeit geprüft werden.

Insbesonders der After-Sales Bereich profitiert von der zentral verwalteten Software und den zentral verwalteten Spezifika. Durch die agile Arbeitsweise können Fehler schnell behoben, getestet und ins Feld gebracht werden. Hierzu ist es notwendig, die Maschinen und Anlagen online verfügbar zu haben. Auf diese Weise ist es auch möglich, z.B. Security-Patches von Betriebssystemen zeitnah auszurollen. Vorteil dieser Methode ist das parallele Vorgehen, im Vergleich zur sequentiellen und manuellen Vor-Ort-Tätigkeit.

Mehr über Maschinenbau erfahren Sie im BlogPost Plattformökonomie im Maschinenbau.

Fazit

Um als Maschinenbauer die digitale Transformation zu meistern und der Erhöhung der Software am Wertschöpfungsprozess Rechnung zu tragen, ist die Einführung eines DevOps-Prozesses und einer DevOps-Kultur unausweichlich. Das Vertrauen in die Qualität und Fähigkeit der Software muss erheblich gestärkt werden, um Online-Updates von Maschinen im Feld und in der Produktion zu ermöglichen. Nur so kann die Effizienz erhöht und die Produktion skaliert werden.