Ressourcen-Nutzung von der Entwicklung bis zur Dokumentation

Chidester (Zuken): Aus unserer Sicht gewinnt die Integration der Prozesse in den frühen Phasen der Produktentstehung rapide an Bedeutung. Der Grund liegt in der allgemein bekannten Verschiebung der Wertschöpfung von der Mechanik in Richtung Elektronik und Software. Stand heute gibt es eine ganze Reihe von Schnittstellen und Integrationsmöglichkeiten, aber nicht alle von ihnen werden in den Entwicklungsprozessen der Industrie bereits in dem wünschenswerten Ausmaß genutzt. Dies ist in besonderem Maße im Falle der Software-Entwicklung für programmierbare Steuerungen der Fall. Die Ursache für diesen Befund findet sich häufig in der Tatsache begründet, dass von Seiten des Managements dieser Unternehmen die Kommunika- tion zwischen den verschiedenen Abteilungen vielfach noch nicht aktiv forciert wird – denn sie bedeutet zunächst einen Zusatzaufwand und zusätzliche Kosten, die sich aber durch einen geringeren Abstimmungsaufwand in späteren Phasen des Produktentstehungsprozesses reduzieren. Mit unserer Daten- und Prozess-Management Lösung E3.EDM für Elektro- und Fluid-Engineering haben wir Ende 2013 einen wichtigen Baustein für eine durchgängige mechatronische Prozessintegration für die industrielle Automationstechnik vorgestellt.

Eisenbeiss (Siemens): Im Maschinen- und Anlagenbau ist heute diesbezüglich noch die gesamte Bandbreite an Lösungen anzutreffen. Es gibt bereits in hohem Maße durchgängige Workflows, die Mehrfach-Eingabe nahezu vermeiden. Es gibt aber auch noch den Papierausdruck, der an die Nachbardisziplin weitergereicht wird.

Fürnschuß (B&R): Leider noch immer unzureichend. Nach unserem Kenntnisstand verwenden unter den deutschen Maschinen- und Anlagenbauern 85 % der Unternehmen keine integrierten Schnittstellen zwischen M-CAD, E-CAD und SPS-Programmierung oder sie behelfen sich mit einfachen Tabellenexporten. Eine weitere Herausforderung sind die Engineering-Daten selbst, also die Bauteilebeschreibungen der einzelnen Anbieter. Eine effiziente Unterstützung des Arbeitsflusses über die Ingenieursdisziplinen hinweg ist erst dann gegeben, wenn neben integrierten Schnittstellen auch die verwendeten Bauteilebeschreibungen für alle Engineering-Systeme gleichermaßen zur Verfügung stehen. Zusammen mit Eplan sind wir dem aktuellen Stand der Technik eindeutig voraus. Automation Studio 4 bietet eine Round-Trip-Kopplung zu Eplan Electric P8. Zudem ist im Eplan-Data-Portal eine umfangreiche Bauteilebibliothek unserer Hardware-Produkte verfügbar.

Ott (Aucotec): So vielfältig wie die Systeme in den verschiedenen Bereichen sind, so vielfältig sind auch die angebotenen Schnittstellen. Das potenziert sich noch einmal durch die z. T. sehr unterschiedlichen Arbeitsweisen und die daraus resultierenden Kunden-Anforderungen. Generell verzeichnen wir über die letzten Jahre eine deutliche Zunahme an Projekten, in denen eine Integration mit ERP, PDM und M-CAD nicht nur angefragt, sondern auch umgesetzt wird. Dabei sehen wir die Entwicklung sehr positiv, dass zunehmend auch kleine und mittelständische Unternehmen auf Integration der Systeme und Disziplinen setzen. Bei SPS- und Fertigungsunterstützung sind die Anforderungen dagegen wesentlich homogener und die Systeme weniger kundenspezifisch, so kann eine Integration häufig recht einfach mit Bordmitteln umgesetzt werden.

Dr. Papenfort (Beckhoff): Schnittstellen zwischen Tools gibt es viele. Davon auch viele proprietäre. Und das genau ist das Problem. Es fehlen standardisierte Schnittstellen. Effektives Engineering funktioniert nur, wenn man sich Daten in einem gemeinsamen Datenpool teilen kann. Dazu muss das Format natürlich festgelegt werden. Und es muss unabhängig von den eingesetzten Tools sein. ERP-Systeme müssen Aufträge einstellen können. Mechanik- und Elektrokonstruktion sowie die Softwarekonstruktion müssen aus diesen Daten die Maschine oder Anlage konstruieren können. Die Datenflüsse müssen zwischen allen beteiligten Programmen hin und her fließen können. Nur dadurch wird in Zukunft paralleles Engineering möglich werden.

Chidester (Zuken): Um die erforderliche Prozessintegration in der Fluid- und Elektrokonstruktion vorantreiben zu können, erweist sich das auf den ersten Blick naheliegende Vorhaben, mit einem PLM-System die Steuerung aller Daten und Abläufe zusätzlich zur Mechanik über alle Disziplinen hinweg auch für Elektrotechnik, Fluid und Elektronik abzudecken in der Praxis aufwändiger als vielfach angenommen. Der Grund hierfür liegt in den spezialisierten Daten- und Ablaufmodellen der verschiedenen Entwicklungs-Disziplinen: Das Datenmodell, das für die Konstruktion eines mechanischen Bauteils oder eine Baugruppe benötigt wird, unterscheidet sich grundlegend von den Datenmodellen der Elektrotechnik, der Elektronik und der Software-Entwicklung. Es sind also dezidierte Lösungen erforderlich, mit denen sich die Datenmodelle der Elektrokonstruktion in vollem Umfang verwalten lassen, die andererseits aber von vornherein für eine Integration mit der etablierten PLM-Welt offen und vorbereitet ist.

Eisenbeiss (Siemens): Verbesserungspotenziale liegen sehr allgemein in den Austauschformaten. Um hier besser zu werden, liegt noch Arbeit in den Standardisierungsgremien, in denen auch wir uns stark engagieren. Zudem investieren wir in offene Schnittstellen, die eine einfache Nutzbarkeit zwischen Werkzeugen erlauben.

Fürnschuß (B&R): Eine wesentliche Effizienzsteigerung liegt klar auf der Hand: Durch Schnittstellen, die einen durchgängigen Datenaustausch ermöglichen, entfallen viele Doppeleingaben ebenso wie manuelle Tätigkeiten. Durch bidirektionale Schnittstellen kann die Arbeit der unterschiedlichen Disziplinen parallel vorangetrieben werden. Heute wird in aller Regel noch zuerst die Mechanik, dann die Elektrokonstruktion und am Ende – oft unter enormem Zeitdruck – die Software entwickelt. Die Möglichkeit, umgekehrt vorzugehen und eine von der Software vorgegebene Konfigura- tion zur Weiterbearbeitung an die Elektrokonstruktion zu übergeben, ist durch eine bidirektionale Schnittstelle, wie sie zwischen Automation Studio 4 und Eplan Electric P8 besteht, ebenfalls gegeben und wird nicht selten auch die effizientere Alternative sein. Das Fehlerpotenzial sinkt und Entwicklungszeiten verkürzen sich. Auch in der oftmals unter hohem Zeitdruck stehenden Inbetriebnahme ergeben sich Vorteile. So können mit guten Interfaces Daten, die möglicherweise vor Ort oder offline verändert wurden, beim nächsten Ankoppeln an die heimische Infrastruktur in alle Engineering-Systeme rückgeführt werden. Projektquellen und Dokumentationen haben so immer einen gültigen Informationsstand, was nachfolgende Wartung und Weiterentwicklung in Folgeprojekten erleichtert.

Ott (Aucotec): In den einzelnen Abteilungen wurde in den vergangenen Jahren viel investiert, um dort die Effizienz zu steigern. Die Potenziale sind hier so gut wie ausgeschöpft. Wichtiger als der Erfolg der Einzel-Disziplinen ist aber der des Unternehmens insgesamt. Für eine unternehmensweite Effizienz-Steigerung müssen die Prozesse zunehmend interdisziplinär angegangen werden. Eine enge Zusammenarbeit zwischen den Disziplinen kann die Software zwar unterstützen, ausschlaggebend ist aber der Mensch. Ohne beispielsweise einen einheitlichen Sprachgebrauch sind zeitraubende Missverständnisse vorprogrammiert. Die Mauern zwischen den Disziplinen müssen fallen oder zumindest transparenter werden. Hier ist die Unternehmensleitung gefragt. Die Initiative muss von ihr ausgehen.

Dr. Papenfort (Beckhoff): Softwareanbieter müssen sicherlich noch zu definierende Standards für den Datenaustausch unterstützen. Die Anwender müssen sich auf mehr Arbeit im Team und Einhalten von vorher definierten Schnittstellen einstellen. Flexibilität und Offenheit sind gefragt.

Chidester (Zuken): Der erforderliche Datenaustausch ist an sich eine recht einfache Aufgabe und im Hause Zuken haben wir zusammen mit unseren Kunden eine ganze Reihe von Schnittstellen für diesen Zweck entwickelt und kontinuierlich weiterentwickelt. Insgesamt hilft uns das Feedback unserer Kunden dabei, zu verstehen, welche Daten ausgetauscht werden müssen, mit welcher Frequenz und mit welcher Informationstiefe.

Eisenbeiss (Siemens): Kernanforderung an die Schnittstelle zwischen CAE und SPS-Programmierung, zum Beispiel zwischen Eplan und Siemens-Steuerungen, ist der Austausch von Signallisten sowie der Hardwarekonfiguration. Zu diesem Zweck wurden Schnittstellen geschaffen, die heute schon im Anlagen- und Maschinenbau etabliert sind und ein hohes Maß an Effizienz bringen.

Fürnschuß (B&R): Die Offenheit unseres Systems ermöglicht es, zum Beispiel die MCAD- und die ECAD-Welt in unsere Entwicklungswelt zu integrieren. Eine bidirektionale Schnittstelle zwischen der Entwicklungsumgebung Automation Studio von B&R und Electric P8 bietet Hard- und Softwareentwicklern eine gemeinsame Datenbasis. Sie kommen dadurch schneller und sicherer zu optimalen Ergebnissen. Außerdem erschließen wir den MCAD-Bereich bequem über eine Simulationsschnittstelle. Dabei gehen wir selektiv vor und verwenden ausschließlich die Informationen, die für beide Disziplinen gleichermaßen relevant sind. Erfahrungsgemäß ist das sinnvoller als komplette Files zu laden und regelrecht im Daten-Overflow zu ersticken. Für die Simula- tion nutzen wir neben unserer eigenen Simulationsumgebung Simulationswerkzeuge wie Matlab oder MapleSim.

Ott (Aucotec): Auch wenn die Software-Anbieter für viele Systeme spezifische Schnittstellen anbieten, sind die generischen Schnittstellen über XLS- und CSV-Formate noch immer im Vormarsch. Dies liegt einerseits daran, dass der zusätzliche Nutzen einer systemspezifischen Schnittstelle die notwendige Investition aus Sicht der Kunden nur selten rechtfertigt und andererseits die spezifische Schnittstelle weniger flexibel ist. Mancher Kunde bräuchte für jedes eingesetzte SPS-Programmiersystem eine passende Schnittstelle. Unabhängig von der Art der Schnittstelle kommt es auf ihre Einfachheit und den Komfort in der Handhabung an und darauf, ob die Daten bidirektional übertragen werden können und Änderungen sinnvoll verwaltet werden. Ob das Format dahinter XLS, CSV oder XML ist, ist eher zweitrangig.

Dr. Papenfort (Beckhoff): Schon heute werden Daten aus der mechanischen und elektrotechnischen Konstruktion an die SPS-Programmierung weitergegeben. Allerdings erfolgt das häufig auf Zuruf und nicht in elektronischer Form. Hier ist eine bessere Abstimmung und eine Nachverfolgbarkeit unbedingt nötig.

Chidester (Zuken): Datenaustausch zwischen den Systemwelten ist ein breites und häufig kontroverses Thema. Am effizientesten ist kurzfristig sicher ein direkter Austausch von Daten zwischen den verschiedenen Werkzeugen. Das ist schneller, genauer und weniger fehleranfällig. Leider sehen wir derzeit noch keinen allgemein akzeptierten Standard. Der VDMA hat damit begonnen, einen solchen Standard definieren. Zuken wird diesen Standard, so er denn erst einmal etabliert ist, zweifellos unterstützen. Grundsätzlich kann man sagen, sind sich alle Beteiligten einig, dass das Ziel ein etablierter Standard sein sollte, aber eine allgemeingültige Definition ist eine schwierige Aufgabe. Ein „leichter“ Standard ist auf alle Fälle schneller zu etablieren, auf lange Sicht bleibt dann aber das Problem der gesamtheitlichen Darstellung der verschiedenen Anforderungen der Industrie. In der Praxis haben wir es deshalb meist mit partiellen Implementierungen zu tun, die durch Individualschnittstellen ergänzt werden. Und damit ist bereits wieder der erste Schritt zu ihrer Verwässerung getan.

Eisenbeiss (Siemens): Es gibt diverse, meist XML-basierte Formate. Ein wirklicher Standard hat sich aber bis heute nicht etabliert. Das Bestreben, diese Lücke zu schließen, ist jedoch aktuell breit vorhanden. Wir stellen die Durchgängigkeit unserer Softwarelandschaft sicher, arbeiten im VDMA am Datenaustausch zwischen MCAD/ECAD/ACAD und setzen uns für Standardisierung und Normung von Formaten ein.

Fürnschuß (B&R): Die Forderungen nach Standards werden berechtigterweise immer lauter und sie werden auch gehört. Teilweise haben sich durch simple Marktgegebenheiten Quasistandards entwickelt, auf die sich einzelne Hersteller einschwingen. Eine Initiative wie die zum VDMA-Einheitsblatt 66415 „Engineering Datenaustausch Mechanik–Elektrik–Software“ ist in jedem Fall zu begrüßen und zu unterstützen. Es gehört zur Kernkompetenz von B&R, unsere Hardware fürs Engineering verfügbar zu machen und die Software entsprechend der Hardware zu programmieren. Im Bereich der Hardware-Konfiguration unterstützen wir unsere Kunden mit hervorragenden Lösungen, die die Entwicklungsqualität und -zeit deutlich optimieren. Auch die Vorteile der IEC-Programmierwelt nutzen wir vollumfänglich. Unser Werkzeug eignet sich für alle Varianten, die uns die IEC bietet.

Ott (Aucotec): Standards sind leider noch nicht weit verbreitet. Entlang der Prozesskette finden wir z. B. eCl@ss, AutomationML, VDMA 66415 und IEC 6242. Alle haben gute Voraussetzungen, sich in naher Zukunft zu etablieren. Da sie jedoch noch von zu wenigen Systemen unterstützt werden, ist die Nachfrage entsprechend gering – das typische Henne-Ei-Problem. Wichtig für eine Standard-Schnittstelle ist letztendlich ihre Verbreitung. Bisher ist keine groß genug. Im Kundenfokus steht zuerst, dass die Schnittstelle ihren eigenen Prozess unterstützt und das Kosten-Nutzen Verhältnis stimmt. Ob dies mit einer Standard- oder proprietären Schnittstelle erreicht wird, ist meist weniger wichtig. Als Systemanbieter käme uns ein etablierter Standard sehr entgegen. Das hieße für uns effizientere Ressourcen-Nutzung in Entwicklung, Qualitätssicherung und Dokumentation.

Dr. Papenfort (Beckhoff): In verschiedenen Gremien werden Standards diskutiert. Allerdings hat sich hier noch keine Lösung herauskristallisiert. Beckhoff ist in diesen Gremien aktiv vertreten.

Mit der Thematik beschäftigt sich auch der VDMA:

http://ea.vdma.org/article/-/articleview/296671