Für die Automatisierung unverzichtbar

Dr.-Ing. Gerald Hemetsberger, camLine Datensysteme GmbH, Petershausen

In der Regel besteht ein SW-Lebenszyklus aus den fünf Phasen Spezifikation, Entwicklung, Inbetriebnahme, operativer Einsatz und weiterer Ausbau in Form von neuen SW-Versionen. Wie gut oder schlecht die Software für den Fertigungsbetrieb tatsächlich geeignet ist, macht sich häufig erst in späteren Phasen bemerkbar, wenn das SW-System rund um die Uhr im Einsatz ist. Wer kennt nicht das Dilemma, dass das System offiziell abgenommen ist und der operative Umgang die Schwachpunkte des Systems ans Tageslicht fördert? Oft ist zu diesem Zeitpunkt das Budget erschöpft, der SW-Anbieter nicht mehr vor Ort und substanziell korrigierende Maßnahmen sind nicht mehr vertretbar.

Mit der Systemabnahme ist ein SW-Projekt beendet, und die intensive Zusammenarbeit mit dem SW-Dienstleister hört auf. Damit ein SW-bedingter Produktionsausfall nicht eskaliert, ist Support für den 24-Stunden-Betrieb erforderlich. Der Fertigungsbetreiber benötigt vom Systemhaus eine Rufbereitschaft mit zugesicherten Reaktionszeiten. Kurzfristige Erreichbarkeit von SW-Experten ist zentraler Gegenstand eines eigenen Hotline-Support-Vertrages oder Bestandteil von Verträgen zur Software-Releasepflege.

Die Rufbereitschaft hilft im Notfall nur dann, wenn der SW-Experte sofort aktiv werden kann. Dies ist in der Regel nur möglich, wenn er von seinem Arbeitsplatz aus das SW-System “remote“ analysieren kann. Es ist also darauf zu achten, dass die Software für Fernwartungsarbeiten ausgelegt ist.

Zur zielführenden Fehlersuche muss die Software Werkzeuge bereitstellen, die das SW-System im laufenden Betrieb analysieren. Die Tools dokumentieren und visualisieren situationsbezogen verschiedenste Systeminformationen, ohne den Betrieb zu beeinträchtigen.

Die Analysedaten sollten in klar strukturierten Protokolldateien abgelegt werden, die einfach durchzusehen sind. Für die zeitnahe Diagnose lassen sich die Online-Tools im Hintergrund ein- und ausschalten. Hierzu muss nur der Betriebsmodus der laufenden Software verändert werden. Unterbrechungen wie Stoppen und erneutes Starten der Software sind unbedingt zu vermeiden. Bei fertigungskritischer Software tut ein Boot der Produktion nie gut.

Üblicherweise werden von der hausinternen IT-Abteilung Überwachungssysteme eingesetzt, um die Verfügbarkeit der SW-Systeme zu gewährleisten. Durch einfache Werkzeuge muss sich das SW-System in die Betreuung integrieren lassen, um die automatische Benachrichtigung von Hotline und Support zu ermöglichen.

Es ist kaum zu umgehen, die Software nach Fehlerkorrekturen (Bug Fixing) oder bei Neuerungen zu aktualisieren. Man steht also immer wieder vor dem Problem, die aktualisierte Software in das laufende Produktivsystem bei möglichst geringen Unterbrechungszeiten einzuspielen.

Am Besten ist es, den SW-Update in zwei Schritten durchzuführen: Zunächst wird die neue Version auf einer Testumgebung installiert, wo sie parallel zum Produktivsystem hinreichend lange läuft und man so ihre Stabilität sicherstellt. Im Anschluss daran erfolgt die eigentliche Migration auf das Produktivsystem.

Die Unterbrechung des laufenden Betriebs hängt wesentlich davon ab, welcher Aufwand erforderlich ist, um die Updates auf den verschiedenen Computern durchzuführen. Ist die Software modular aus einzelnen Komponenten aufgebaut, dann brauchen nur die betroffenen Teilkomponenten ersetzt zu werden. Ist eine zentrale SW-Verwaltung möglich, lassen sich von einem Arbeitsplatz aus nicht nur die Server, sondern auch die vielen in der Fertigung verteilten PC-Clients modifizieren µ kein Stress durch lange Spazierwege im Maschinenpark.

Im Fertigungsumfeld hört man oft noch die Ansicht:: “Den ganzen Aufwand mit Support und Updates kann man sich doch sparen. Wir investieren in neueste Technik und die sollte für die nächsten Jahre halten. Wir machen uns doch nicht von einem SW-Server abhängig. Für den Serverausfall gibt es Offline-Notstrategien, durch die wir für gewisse Zeit auch ohne Serverzugriff produzieren können.“

Der Blick in die Fertigungen ergibt jedoch ein anderes Bild. In der Realität müssen sich Fertigungsteams in heterogen gewachsenen Systemlandschaften zurechtfinden. Ständig gehen irgendwelche Komponenten kaputt und müssen durch neue ersetzt werden, von denen am Markt nur die jeweils aktuellste erhältlich ist. Und dies gilt nicht nur für Hardware. Auch bei Software ist der Support für Betriebssystem- und Datenbank-Versionen zeitlich begrenzt. So kommt es zwangsläufig zu schleichenden Veränderungen, die niemand so richtig haben will, auf die man sich aber im Vorhinein einstellen muss.

Offline-Notstrategien sind immer mit hohem Aufwand für alle Beteiligten verbunden. Wenn der Server nicht zur Verfügung steht, heißt dies Chaosgefahr. Die übergreifende Kommunikation funktioniert nicht mehr und muss von den Teams zusätzlich getragen werden. Großer personeller Einsatz ist erforderlich, denn vor Ort und unter Zeitdruck ist das Umschalten auf die Notstrategie nur mit spezieller Autorisierung erlaubt. Die Erfahrung zeigt, dass es wirtschaftlicher ist, in zuverlässige Software und SW-Strategien zu investieren.

Will man hochverfügbare Software zentral im Griff haben und SW-Komponenten unabhängig voneinander erneuern, bietet sich eine SW-Architektur an, die aus drei Schichten besteht. Die erste Schicht steht für zentrale Datenhaltung in Form einer Datenbank. In der zweiten Schicht liegt die eigentliche Anwendung, deren zentrale Server als “Business Logic“ den wesentlichen Funktionsumfang bieten und für die Kommunikation über das Netz sowohl zur Datenbank als auch zu den verteilten PC-Clients verantwortlich sind.

Die PC-Clients verkörpern die dritte Schicht. Diese hierarchisch gegliederte SW-Architektur kann auch ein heterogen gestaltetes und wechselndes Fertigungsumfeld problemlos bedienen. Durch clever gestaltete Modularität müssen immer nur die gerade betroffenen Einheiten ausgetauscht werden, wie dies für Hardware bekannt ist: Benötigt man mehr Speicher, wird in den Rechner einfach eine weitere Festplatte gesteckt. Analog hierzu braucht man bei steigendem Datenaufkommen nur einen weiteren SW-Server zu starten.

Möchte man eine dauerhafte Verbesserung von Qualität und Produktivität sicherstellen, ist neben der offensichtlichen SW-Funktionalität genauso das prinzipielle SW-Konzept sowie die Strategien des SW-Anbieters bezüglich SW-Verwaltung und Support zu betrachten. Nur durch Einbeziehung all dieser Faktoren lässt sich die für den 24-Stunden-Betrieb entscheidende Verfügbarkeit sicherstellen.

503