Maschinen-Konstruktion Software in den mechatronischen Ansatz integrieren

Im Sinne des mechatronischen Entwicklungsansatzes ist es wichtig, die Software von Anfang an in den Entstehungsprozess einer Maschine mit einzubeziehen. Das ist nicht so einfach. Denn oft soll die Software auch Fehler in der Konstruktion korrigieren. Mechatronische Ansätze helfen, die Software-Risiken an den Anfang der Maschinen-Entstehung zu platzieren.

Anbieter zum Thema

ISG Industrielle Steuerungstechnik GmbH

invenio AG

Actronic-Solutions GmbH

PHOENIX CONTACT Deutschland GmbH

Die Beschleunigung der Inbetriebnahme ist ein wichtiges Ziel im Maschinenbau. Wenn Mechanik und Elektrik einer Maschine fertig gestellt sind, ist die Software oft nur zu einem Teil erstellt und noch nicht getestet. Ein Großteil der Software entsteht erst bei der Inbetriebnahme. Sie ist damit der „kritische Pfad“ für die termingerechte Abwicklung des Auftrags.

Folge dieser Vorgehensweise sind „reisende Software-Entwickler“, die Teile der Software erst beim Kunden entwickeln, sowie Qualitätsprobleme, die den Kunden verärgern. Während der Inbetriebnahmephase können die Projektkosten dann leicht explodieren.

Risikopotenzial der Software reduzieren

Einige Strategien helfen dem Anwender, das Risikopotenzial der Software bei der Inbetriebnahme zu reduzieren. Sinnvoll ist es, die Software bereits vor der Inbetriebnahme zu entwickeln und zu testen. Dieser Ansatz wird von Praktikern häufig belächelt. Denn sie wissen, dass die Software oft nachträglich Probleme lösen muss, die bei der mechanischen Konstruktion übersehen wurden.

Praktiker wissen auch, dass eine Maschine häufig nicht bis ins Detail so gebaut wurde, wie es vorher zwischen den Abteilungen vereinbart worden war. Wurde bei nicht genau festgelegten Konstruktionsabläufen Software parallel zur Maschinenkonstruktion entwickelt, muss die Software oft nachgearbeitet oder neu erstellt werden.

Soll eine Software bei der Inbetriebnahme fertig entwickelt sein, muss der Programmierer Konstruktion und Funktion sowie den geplanten Maschinenablauf kennen. Außerdem muss er bei kleinen Veränderungen informiert werden.

Abstimmungsrunde darf keine lästige Pflicht sein

Dies kann durch regelmäßige Abstimmung zwischen den Mitarbeitern aus mechanischer, elektrischer und Software-technischer Konstruktion erfolgen. Fundierte, effiziente Abstimmungen der Konstruktions-Fachrichtungen sind ein wichtiger Schritt in Richtung eines mechatronischen Ansatzes. Eine derartige Abstimmungsrunde darf nicht zur lästigen Pflichtveranstaltung werden, sondern sollte effizient gehalten sein und protokolliert werden. Jede Änderung in Mechanik, Elektrik oder Software muss in diese Abstimmungsrunde eingebracht und protokolliert werden, bevor sie vollzogen wird.

Folgt man den Geboten der Mechatronik, kann der Abstimmungsprozess mit einer Umstrukturierung der Konstruktionsabteilung einher gehen. Dabei können sich mechatronische Konstruktionsteams bilden, die für Maschinenmodule verantwortlich sind.

Bei der Abstimmung gestaltet sich die Protokollierung der Ergebnisse oft schwierig. Daher haben renommierte Maschinenbauer im „Forum Mechatronik“ die Nutzung des Ablaufdiagramms für den Maschinenablauf vorgeschlagen.

Ergebnisse der Abstimmung im Ablaufdiagramm darstellen

Mit Steeplechase VLC bietet Phoenix Contact eine Software, mit der die Ergebnisse der Abstimmung zwischen den Fachabteilungen als Ablaufdiagramm für jeden einfach und verständlich dargestellt werden können. Außerdem können damit die Programme der Steuerungen einer Maschine erstellt werden. Mit Steeplechase VLC werden Differenzen zwischen Abstimmungsergebnissen und Software-Entwicklung eliminiert. Die Software wird damit für den mechanischen Konstrukteur verständlich und erlebbar - ein weiterer Schritt in Richtung „Mechatronik“.

Software kann auf unterschiedliche Weise getestet werden - ein Ansatz ist die Simulation. Diesem Ansatz begegnet man heute selten, da Datenbeschaffung und Modellerstellung oft aufwendig sind. Bei gleichen und ähnlichen Konstruktionen kann der Aufwand aber gerechtfertigt sein. Hier ist in Zukunft mehr zu erwarten - besonders durch die Verzahnung der Software-Tools und der damit automatisierten Datenerstellung.

Maschine modularisieren und Module „in Betrieb nehmen“

Ein anderer interessanter Ansatz ist die mechatronische Modularisierung. Bei der Konstruktion von mechatronischen Modulen, die autark ihre Funktionen ausführen, kann auch die Software der Module getestet werden. So kommt es zu einer „Modulinbetriebnahme“, bevor die Gesamtmaschine in Betrieb genommen wird.

Dazu muss die gesamte Maschinenkonstruktion in eine modulare Bauweise mit identischen Modulgrenzen überführt werden. Hier wird der Mechanik-Konstrukteur einwenden, dass er die Modulbauweise ja schon seit Jahrzehnten nutzt. Allerdings ist dieser Einwand zu kurz gedacht.

Soll die Software getestet werden, müssen die elektrische Konstruktion, die Software selbst sowie eventuell auch die Pneumatik- und Fluid-Konstruktion an die mechanische Modulbauweise angepasst werden. Die mechatronische Modulbauweise verlangt, dass die Schnittstellen der mechatronischen Module in allen Konstruktionsdisziplinen identisch sind. Nur dann ist ein Modul wieder verwendbar, nur dann kann die Software für dieses Modul effizient am realen Modul getestet werden.

Jedes Modul muss autark sein

Der Software-Entwicklung will die Abgrenzungen der Module oft nicht akzeptieren. Die Software wird in Organisationseinheiten strukturiert, zum Beispiel in Funktionen und Funktionsblöcke nach IEC 61131. Für eine echte Modularisierung dürfen die Funktionen und Funktionsblöcke die Funktionen der anderen Module nicht kennen. Der Aufwand für diese „Kapselung“ der Funktionen und für einheitliche Software-Funktions-Schnittstellen ist allerdings nicht zu unterschätzten.

Soll die Maschinen-Software vor der Maschineninbetriebnahme getestet werden können, müssen unterschiedliche Faktoren zusammen kommen: eine geeignete mechatronische Modularisierung, eine gute Kommunikation zwischen den Disziplinen und vor allem die Unterstützung durch das Management.

Vor allem das Management muss mitmachen

Die Unterstützung durch das Management ist von übergeordneter Bedeutung. Denn das Management muss die Kommunikationsprozesse so strukturieren, dass die Konstrukteure jeder Fachrichtung gleichberechtigt miteinander diskutieren. Unternehmen, die den Software-Entwickler als Zuarbeiter des Maschinenbauers betrachten, werden strukturelle Probleme nicht durch technologische Veränderungen beseitigen können.

Wird die Kommunikation sachgerecht gestaltet und die mechatronische Modularisierung konsequent durchgeführt, so kann durch die frühe Test- und Inbetriebnahme der Software sowie der Mechanik, Elektrik, Pneumatik und Fluidtechnik die Qualität und Sicherheit deutlich gesteigert werden. Dabei werden auch die Kosten und die Risiken der Inbetriebnahme erheblich gesenkt.

*Dipl.-Ing. Claus Kühnl ist Mitarbeiter im Strategischen Marketing der Business Unit Automation Systems bei der Phoenix Contact Electronics GmbH, Bad Pyrmont.

(ID:236021)