Die Umsetzung kreativer Automatisierungstechnik bedarf einerseits kreativen Freiraums, andererseits braucht es Grenzen; und Erfahrungen sollten nicht verloren gehen, denn dort setzen Normen an. Kombiniert mit begleitenden Vorschriften sind diese die Basis für eine möglichst neutrale und bereichsübergreifende Beurteilung des betroffenen Sachverhaltes. Im Bereich der Hardware geben Normen Mindestkriterien vor. Ein Puffer nach oben bringt Verfügbarkeit. Was die Software betrifft - ohne sie verlieren viele Hardwareprodukte ihren Charme - greifen Normen sehr unterschiedlich ein. Nimmt man zum Beispiel die Programmiersprachen, so empfinden Anwender Optimierungen und Ergänzungen kontraproduktiv.

Zwar stellen Softwarestandards eine Grundvoraussetzung für wieder verwendbaren Sourcecode dar; die eigentliche Wirtschaftlichkeit - also inwieweit eine effiziente Konstruktion und Produktion sowie eine systematische, robuste Instandhaltung der gelieferten Maschinen und Anlagen gewährleistet ist -, zeigt sich aber erst in der Architektur des gewählten Engineering-Werkzeuges. Ein Aspekt, der in diesem Kontext eine immer zentralere Rolle spielt, ist das Thema Diagnose und Systemtransparenz.

Mit Werkzeugen wie dem „System Diagnostic Manager“ steht dem Anwender eine breite Palette an Diagnosemöglichkeiten via Web für Hard- und Software zur Verfügung.

© B&R

Für eine Abschaltung gibt es viele Gründe - nicht jeder Maschinenstillstand ist auf eine Fehlfunktion der Maschine oder Steuerung zurückzuführen. Doch egal, wo die Ursache letztlich liegt, gilt es, Fehler so schnell wie möglich zu identifizieren, um geordnete und zuverlässige Maßnahmen zur Behebung der unerwünschten Situation ergreifen zu können. Diagnose über alle relevanten Komponenten hinweg - ob Hardware oder Software - ist hier das einzige Mittel.

Mit anderen Worten: Die volle Transparenz einer Automatisierungsarchitektur ist entscheidend - und zwar ohne Einschränkungen ob direkt an der Maschine oder über Fernzugriff mit entsprechenden Sicherheitsberechtigungen. Die meisten Engineeringwerkzeuge der Hersteller unterstützen die erforderlichen Arbeiten über dezentrale Strukturen vom Intranet bis hin zum Internet. Sicherheitstechnische Fragen lagern viele Unternehmen aus gutem Grund auf ihre IT-Strukturen aus. Genau an dieser Stelle setzen die Grenzen der „gut gemeinten" Lösungen ein. Denn wer Internet nutzen möchte, muss vorausschauend und konsequent arbeiten; andernfalls steht der geplante Kommunikationskanal im Ernstfall unter Umständen doch nicht zur Verfügung. Neben dem Kommunikationskanal muss der Anwender darüber hinaus die Notwendigkeit und den Nutzen des Hersteller- Werkzeuges für die unterschiedlichen Situationen kritisch hinterfragen.

Ist es wirklich zielführend, alle Diagnoseaufgaben auf Herstellerwerkzeuge zu projizieren? Egal welches Softwarepaket in Betracht kommt: Neben Basiskosten fallen direkte und indirekte Kosten für Instandhaltung und Schulung an. Diese Kosten lassen sich nachhaltig eliminieren, wenn das Automatisierungssystem einen werkzeugunabhängigen Diagnosezugriff bietet - etwa in Form eines webbasierenden Anwenderinterface wie dies zum Beispiel beim B&R-System der Fall ist. Damit wird jeder Standard-Webbrowser zu einem Diagnosewerkzeug und liefert dem Benutzer entscheidende Informationen über den Anlagenzustand. So selbstverständlich dies auch klingen mag: Möglich wurde dieser innovative Schritt erst auf Basis der IT-Standards - also auf der Grundlage entsprechender Normen.

Langfristig verfügbar und doch „up to date“

Ein weiteres Konstruktionskriterium ist das Thema langfristige Verfügbarkeit. Im schnelllebigen Zeitalter der Elektronik- Wegwerfgesellschaft denken viele Menschen eher in Monaten als in Jahren, um sich ein neues Produkt anzuschaffen. Der Betreiber einer Maschine erwartet jedoch eine Betriebszeit jenseits von 15 Jahren - dafür muss der Maschinenbau die Verantwortung übernehmen. Gleichzeitig besteht aber die Notwendigkeit, Innovationen umzusetzen, nachzurüsten, zu ergänzen und zu kombinieren. Steuerungs- und Automatisierungstechnik muss hier eine Antwort liefern.

Das heißt: Bereits bei der Entwicklung eines Produktes gilt es die Weichen zu stellen, um eine langfristige Verfügbarkeit zu gewährleisten. Klare Strategien in der Materialwirtschaft, in der Zusammenarbeit mit Lieferanten und vor allem im Design eines Systems sind die Grundsteine hierfür. Die Forderung nach langfristiger Verfügbarkeit gilt insbesondere für die teuerste Investition in eine Maschine oder Anlage - die Software! Die Einstellung „Die Software wird das Problem schon lösen" ist meist der Anfang eines langwierigen und nicht selten kostspieligen Weges. Waren es früher die Softwaretricks, die eine Wiederverwertbarkeit von Software verhinderten, so ist es heute die Komplexität der Lösungen. Die Verschränkung verschiedenster Softwarekomponenten in einem System ist für den Anwender oftmals völlig untransparent.

Zudem führt der vermeintlich einfache Hardwaretausch immer wieder implizit auch zu einem Softwaretausch. Mitunter bleibt das ohne Folgen. Manchmal resultiert daraus jedoch nach „Murphy's Law" eine große Krise mit einem wichtigen Kunden. Was lässt sich daraus lernen? Nur konsequent umgesetzte Softwarekonzepte - und dies gilt sowohl für Systemsoftware als auch für die Anwendungssoftware - beherrschen den Servicefall über viele Jahre. Gefragt sind demnach Systeme, welche die Gesamtsoftware einer Automatisierung als ein Paket verwalten. Das bedeutet: Firmware, Betriebssysteme und Anwendung sind auf Dauer miteinander „verheiratet" und selbst ein Hardwaretausch trennt diese Beziehung nicht auf. Vorsicht ist ebenfalls bei der Wahl der Entwicklungsmethode geboten: Die Verlockung zur schnellen Implementierung nach dem Motto „quick and dirty" scheint noch immer hoch zu sein. Dabei führen schlecht abgestimmte Anforderungsprofile gepaart mit mangelhaft dokumentiertem Source Code mit Sicherheit in das Chaos von Fehlerflut und Terminproblemen. Und so entpuppt sich nicht selten die schnelle Lösung sukzessive als Fehleinschätzung der Aufgabenstellung.

Die Erfahrung lehrt hingegen auch, dass sich selbst bei kleinen Projekten strukturierte Entwicklungsmethoden auszahlen. Und ob dabei tatsächlich ein Mehraufwand entsteht, hängt maßgeblich vom Programmierwerkzeug der Automatisierungsumgebung ab. Kurzum: Je mehr ein System abgedeckt, desto effizienter und professioneller arbeitet der Anwender.

Das Werkzeug bestimmt die Effizienz

Wie aber das richtige Werkzeug finden? In der Mechanik steht völlig außer Zweifel, dass man an einer Kreuzschlitzschraube nicht mit einem Klingenschraubendreher hantieren soll. Für Software scheint sich diese Selbstverständlichkeit - und zwar mit dem richtigen Werkzeug an die Aufgabe zu gehen - bislang nicht durchgesetzt zu haben. Diskutieren Experten noch immer über den Sinn der einen oder anderen Programmiersprache in der IEC 61131-3, erfinden andere bereits neue Dialekte, um Defizite des Standards auszugleichen. Dabei drängt sich die Frage auf: Sind neue Methoden in der Tat für den Maschinenbau gedacht, oder sind sie mehr der Versuch, eine bessere Kundenbindung zu erreichen?

Unter dem Gesichtspunkt „Kosteneffizienz" der Automatisierungsausrüstung und „langfristig verfügbar" lenken die Trends nach neuen „Sprachen" vom Kernproblem ab. Geht es nicht darum, Maschinen- und Anlagensoftware schnell zu modifizieren? Nur robuste Verfahren zur automatisierten Versionskontrolle jeder Änderung im Automatisierungssystem entlasten den Maschinenbauer wirklich. Der Begriff Automatisierungssystem steht hier nicht nur für die Anwendungssoftware, sondern bereichsübergreifend für Hardware, Systemsoftware, Firmware und Netzwerkkonfigurationen.

Selbstverständlich ist es sinnvoll, neue Verfahren zur Programmierung zu entwickeln. Die Softwarelandschaft kennt aus anderen Branchen durchaus bereits heute etablierte Standards, die sich in entsprechenden Fällen sehr effizient auf die Automatisierung übertragen lassen. Aber es müssen auch die Randbedingungen richtig eingebettet werden, ansonsten verpufft der vermeintliche Vorteil - vor allem bei neuen Verfahren.

Auf den Punkt gebracht: Ein Entwicklungswerkzeug der Automatisierung, wie etwa „Automation Studio" von B&R für Visualisierung, Steuerungssysteme, Motion, Netzwerktechnik und Safety, muss für den gesamten Lebenszyklus einer Maschine geeignet sein. Oder anders ausgedrückt: Oft steht heute noch die Entwicklung im Vordergrund; nicht minder wichtig ist jedoch die Zeit nach der Fertigstellung. Die betriebssichere, robuste Pflege eines Softwarestandes über mehr als 15 Jahre stellt spezifische Ansprüche, die ein und dasselbe Automatisierungstool abdecken muss.

Und wenn dann nach Jahren doch ein Retrofit erforderlich sein sollte, stellt sich die nächste Frage: Wie lässt sich Software für eine 15 Jahre alte Maschine ohne Maschinenstillstand nachrüsten und testen? Ganz einfach: Vorher an der Anlagensimulation in Betrieb nehmen. Es gibt Branchen, die sich über viele Jahre diese Voraussetzungen geschaffen haben. Natürlich denkt man bei Simulation in erster Linie an Entwicklungsarbeiten am Anfang eines Projektes. Das ist auch sicherlich der richtige Zugang. Eine „ernsthafte" Simulationsumgebung unterstützt den Anwender jedoch über den gesamten Lebenszyklus.

Simulation ist harte Arbeit

Diesbezüglich gilt es zu bedenken: Simulationsmodelle sind harte Entwicklungsarbeit. Nur eine konsequente Vorgehensweise führt zu einem nutzbaren Erfolg. In etablierten Simulationswerkzeugen lassen sich auch Lösungsstrategien für die gestellten Aufgaben entwickeln.

Eine kompakte und systemkonforme Toolbox für Matlab/Simulink ist ein entscheidender Faktor für eine einfache Anwendung.

© B&R

Eine automatische Übernahme der Arbeitsergebnisse in ein Automatisierungssystem spart einerseits Zeit und sichert andererseits die dauerhafte Nutzung der Simulationsarbeiten ab. Dort, wo Simulationsmodelle zur Entwicklung dienen und nach Fertigstellung der Prüfstand für Inbetriebnahme und Maschinenpflege sind, ist der nachhaltige Nutzen gesichert. Matlab/Simulink sind Beispiele für Produkte, die sich in diesem Zusammenhang einsetzen lassen. Eine offene Architektur des Automatisierungssystems - wie etwa bei Automation Studio der Fall - schafft schließlich die Voraussetzungen für eine durchgängige Nutzung der vollautomatischen Code- Generierung. Zusammenfassend lässt sich festhalten: Mehr denn je ist die effektive Wirtschaftlichkeit einer Lösung entscheidend. Automatisierungstechnik, eine Kerndisziplin der Mechatronik, spielt in diesem Zusammenhang eine zentrale Rolle. Dabei geht es nicht mehr nur um MHz und MByte, sondern immer mehr um die Frage nach realem Anwendernutzen projiziert auf die nächsten 20 Jahre.

Autor: Franz Enhuber ist Key Project Agent bei B&R, Eggelsberg (Österreich).