Beschreibung

Die vorliegende Erfindung betrifft den Datenaustausch zwischen einem Konstruktions- bzw. Planungssystem zur Entwicklung von technischen Produkten, insbesondere Produkten zur Verwendung in einer Automatisierungsanlage und einem davon getrennten Produktionssystem zur Produktion der Produkte.

Bei der Entwicklung und Herstellung von technischen Produkten, wie zum Beispiel Produkten in der Automatisierungstechnik (für unterschiedliche Anwendungsgebiete, wie Labortechnik, Messgerätetechnik, Nahrungsmittelindustrie oder Fertigungstechnik etc.) sind zwei - üblicherweise sequenzielle - Zeitphasen vorgesehen: erstens die

Konstruktion/Entwicklung/Planungsphase (in der zum Beispiel ein CAD System, Computer Aided Design zum Einsatz kommen kann) und zweitens die Produktionsphase, in der das entwickelte/konstruierte technische Produkt oder Produktionssystem hergestellt werden. Üblicherweise wird der Produktionsprozess auch durch Software Tools unterstützt. Da die entwicklungsseitige Domäne und die produktionsseitige Domäne voneinander getrennt sind, ist ein Datenaustausch zwischen den beiden Domänen bislang gar nicht oder nur sehr eingeschränkt möglich gewesen.

Bei den heutigen Systemen und Anlagen kann davon ausgegangen werden, dass die Entwicklung, zum Beispiel auf einem CAD-System, völlig entkoppelt von der späteren Produktion erfolgt. Das fertig entwickelte Produkt wird nach Abschluss der Entwicklungsphase an die Produktion übergeben. Daraufhin erfolgt die produktionsseitige Umsetzung auf Basis der real verfügbaren Ressourcen.

Nachteiliger Weise erfolgte im Stand der Technik kein standardisierter Abgleich und Kommunikationsaustausch zwischen der Entwicklungsdomäne und der Produktionsdomäne. Insbesondere war es nicht standardisiert oder nur mit zusätzlichen Aufwand möglich, die real verfügbaren Betriebsmittel in der Produktion und die produktionsseitigen Ressourcen bereits zum Zeitpunkt der Entwicklung an das Entwicklungssystem zu kommunizieren. Damit war es nicht möglich, den Entwicklungsprozess auf die Fähigkeiten und Möglichkeiten der Produktion gezielt anpassen zu können. Dies wirkt sich nachteilig auf die Herstellungskosten aus, da mitunter nachträglich im Produktionsprozess Anpassungen getroffen werden müssen, um die entwicklungsseitigen Vorgaben erfüllen zu können.

Hier setzt die vorliegende Erfindung an. Diese hat sich zur Aufgabe gestellt, den Datenaustausch zwischen der entwicklungsseitigen IT-Domäne und der produktionsseitigen IT-Domäne zu verbessern und insbesondere zu standardisieren. Das Zusammenspiel und die Kommunikation zwischen Entwicklung und Produktion sollen verbessert werden. Des weiteren sollen die Herstellungskosten reduziert und die Qualität der Produktion erhöht werden. Weiterhin soll die Zeit bis zur fertigen Produktion des zu produzierenden Werkstücks oder Produktes verkürzt werden.

Diese Aufgabe wird durch die beiliegenden einander nebengeordneten Patentansprüche gelöst, insbesondere durch ein System zum Austausch von elektronischen Nachrichten, durch einen Intermediär, durch ein computer-implementiertes Verfahren und durch ein Computer Programm und ein Computerprogrammprodukt.

Gemäß einem ersten Aspekt betrifft die Erfindung ein Computer-implementiertes System zum Austausch von elektronischen Nachrichten zwischen einem elektronischen Entwicklungstool (zum Beispiel einem CAD - Software Tool zur Entwicklung/Konstruktion/Planung) und einem (üblicherweise davon getrennten) elektronischen Produktionstool. Das System umfasst einen Intermediär (als einen computerbasierten Vermittlungsknoten mit Hardware und Software), der über ein Netzwerk (zum Beispiel LAN, WLAN oder andere Funk-basierte Netzwerke oder drahtgebundene Netzwerke) mit dem Entwicklungstool und dem Produktionstool in Datenaustausch steht. Das System und insbesondere der Intermediär umfasst: eine Entwicklungsanfrageschnittstelle, insbesondere zu dem Entwicklungstool, eine Produktionsanfrageschnittstelle, insbesondere zu dem Produktionstool, eine Produktionsantwortschnittstellen, insbesondere zu dem Produktionstool und eine Analysenachrichtschnittstelle, insbesondere zu dem Entwicklungstool.

Der Intermediär dient zum standardisierten Datenaustausch zwischen dem Entwicklungstool und dem Produktionstool und ist dazu ausgebildet, eine Entwicklungsanfragenachricht über die Entwicklungsanfrageschnittstelle zu empfangen und diese mittels eines Transformationsalgorithmus in eine Produktionsanfragenachricht umzurechnen bzw. zu transformieren, um die Produktionsanfragenachricht über die Produktionsanfrageschnittstelle an das Produktionstool zu senden. Der Intermediär ist weiterhin dazu ausgebildet, über die Produktionsantwortschnittstelle eine Produktionsantwortnachricht von dem Produktionstool zu empfangen und daraus mittels eines Analysealgorithmus eine Analysenachricht zu erzeugen und diese Analysenachricht über die Analysenachrichtschnittstelle an das Entwicklungstool zu senden. In einer bevorzugten Ausführungsform können die Entwicklungsanfrageschnittstelle und die Analysenachrichtschnittstelle in einer gemeinsamen Schnittstelle integriert sein. Gleiches gilt für die Produktionsanfrageschnittstelle und für die Produktionsantwortschnittstelle; auch diese können in einer gemeinsamen physikalischen Schnittstelle kombiniert bzw. integriert sein.

In einer bevorzugten Ausführungsform kann auf dem Produktionstool aus einer Produktionsanfragenachricht eine Produktionsantwortnachricht erzeugt werden, indem die angefragten Informationen direkt aus einer in dem Produktionstool gespeicherten Datei extrahiert werden. Kumulativ oder alternativ können die angefragten Informationen aus Parametern einer Anlage, die mit dem Produktionstool betrieben und/oder verwaltet wird, berechnet werden. So können z.B. aus einer Datei, die zum Beispiel nach Vorgaben der Verwaltungsschale der Plattform Industrie 4.0 gestaltet sein kann, gemäß einem Algorithmus Lösungsräume berechnet werden, die sich durch die Fähigkeiten (Skills) der jeweiligen Maschine ergeben und die mit den in der Produktionsanfragenachricht ermittelten Anforderungen abgeglichen werden. Dazu sein folgendes Beispiel erwähnt: In der Produktionsanfragenachricht wird gefragt, ob ein Produkt A mit den Maßen 100x200x500mm in Prozesszelle P1 beschriftet werden kann. Die Fähigkeiten von P1 sind in der Datei D1 beschrieben. Prozesszelle P1 hat laut Datei D1 einen Bearbeitungsraum von max. 150x200x300mm. Der Analysealgorithmus vergleicht die Lösungsräume von der Prozesszelle P1 anhand der Informationen in der Datei D1 mit den Anforderungen seitens des Entwicklungstools zur Entwicklung von Produkt A. In der Produktionsantwortnachricht wird dem Entwicklungstool dann mitgeteilt, dass sein Produkt A nicht auf der Prozesszelle P1 gefertigt werden kann, da die Maße in der Z-Dimension den Bearbeitungsraum von der Prozesszelle P1 um 200mm überschreiten.

Durch die unmittelbare Rückmeldung über die Fertigbarkeit von A spart sich der Entwickler einen hohen Kommunikations- und Abstimmungsaufwand und kann unmittelbar, in einer sehr frühen Phase des Entwicklungsprozesses, Anpassungen an einem Produkt vornehmen, die sich letztendlich sehr positiv auf die Herstellkosten auswirken. Gleiches gilt analog, wenn die Anlage in dem Produktionstool verwaltet wird. Lediglich mit dem Unterschied, dass die Fähigkeiten über ein Protokoll direkt von der Anlage an das Produktionstool übermittelt werden bzw. dass sie händisch in das Produktionstool eingetragen werden.

Auch ein Empfänger-basiertes Erzeugen der Produktionsantwortnachricht ist möglich, z.B. durch einen Anwender des Produktionssystems, der Eingaben auf einer Benutzeroberfläche (z.B. in einer Eingabemaske) tätigt.

In einer weiteren bevorzugten Ausführungsform kann die Entwicklungsanfragenachricht auf dem Entwicklungstool erzeugt werden, indem eine Exportfunktion ausgeführt wird, um die erforderlichen Daten aus dem IT-basierten Entwicklungstool (z.B. einem CAD-System) zu extrahieren und zu der Entwicklungsanfragenachricht zu verarbeiten. So kann in diesem Schritt z.B. eine Extraktion der einzelnen Komponenten aus dem Gesamt-CAD, eine Produktion-/Montagereihenfolgenbildung und/oder eine Strukturierung der Daten und/oder eine Gruppierung der jeweiligen Merkmale nach den einzelnen Komponenten (Abmessungen, Material etc.) ausgeführt werden.

Alternativ kann die Entwicklungsanfragenachricht erzeugt werden, indem eine Eingabemaske auf dem Entwicklungstool zur Verfügung gestellt wird, über die Parameter abgefragt werden, aus denen die Entwicklungsanfragenachricht algorithmisch synthetisiert und erzeugt werden kann. Wichtige Merkmalkategorien sind hier: Geometriedaten, Produktdaten, Prozessdaten, Prüfdaten und/oder Maschinendaten.

In einer vorteilhaften Ausführungsform der Erfindung können die ausgetauschten Nachrichten und insbesondere die Entwicklungsanfragenachricht als sogenannte STEP-Datei oder in einem CAD-Produkt-spezifischem Format bereitgestellt und ausgetauscht werden. STEP steht für „Standard for the Exchange of Product model data“ und das zugehörige Dateiformat lautet „.STP“. Mit einer STEP-Datei ist es möglich, die Informationen eines Produkts über dessen gesamten Lebenszyklus abzubilden. Dabei werden sowohl die funktionalen wie auch die physikalischen Aspekte erfasst. Die Verwendung des STEP-Formates erweist sich vor allem für die Beschreibung von per Computer erstellten 3D-Modellen (CAD, Computer gestütztes Design) als vorteilhaft.

In einer weiteren vorteilhaften Ausführungsform der Erfindung kann es vorgesehen sein, ein digitales Modell („digital twin“) für die produktionsseitig vorhandenen Betriebsmittel und deren Funktionalitäten (skills) vorzuhalten und in einem Speicher zu speichern, sodass das System und vorzugsweise der Intermediär darauf zugreifen kann. Um die Komplexität des digitalen Modells so gering wie möglich zu halten, kann es vorgesehen sein, das digitale Modell nur für ausgewählte Produktionsmittel (umfassend Betriebsmittel und deren Funktionalitäten) bereitzustellen. Das digitale Modell kann vorzugsweise direkt auf dem Intermediär gespeichert sein und bietet die Möglichkeit, die entwicklungsseitig definierten Anforderungen dahingehend zu überprüfen, ob sie gegenwärtig (unter den aktuellen Bedingungen des Produktionssystems) produktionsseitig auch realisierbar sind. Hier fließen insbesondere Taktzeiten, Zykluszeiten und/oder weitere zeitbasierte Parameter sowie Bau(gruppen)größen und/oder geometrische, Maschinen-, Produkt- und/oder Prozessdaten, sowie prüfspezifische Größen deren Funktionalitäten ein.

Gemäß einem weiteren Aspekt bezieht sich die vorliegende Erfindung auf einen Intermediär zur standardisierten Vermittlung von elektronischen Nachrichten. Der Intermediär dient damit als zentraler computerbasierter Vermittlungsknoten zwischen dem Entwicklungstool einerseits und dem Produktionstool andererseits. Dazu umfasst der Intermediär die Entwicklungsanfrageschnittstelle, die Produktionsanfrageschnittstelle, die Produktionsantwortschnittstelle und die Analysenachrichtschnittstelle, um die Entwicklungsanfragenachricht und die Produktionsantwortnachricht (von unterschiedlichen Sendeknoten) zu empfangen und die Produktionsanfragenachricht und die Analysenachricht (an unterschiedliche Empfängerkonten) zu senden.

In einer ersten Ausführungsform kann der Nachrichtenaustausch, der über den Intermediär vermittelt wird, von dem Entwicklungstools getriggert bzw. angestoßen werden, indem eine Entwicklungsanfragenachricht auf dem Entwicklungstools erzeugt wird und an den Intermediär gesendet wird, der daraufhin weitere Datenverarbeitungen und Algorithmen ausführt, um schlussendlich die finale Analysenachricht mit der produktionsseitigen oder intermediärseitigen Antwort auf die Entwicklungsanfragenachricht bereitzustellen und als Antwort an das Entwicklungstool zurückzusenden. Dazu kann der Intermediär mit dem Produktionstool interagieren. Alternativ kann auf dem Intermediär ein Kl-Tool implementiert sein, so dass der Intermediär die notwendigen Antworten und Analysen selbständig bereitstellen kann (z.B. unter Zugriff auf historische Daten).

In einer zweiten Ausführungsform kann der Nachrichtenaustausch, der über den Intermediär vermittelt wird, auch von dem Produktionstool getriggert werden, in dem eine Produktionsantwortnachricht von dem Produktionstool an den Intermediär gesendet wird, der daraufhin ausgelegt ist, in Antwort auf die empfangene Produktionsantwortnachricht eine Analysenachricht zu erzeugen und die so erzeugte Analysenachricht an das Entwicklungstool zu übermitteln. In diesem Fall hat die Produktionsantwortnachricht den Charakter einer Statusnachricht, um den aktuellen Betriebsstatus des Produktionstools zu repräsentieren, insbesondere mit den verfügbaren Betriebsmitteln und deren Funktionalitäten, sowie optional weiteren produktionstechnischen Parametern, wie zum Beispiel Taktzyklen, Ausfallsicherheit, Zuverlässigkeit, Sicherheitslevel und/oder weiteren produktionsrelevanten Metadaten etc. Es können z.B. folgende Daten verarbeitet werden: Daten zur Auslastung (z.B. OEE), ein Schichtmodell, eine Planbelegung, Maschinenkostensätze, benötigte Mitarbeiter ("Werker") pro Anlage. Dazu folgende Beispiele:

Beispiel 1 : Aufgrund aktueller Daten zur Auslastung können auf dem Entwicklungstool Rückschlüsse darauf gezogen werden, ob ein Produkt in der geplanten Stückzahl auf einer bestimmten Anlage produziert werden kann oder ob in eine neue Anlage investiert werden muss.

Beispiel 2: Das Produktionstool sendet Änderungen in den Maschinenkostensätzen, sodass die Herstellkosten im Entwicklungstool angepasst werden können.

Beispiel 3: Das Produktionstools liefert Informationen zur durchschnittlichen Auslastung (n.i.O.-Raten/Fehlerraten, ...) des Prozessmoduls an den Intermediär. Das Entwicklungstool kann auf Basis dieser Informationen Rückschlüsse auf die Prozesssicherheit und ggf. Eignung einer Fertigungstechnologie schließen und sich ggf. für alternative Fertigungsverfahren entscheiden.

Der Nachrichtenaustausch zwischen dem Entwicklungstool und dem Produktionstool kann somit von beiden Seiten, also von dem Entwicklungstool und/oder von dem Produktionstool aus getriggert bzw. ausgelöst werden. In einer bevorzugten Ausführungsform kann ein vordefiniertes Ereignismuster hinterlegt sein, um den Nachrichtenaustausch zwischen Produktionstool und Entwicklungstool auszuführen. So kann beispielsweise ein Zeitmuster hinterlegt sein, das definiert, zu welchem Zeitpunkt eine entsprechende Anfrage (zum Beispiel eine Entwicklungsanfragenachricht) an das jeweils komplementäre System (hier: Produktionssystem) gesendet werden soll. Des weiteren kann alternativ oder kumulativ ein Aktivitätsmuster hinterlegt sein, das definiert, in welchen Situationen eine entsprechende Anfrage bzw. ein Datenaustausch ausgeführt werden soll. Das Aktivitätsmuster kann beispielsweise aus einer Menge von vordefinierten, erfassten Sensordaten deduziert werden (zum Beispiel nach Abschluss einer bestimmten Entwicklungstätigkeit, Entwicklungsphase und/oder bei Änderungen am Produktionstool).

In einer bevorzugten Ausführungsform sind alle oder ausgewählte der vorstehend beschriebenen Schnittstellen (also insbesondere die Entwicklungsanfrageschnittstelle, die Produktionsanfrageschnittstelle, die Produktionsantwortschnittstelle und die Analysenachrichtschnittstelle) als REST API’s ausgebildet. REST API ist in diesem Kontext als Applikation Schnittstelle (application program interface, API) zu verstehen, die nach dem REST Paradigma ausgelegt ist. Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. Client notwendig sind, um die Nachricht zu verstehen. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Vorzugsweise ist die Schnittstelle jeweils zustandslos (englisch: stateless) bzw. wird mit einem zustandslosen Protokoll betrieben. Als Anwendungsschicht-Protokolle Können z.B. HTTP oder HTTPS eingesetzt werden. Jede Anfrage eines Clients (zum Beispiel Entwicklungstool und/oder Produktionstool) an den Server (hier insbesondere: Intermediär) ist insofern in sich geschlossen, als sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom „Server“ für die Verarbeitung der „Client“-Anfrage benötigt werden.

In einer weiteren vorteilhaften Ausführungsform können die auszutauschenden Nachrichten in einem vordefinierten Format bereitgestellt und ausgetauscht werden, das eine weitere Verarbeitung vereinfacht. So können die Nachrichten beispielsweise in einem JSON-Format bereitgestellt werden, was den Vorteil einer einfach lesbaren Textform hat und dem Zweck des Datenaustausches zwischen den Anwendungen dient. Die Nachrichten können auch in einem XML-Format (XML: Extensible Markup Language) formatiert sein, so dass diese sowohl von Menschen als auch voll-automatisiert von einer Maschine lesbar sind. Diese Ausführungsform hat den technischen Vorteil, dass die ausgetauschten Nachrichten einerseits auf einem Userinterface (zum Beispiel einem Monitor) dargestellt und gleichzeitig bzw. direkt (ohne Zwischenverarbeitung) voll-automatisiert durch entsprechende Algorithmen weiterverarbeitet werden können.

In einer vorteilhaften Weiterbildung kann die Produktionsantwortnachricht zumindest zwei Bestandteile bzw. Abschnitte aufweisen und insbesondere einen Betriebsmittelabschnitt und einen Betriebsmittelfunktionalitätsabschnitt umfassen. Der Betriebsmittelabschnitt bezieht sich auf bzw. repräsentiert die Betriebsmittel, die aktuell im Produktionssystem verfügbar sind und entsprechend im Produktionstool als verfügbar gekennzeichnet sind. Der Betriebsmittelfunktionalitätsabschnitt bezieht sich auf bzw. repräsentiert die Funktionalität des jeweiligen Betriebsmittels. Je nach Ausführungsform kann der Betriebsmittelfunktionalitätsabschnitt unterschiedliche Sub-Kategorien umfassen, in denen weitere Metadaten repräsentiert sind, wie zum Beispiel Zykluszeiten, Taktzeiten, Ausführungsbedingungen, Umgebungsbedingungen, wie zum Beispiel Temperatur, erforderliche Schmiermittel und/oder andere physikalische Größen. Mit dieser Ausführungsform wird es vorteilhafter Weise möglich, eine tiefergehende Analyse und eine konkretere Aussage bereitzustellen. So kann nicht nur eine Aussage darüber getroffen werden, welche Betriebsmittel (zum Beispiel Messenden, Laser und/oder Beschriftungsgeräte) aktuell auf dem Produktionssystem verfügbar sind, sondern auch welche Aufgaben von den vorhandenen Betriebsmittel erfüllt werden können (zum Beispiel Ventilschaltvorgänge mit zugehörigen Taktzeiten und/oder Laser mit zugehörigen Wellenlängen).

In einer vorteilhaften Weiterbildung der Erfindung kann der Transformations-Algorithmus automatisch aus der Entwicklungsanfragenachricht Prozessparameter extrahieren, die Prozessanforderungen repräsentieren. Der Begriff „Prozessanforderungen“ ist in diesem Kontext zu verstehen als diejenigen technischen bzw. physikalischen Anforderungen, die erfüllt sein müssen, um den Prozess auf dem Produktionssystem ausführen zu können. Prozessanforderungen können sich also z.B. auf die Temperatur, die Druckverhältnisse, die Spannungs- und Stromversorgung und/oder auf andere physikalische oder technische Parameter beziehen.

Der Analysealgorithmus ist ein computerbasierter Prozess, der in Antwort auf die erfassten Gegebenheiten oder den erfassten Zustand des Produktionssystems eine Analysenachricht erzeugt. Die Analysenachricht hat den Zweck, das Entwicklungstools (bzw. dessen User) über den aktuellen Zustand des Produktionssystems zu informieren und/oder dessen Anfragen (insbesondere formalisiert als Entwicklungsanfrage Nachricht) möglichst exakt und vollständig zu beantworten. Dazu kann der Analysealgorithmus - je nach Ausführungsform - unterschiedliche Bausteine bzw. Funktionen umfassen. So kann beispielsweise ein Abgleich von Geometrie - und Prozessdaten ausgeführt werden. Kann zum Beispiel aus dem Entwicklungstool eine Geometrieanforderung abgeleitet werden, dass eine bestimmte Dimension des Bauraums erforderlich ist (z.B. Werte für X/Y/Z - Achse müssen mindestens 20/30/40 mm betragen), so kann dies mit den aktuell verfügbaren Produktionsressourcen abgeglichen werden. Falls das Bauteil in der angefragten Dimension (20/30/40 mm) verfügbar ist, kann das Ergebnis des Vergleichs ausgegeben werden. Andernfalls kann eine Fehlermeldung ausgegeben werden, dass die Entwicklungstool-seitige Anforderung produktionsseitig nicht erfüllt werden kann. Entsprechende Alternativvorschläge für das Entwicklungstool zur Entwicklung von Produkten mit umsetzbaren Produktionsanforderungen können automatisch erzeugt und dem Anwender über eine Benutzerschnittstelle angeboten werden. Üblicherweise werden die Alternativvorschläge auf dem Intermediär erzeugt und an das Entwicklungstool zur dortigen Ausgabe (vorzugsweise mit der Analysenachricht) übermittelt.

Für das Erzeugen und Bereitstellen der Alternativvorschläge kann vorteilhafter weise auf ein Kl - basiertes Tool zurückgegriffen werden, dass mit Trainingsdaten trainiert worden ist. Die Trainingsdaten umfassen eine Menge von unterschiedlichen Entwicklungsanfragen (formalisiert als Entwicklung Anfrage Nachrichten) in Kombination mit produktionsseitigen Zustandserfassungen (die zum Beispiel als Produktionsantwortnachricht formalisiert sein können) und zugeordneten Änderungsnachrichten in Bezug auf die Entwicklungsseite. Die Änderungsnachricht charakterisiert jeweils, welche entwicklungsseitigen Änderungen vorgenommen werden müssen, sodass diese bei dem aktuellen produktionsseitigen Zustand realisiert und umgesetzt werden können. Dabei sollten die entwicklungsseitigen Änderungen derart ausgebildet sein, dass die ursprünglich gewünschte Entwicklungsaufgabe immer noch erfüllt werden kann. Mit anderen Worten wird hier die Frage beantwortet, wie der Entwicklungsprozess geändert werden kann, um einerseits nach wie vor die Entwicklungsaufgabe zu lösen und andererseits den Vorgaben der Produktion zu entsprechen. Beispielsweise könnte ein Änderungsvorschlag lauten: “Anzahl der verfügbaren Laser [oder anderer Subsysteme] erhöhen“ oder „Bundsteg 1 mm schmäler konstruieren, damit ausreichend Bauraum bereitgestellt werden kann“.

Der Analysealgorithmus kann auch das Erzeugen von Optimierungsvorschlägen umfassen. Die Optimierungsvorschläge können sich einerseits auf eine Optimierung des Entwicklungssystems bzw. Entwicklungstools beziehen, sodass die produktionsseitigen Vorgaben erfüllt werden können. Andererseits können sich die Optimierungsvorschläge auch auf eine Optimierung des Produktionstools beziehen, sodass die entwicklungsseitigen Vorgaben erfüllt werden können. Mit anderen Worten kann hier eine Optimierungsnachricht generiert werden, die repräsentiert, welche entwicklungsseitigen und/oder produktionsseitigen Änderungen und Optimierungen vorgenommen werden können, sodass das bestehende Produktionssystem bzw. Entwicklungssystem möglichst optimal ausgenutzt werden kann/können. So können zum Beispiel Ergänzungen eines redundanten Betriebsmittels/Subsystems, zur Steigerung der Ausbringung und/oder der Taktzeit, eine Reduzierung der Vielfalt von C-Teilen, z.B. verschiedenartige Schrauben, um die Kapazität der bereits vorhandenen Betriebsmittel maximal auszunutzen (dadurch reduziert sich der notwendige Neu-Invest in Betriebsmitteln für Produktneuheiten.)

Generell dient der Intermediär zur Beantwortung von entwicklungsseitigen requests. Die Umsetzung kann nach dem Challenge - Response - Prinzip erfolgen. Das Entwicklungstool stellt eine Anfrage (Challenge) an den Intermediär und erhält von diesem eine passende Antwort (response). Die Response basiert vorzugsweise auf den Antworten, die das Produktionssystem automatisiert (ohne Eingabe eines Anwenders) auf die Anfrage geliefert hat und / oder die der Intermediär auf Basis der produktionsseitigen Antworten berechnet hat. Dies setzt grundsätzlich voraus, dass der Intermediär auf die Produktionsanfragenachricht auch eine Produktionsantwortnachricht generieren kann. Dies ist jedoch nicht immer möglich. Es gibt durchaus auch Situationen, in denen das Produktionssystem automatisch keine zufriedenstellenden Antworten bereitstellen kann. In diesen Fällen kann es sinnvoll sein, die entsprechende Anfrage an das Produktionssystem in Form der Produktionsanfragenachricht an einen oder mehrere zuständige Empfänger auf Seiten des Produktionssystems weiterzuleiten. Dazu kann ein Weiterleitungsassistent bereitgestellt werden, der die Produktionsanfragenachricht nach bestimmten Kriterien „parsed“, um automatisch einen Kreis von zuständigen Empfängern zu finden. Das Parsen der Produktionsanfragenachricht kann eine semantische Analyse umfassen, insbesondere in Hinblick auf vordefinierte Schlüsselwörter (keywords) auf Basis von historischen Daten kann dann auf eine Speicherstruktur zurückgegriffen werden, in der einem oder mehreren Schlüsselwörtern ein oder mehrere zuständige Empfänger zugeordnet sind. Dabei kann es sich zum Beispiel um E- Mail-Adressen, Telefonnummern oder Kontaktmöglichkeiten zu Personen handeln, von denen auf Basis von historischen Daten angenommen werden kann, dass sie die gestellte Frage/Anfrage beantworten können. Deren Antworten werden dann gesammelt und zurück an den Intermediär geleitet, der daraufhin in Antwort auf die gesammelten Daten die Analysenachricht erstellen kann.

In einer bevorzugten Ausführungsform kann der Intermediär auch auf ein elektronisches Ticketsystem zurückgreifen. Das Ticketsystem dient dazu, Entwicklungsanfragenachrichten des Entwicklungstools auf dem Intermediär zu verarbeiten. In einem ersten Schritt kann seitens des Intermediär versucht werden, die erfasste Anfrage des Entwicklungstools selbstständig und ohne Weiterleitung an das Produktionssystem zu beantworten. Dies kann auf Basis von historischen Anfragen und Antworten und oder unter Zugriff auf ein Kl-basiertes Tool erfolgen. Falls die selbstständige Beantwortung nicht möglich ist, kann die Anfrage in einem zweiten Schritt an ein Ticketsystem weitergeleitet werden. Das Ticketsystem dient dazu, die Anfragen - möglicherweise von mehreren, unterschiedlichen Entwicklungstool-seitigen Sendern - zu sammeln und auf koordinierte (und/oder priorisierte) Art und Weise an das Produktionssystem und insbesondere an zumindest einen Produktionstool-seitigen Empfänger weiterzuleiten. Bei dem Sender/Empfänger kann es sich um einen Automaten (Maschine, Bot) und/oder um einen Anwender handeln, der über eine Benutzeroberfläche mit dem System interagiert.

In einer bevorzugten Ausführungsform kann der Analysealgorithmus eine Auswerte-Funktion umfassen. Die Auswerte-Funktion dient dazu, vordefinierbare Zusatzanforderungen, die von dem Entwicklungstool an das Produktionstool gestellt werden, auf Erfüllbarkeit zu analysieren. Mit dieser Zusatzfunktion ist es beispielsweise möglich, dass auf dem Entwicklungstool eine Maske bereitgestellt wird, über die der Entwickler zum Beispiel branchenspezifische Angaben zu Anforderungen an z.B. die Genauigkeit, die Reinheit und/oder die Geschwindigkeit etc. eingeben kann. Die auf dieser Maske bereitgestellten Daten werden an den Intermediär weitergeleitet, der daraufhin - und möglicherweise unter Zugriff auf das Produktionstool - auswertet, ob die gestellten Anforderungen im aktuellen Produktionssystem erfüllbar sind oder nicht. Je nach Ergebnis, kann die Analysenachricht ein entsprechende Teilergebnis als Bestandteil der Analysenachricht als Antwort umfassen. Dies hat den technischen Vorteil, dass zusätzliche entwicklungsseitigen Anforderungen an das Produktionssystem noch genauer und spezifischer analysiert werden können.

In einer weiteren vorteilhaften Ausführungsform kann die Entwicklungsanfragenachricht Metadaten zu dem zu fertigenden Werkstück bzw. Produkt umfassen. Die Metadaten können sich beispielsweise auf „Beziehungswissen“ beziehen. „Beziehungswissen“ meint hier das Wissen überden (technischen) Zusammenhang zwischen Werkstück und Betriebsmittel. Dazu zählen folgende Aspekte: Auf welchem Betriebsmittel kann ein bestimmtes Werkstück gefertigt werden? Wie lange ist die Bearbeitungszeit auf der jeweiligen Maschine? In welcher Reihenfolge werden die Betriebsmittel getaktet? Beispiele für Metadaten sind alle Informationen zum Werkstück (CAD-Daten, Geometriedaten, Werkstoffdaten, ...). In einer vorteilhaften Weiterbildung kann aus der Analysenachricht automatisiert ein Montageplan erzeugt werden. Damit kann vorteilhafterweise der Automatisierungsgrad der Entwicklung/Produktion erhöht werden. Der Montageplan enthält Informationen zur Montage des zu fertigenden Werkstücks/Bauteils. In einer bevorzugten Ausführungsform der Erfindung erzeugt der Intermediär den Montageplan. Der Montageplan enthält bspw. Durchlaufzeiten, Zykluszeiten, sowie Reihenfolgen- und Rezepturdaten.

In einer weiteren, vorteilhaften Ausführungsform kann die Analysenachricht eine Auswahl von als verfügbar erfassten Produktionsmitteln (produktionsseitige Betriebsmittel) für die jeweilige Entwicklungsanfrage (repräsentiert in der Entwicklungsanfragenachricht) umfassen. Damit kann vorteilhafter Weise ein zusätzlicher Austausch zwischen Entwicklung und Produktion geschaffen werden und dem Entwickler kann zusätzliche Information an die Hand gegeben werden, welche Produktionsmittel für seine Entwicklungslösung erforderlich sind.

In einer anderen, bevorzugten Ausführungsform der Erfindung kann der Intermediär eine Ein- und Ausgabeschnittstelle umfassen, um alle oder ausgewählte Nachrichten auszugeben und/oder Steuerdaten zu empfangen (z.B. eingebbar auf einer Maske einer Benutzeroberfläche). Insbesondere kann die Ausgabeschnittstelle dazu dienen, die Analysenachricht und/oder die zugehörige Entwicklungsanfragenachricht auszugeben. Die Ausgabeschnittstelle kann darüber hinaus dazu dienen, eine - spezifisch und lokal auf dem Intermediär erzeugte - Machbarkeitsergebnisnachricht auszugeben. Die Machbarkeitsergebnisnachricht repräsentiert, ob die entwicklungsseitigen Anforderungen gegenwärtig produktionsseitig umsetzbar sind. Damit kann dem Entwickler vorteilhafterweise sehr frühzeitig, nämlich noch im Entwicklungsprozess mehr Information über das bestehende Produktionssystem bereitgestellt werden kann, sodass der Entwickler möglicherweise Änderungen vornehmen kann, um besser an die gegenwärtigen produktionsseitigen Ressourcen angepasst entwickeln zu können.

Vorstehend wurde die Lösung der Aufgabe anhand des Systems (also vorrichtungsbasiert, beispielsweise auf ein System oder auf einen Intermediär gerichtet sind) beschrieben. Dabei erwähnte Merkmale, Vorteile oder alternative Ausführungsformen sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen und umgekehrt. Mit anderen Worten können auch die Verfahrens-bezogenen Ansprüche (die) mit den Merkmalen weitergebildet sein, die in Zusammenhang mit den Vorrichtungen beschrieben und/oder beansprucht sind. Die entsprechenden funktionalen Merkmale des Verfahrens werden dabei durch entsprechende gegenständliche Module, insbesondere durch Hardware-Module oder Mikroprozessor-Module, des Systems bzw. des Produktes ausgebildet und umgekehrt. So wird beispielsweise das Empfangen einer Nachricht mittels einer entsprechenden Schnittstelle ausgebildet.

In einem weiteren Aspekt bezieht sich die Erfindung auf ein computer-implementiertes Verfahren zum Austausch von elektronischen Nachrichten zwischen einem elektronischen Entwicklungstool und einem elektronischen Produktionstool. Das Verfahren wird vorzugsweise auf einem Intermediär ausgeführt. Das Verfahren kann folgende Schritte umfassen: optional: Bereitstellen einer Entwicklungsanfragenachricht über eine

Entwicklungsanfrageschnittstelle; optional: Transformieren der Entwicklungsanfragenachricht in eine

Produktionsanfragenachricht mittels eines Transformations-Algorithmus; optional: Senden der Produktionsanfragenachricht über eine

Produktionsanfrageschnittstelle an das Produktionstool;

Bereitstellen oder Empfangen einer Produktionsantwortnachricht auf dem Intermediär; die Produktionsantwortnachricht kann erstens autonom auf dem Intermediär generiert werden und/oder kann zweitens unter Zugriff auf das Produktionstool generiert werden durch Empfangen der Produktionsantwortnachricht über eine Produktionsantwortschnittstelle; auch Mischformen sind möglich, bei denen ein Teil der Produktionsantwortnachricht auf dem Intermediär und ein anderer Teil auf dem Produktionssystem erzeugt wird;

In Antwort auf die empfangene Produktionsantwortnachricht: Erzeugen einer Analysenachricht;

Senden der erzeugten Analysenachricht über eine Analyseschnittstelle an ein Entwicklungstool.

Die vorstehend als „optional“ gekennzeichneten Verfahrensschritte können auch entfallen, sodass der Intermediär nach dem Pushbetrieb betrieben wird. Der Pushbetrieb kennzeichnet sich dadurch, dass der Intermediär selbstständig nach einem vordefinierten Schema (Zeit basiert oder Ereignis passiert) aktiv wird und das Entwicklungstool bzw. den Entwickler proaktiv über den aktuellen Zustand des Produktionssystems informiert, ohne dass der Entwickler gezielte Anfragen an den Intermediär richten muss. Im Gegensatz dazu, kann der Intermediär auch im Pullbetrieb betrieben werden. In dieser Ausführungsform werden die drei vorstehend als „optional“ gekennzeichneten Verfahrensschritte zwingend ausgeführt bevor die Schritte des Bereitstellen oder Empfangen, Erzeugen und Senden ausgeführt werden. Der Pullbetrieb kennzeichnet sich dadurch, dass gezielt entwicklungsseitige Anfragen in Hinblick auf das Produktionssystem an den Intermediär gerichtet werden, die dann beantwortet werden. Die Anfragen können, wie vorstehend bereits geschrieben, entweder direkt auf dem Intermediär verarbeitet und beantwortet werden oder können an das Produktionssystem zur Beantwortung weitergeleitet werden.

Eine weitere Aufgabenlösung besteht in einem Computerprogrammprodukt, das in einen Speicher eines Computers oder eines elektronischen Gerätes geladen oder ladbar ist mit einem Computerprogramm zur Durchführung des oben näher beschriebenen Verfahrens, wenn das Computerprogramm auf dem Computer oder dem Gerät ausgeführt wird.

Eine weitere Aufgabenlösung sieht ein Computerprogramm vor zur Durchführung aller Verfahrensschritte des oben näher beschriebenen Verfahrens, wenn das Computerprogramm auf einem Computer, einem elektronischen Gerät ausgeführt wird. Dabei ist es auch möglich, dass das Computerprogramm auf einem für den Computer oder das elektronische Gerät lesbaren Medium gespeichert ist.

Im Folgenden werden die in dieser Anmeldung verwendeten Begrifflichkeiten näher definiert.

Das Entwicklungstool ist als ein Software Tool zu verstehen und dient zur rechnerunterstützten Konstruktion und Entwicklung. Es kann zum Beispiel als CAD - Tool ausgebildet sein. Es umfasst Schnittstellen zum Datenaustausch. Zusätzlich kann ein Userinterface zur Ein- und Ausgabe von Daten bereitgestellt sein. Das Entwicklungstool kann eine Stückliste für das zu fertigende Produkt ausgeben (BOM - Bill of Materials oder MBOM - manufacturing bill of materials).

Entsprechend ist auch das Produktionstool ein softwarebasiertes Tool und dient zur rechnergestützten Fertigung bzw. Produktion. Es ist mit entsprechenden Schnittstellen zum Datenaustausch ausgebildet. Das Produktionstool kann z.B. als Computer-aided manufacturing (CAM-Tool) ausgebildet sein. Auch das Produktionstool kann mit einem Userinterface ausgebildet sein. Grundsätzlich muss die Möglichkeit einer Eingabe zugelassen und bereitgestellt werden, sodass die Anlage und Verwaltung von Betriebsmitteln und deren Fähigkeiten möglich ist. Wichtig ist, das Zusammenspiel mit der Produktentwicklung. Das Produktionstool kann auch als eine Mischung aus MES (Manufacturing and Execution System) Auftragsplanung- und Verwaltung, Feinplanungstool und PLM-System verstanden werden.

Die Entwicklungsanfrageschnittstelle, die Produktionsanfrageschnittstelle, die Produktionsantwortschnittstelle und/oder die Analyseschnittstelle sind als logische und/oder physikalische Schnittstellen zu verstehen. Sie dienen zur Interaktion des Intermediärs mit externen computerbasierten Instanzen bzw. Software Tools. Die Entwicklungsanfrageschnittstelle und die Analysenachrichtschnittstelle können als zwei separate Schnittstellen ausgebildet sein. Alternativ können die vorstehend genannten Entwicklungstool-bezogenen Schnittstellen auch in eine Schnittstelle integriert sein. Sie dienen insbesondere zur datentechnischen Verbindung des Intermediär das mit dem Entwicklungstool. Die Produktionsanfrageschnittstelle und die Produktionsantwortschnittstelle können ebenfalls als zwei separate Schnittstellen ausgebildet sein. Alternativ können die Produktions-bezogenen Schnittstellen auch in eine Schnittstelle integriert sein. Die produktionsbezogenen Schnittstellen dienen insbesondere zur datentechnischen Verbindung des Intermediär das mit dem Produktionstool. Die vorstehend genannten Schnittstellen der beteiligten Verarbeitungsinstanzen (Entwicklungstool, Intermediär, Produktionstool) bilden ein verteiltes Datenverarbeitungssystem und halten zur Datenverarbeitung Algorithmen und Programme in Speichern (zum Beispiel RAM, SRAM, CPU Cache Speicher) und/oder in nicht volatilen Speichern (zum Beispiel ROM, PROM, EPROM etc.). Beispielsweise können die volatilen Speichereinheiten zur vorübergehenden Speicherung von Programm Dateien zur Ausführung von Programmelementen dienen und die nicht volatilen Speichereinheiten können Bootstrapcode des jeweiligen Betriebssystems des Datenverarbeitungssystems umfassen. Das Datenverarbeitungssystem umfasst eine computerbasierte Verarbeitungseinheit oder ein Cluster von Computern. Das Datenverarbeitungssystem kann insbesondere zumindest eine Prozessoreinheit zur Datenverarbeitung umfassen. Die Prozessoreinheit umfasst üblicherweise eine CPU und/oder eine GPU und eine Menge von Softwaremodulen, die jeweils eingerichtet sind, um die vorstehend beschriebenen Verfahrensschritte der vorliegenden Anmeldung auszuführen. Die Prozessoreinheit kann insbesondere dazu eingerichtet sein, den Transformations-Algorithmus und/oder den Analysealgorithmus auszuführen. Das Datenverarbeitungssystem kann auf unterschiedliche computerbasierte Entitäten aufgeteilt sein und somit kann ein Teil der erfindungsgemäßen Funktionalität auf dem Entwicklungstool, ein anderer Teil auf dem Intermediär und ein weiterer Teil der Funktionalität kann auf dem Produktionstool ausgeführt werden. Die computerbasierten Entitäten stehen dazu über zumindest ein Netzwerk (drahtlos oder Draht gebunden) in Datenaustausch. Das Datenverarbeitungssystem kann darüber hinaus einen Netzwerkcontroller (NIC) umfassen. Das Netzwerk kann zum Beispiel als Intranet, Internet oder als Mobilfunknetz ausgebildet sein.

Das Verfahren führt mehrere Algorithmen aus, insbesondere den Transformations- Algorithmus und den Analysealgorithmus. Ein Algorithmus ist eine Sammlung bzw. eine Abfolge von Befehlen zur Verarbeitung von Eingangsdaten, um maschinell Ausgangsdaten zu berechnen. Die Befehle eines Algorithmus können in Software implementiert sein und auf einem Prozessor des Datenverarbeitungssystems ausgeführt werden. Alternativ oder kumulativ können die Befehle des Algorithmus auch in Hardware auf entsprechenden Mikroprozessorbausteinen implementiert sein (zum Beispiel FGPA, ASIC).

Bei dem Ticketsystem handelt es sich um ein elektronisches System zur Verarbeitung von Daten. Der Begriff „Ticket“ ist hier nicht als physikalisches Ticket, sondern als elektronisches, digitales und logisches Ticket zu verstehen. Das Ticket kann zum Beispiel als Code oder Datenstring implementiert sein.

Weitere Vorteile, Merkmale und alternative Ausführungsformen der Erfindung ergeben sich aus der nachfolgenden Beschreibung, in der - unter Bezugnahme auf die Zeichnungen - Ausführungsbeispiele beschrieben sind. Dabei können die in den Ansprüchen und in der Beschreibung erwähnten Merkmale jeweils einzeln für sich oder in beliebiger Reihenfolge und Kombinationserfindung wesentlich sein.

Kurze Beschreibung der Figuren

Fig. 1 zeigt in einer schematischen Überblicksdarstellung wesentliche Bestandteile des Datenverarbeitungssystems gemäß einer bevorzugten Ausführungsform;

Fig. 2 ist ein Sequenzdiagramm zur Darstellung des Datenaustausches zwischen den beteiligten Instanzen gemäß einer bevorzugten Ausführungsform der Erfindung;

Fig. 3 zeigt einen im Vergleich zu Fig. 2 alternativen Datenaustausch zwischen den beteiligten Instanzen gemäß einer weiteren bevorzugten Ausführungsform der Erfindung;

Fig. 4 ist eine exemplarische Schema-Darstellung mit elektronischen Komponenten eines Intermediärs;

Fig. 5 ist eine schematische Darstellung einer Produktionsantwortnachricht; Fig. 6 ist ein Ablaufdiagramm eines Verfahrens gemäß einer vorteilhaften

Ausführungsform der Erfindung und

Fig. 7 ist ein Ablaufdiagramm eines Verfahrens gemäß einer vorteilhaften

Ausführungsform der Erfindung.

Detaillierte Beschreibung der Figuren

Die vorliegende Erfindung liegt auf dem Gebiet der Automatisierungstechnik und betrifft den standardisierten Datenaustausch zwischen der Entwicklung und der Produktion über eine entsprechende digitale Plattform, nämlich einen Intermediär.

Die vorliegende Erfindung dient dazu, die Entwickler frühzeitig und schon in der Entwicklungsphase über die in der Produktion vorhandenen Produktions- und Betriebsmittel zu informieren und einen standardisierten Austausch von relevanten Informationen zwischen den Systemen zu ermöglichen. Das Zusammenspiel zwischen Konstruktion und Produktion soll verbessert werden. Auch der Produktionsablauf soll verbessert werden, indem Produktionsmittel und/oder Produktionsvorrichtungen nicht mehr nach abgeschlossener Entwicklung auf Basis der Vorgaben der Entwicklung angepasst und/geändert werden müssen, sondern bereits im Entwicklungsprozess Berücksichtigung finden. Damit können Kosten und Zeit eingespart werden. Darüber hinaus soll der Datenaustausch standardisiert und formalisiert werden, indem insbesondere bestimmte Informationen und Nachrichten fakultativ bereitgestellt werden. Somit wird ein Datenaustausch gemäß einem variable vorkonfigurierbaren Schema zwischen den beiden Systemen quasi „erzwungen“. Damit kann die Effizienz des gesamten Entwicklung - und Produktionsprozesses signifikant verbessert werden. „Variabel vorkonfigurierbar“ meint hier, dass in einer vorbereitenden Konfigurationsphase über eine Benutzerschnittstelle definiert werden kann, von welcher Instanz welche Nachrichten/Informationen angefordert werden. Hier kann z.B. festgelegt sein, dass zunächst immer eine Entwicklungsanfragenachricht ean abgewartet wird, bevor der Intermediär mit dem Produktionssystem bzw. -Tool PT interagiert.

Der Entwickler soll in einer sehr frühen Phase des Entwicklungsprozesses automatisiert das notwendige, detailspezifische Wissen über die Fähigkeiten/Funktionalitäten bzw. Skills der vorhandenen Betriebsmittel und Prozesse im Produktionstool erhalten, um damit seine Konstruktion an die vorhandenen Betriebsmittel und Prozesse anpassen zu können. Durch eine bessere Auslastung können Kosten für die Beschaffung zusätzlicher Betriebsmittel reduziert werden. Die Transparenz der entwicklungsseitigen und produktionsseitigen Prozesse kann verbessert werden. Vorteilhafterweise können die Herstellungskosten gesenkt werden, da in vielen Fällen eine Neubeschaffung von produktionsseitigen Betriebsmitteln eliminiert oder zumindest minimiert werden kann. Ein weiterer Vorteil ist darin zu sehen, dass eine unmittelbare produktionsseitige Rückmeldung zu den Zykluszeiten in den Prozessen und den damit verbundenen Herstellungskosten bereitgestellt werden kann.

Bei dem Intermediär handelt es sich vorzugsweise um eine Cloud basierte Anwendung. Der Intermediär kann dezentral oder zentral betrieben werden. Das Betreiben des Intermediärs bzw. die Ausführung der entsprechenden Algorithmen kann grundsätzlich von unterschiedlichen Instanzen aus getriggert werden. Zum einen kann der Intermediär von dem Entwicklungstool getriggert werden. Zum anderen kann der Intermediär bzw. der darauf implementierten Algorithmen von dem Produktionstool getriggert werden. Ebenso ist es möglich, dass auf dem Intermediär ein Ausführungsschema hinterlegt ist, das definiert, zu welchem Zeitpunkt, welche Nachrichten an welche Instanz zu senden sind. So kann beispielsweise ein erstes Ausführungsschema hinterlegt sein, das definiert, dass am Ende jedes Werktages oder nach einem anderen zeitbasierten Schema ein Austausch zwischen dem Entwicklungstool und dem Produktionstool stattfindet. Insbesondere soll das Entwicklungstool gemäß diesem Ausführungsschema über die aktuellen Ressourcen und Bedingungen des Produktionstools informiert werden.

Figur 1 zeigt in einer überblicksartigen Darstellung das Datenverarbeitungssystem mit den beteiligten Instanzen, insbesondere mit einem Entwicklungstool ET, einem Intermediär I und einen Produktionstool PT. Alle drei vorstehend genannten Instanzen sind computerbasierte Instanzen und können Softwareanteile und/oder Hardwareanteile umfassen und werden zusammenfassend als Datenverarbeitungssystem bezeichnet und interagieren über ein Netzwerk NW, das z.B. als WLAN, LAN oder als anderweitiges Funknetz oder digitales Netzwerk ausgebildet sein kann. Das Entwicklungstool ET und das Produktionstool PT umfassen zumindest einen Prozessor P, einen Monitor M und einen Speicher S. Der Intermediär I umfasst zumindest einen Prozessor, der in den Figuren ebenfalls mit dem Bezugszeichen P gekennzeichnet ist. Alle drei computerbasierte Instanzen stehen über ein Netzwerk (drahtlos oder Draht gebunden) in Datenaustausch. In einer Ausführungsform kann das Entwicklungstool ET eine Entwicklungsanfragenachricht ean über eine Entwicklungsanfrageschnittstelle EAS an den Intermediär I senden. Der Intermediär I wendet auf die empfangene Entwicklungsanfragenachricht ean einen Transformations-Algorithmus TA an, um eine Produktionsanfragenachricht pafn zu erzeugen und diese über eine Produktionsanfrageschnittstelle PANFS an das Produktionstool PT zu senden. Das Produktionstool PT erarbeitet in Antwort auf die empfangene Produktionsanfragenachricht pafn eine Produktionsantwortnachricht patn und sendet diese über eine Produktionsantwortschnittstelle PANTS an den Intermediär I. Der Intermediär I wendet daraufhin auf die empfangene Produktionsantwortnachricht patn einen Analysealgorithmus AA an, um eine Antwortnachricht an zu erzeugen und über eine Analyseschnittstelle ANS an das Entwicklungstool ET zurückzusenden. Für den Fachmann liegt es auf der Hand, dass die auf dem Intermediär I erzeugten Nachrichten auch über eine Benutzerschnittstelle (nicht gezeigt) ausgegeben werden können. Insbesondere können die erzeugten Nachrichten an das Entwicklungstool ET und/oder an das Produktionstool PT übermittelt werden, um auf den dortigen lokalen Monitoren M zur Darstellung gebracht werden zu können, wenn der Intermediär I als Cloud-basierte Applikation ausgebildet ist. Alternativ kann der Intermediär I auch als Server ausgebildet sein und direkt eine Benutzerschnittstelle zur Ein - und Ausgabe von Daten umfassen.

In Figur 2 ist der Datenaustausch zwischen den beteiligten Instanzen in Form eines Sequenzdiagrammes gemäß einer Ausführungsform näher dargestellt. In dieser Ausführungsform wird die Vermittlungsplattform bzw. der Datenaustausch zwischen Entwicklungstool ET und Produktionstool PT vom Entwicklungstool ET aus getriggert. Auf dem Entwicklungstool ET kann eine Exportfunktion EF angewendet werden, um aus einem Konstruktionsdatensatz eines Konstruktionstools, zum Beispiel eines CAD - Tools, eine Entwicklungsanfragenachricht ean zu erzeugen. Die Entwicklungsanfragenachricht ean wird dann an den Intermediär I gesendet. Der Intermediär I wendet den Transformations- Algorithmus TA an, um die Produktionsanfragenachricht pafn zu erzeugen und an das Produktionstool PT zu senden. In der in Figur 2 dargestellten Ausführungsform ermittelt das Produktionstool PT eine Produktionsantwortnachricht patn und übermittelt diese an den Intermediär I. Alternativ ist es jedoch auch möglich, den Intermediär I mit weiterer Intelligenz auszustatten, zum Beispiel durch Aufspielen von intelligenten Algorithmen, sodass der Intermediär I selbstständig aus der Produktionsanfragenachricht pafn eine Produktionsantwortnachricht patn erzeugen kann, ohne dass er dazu auf das Produktionstool PT zugreifen muss. Nachdem die Produktionsantwortnachricht patn auf dem Intermediär I bereitgestellt ist (entweder durch Empfangen oder durch lokale, eigene Berechnung), kann der Analysealgorithmus AA daraus eine Analysenachricht an berechnen, um diese zurück an das Entwicklungstool ET zu senden.

Nach Empfang der Analysenachricht an auf dem Entwicklungstool ET kann dort eine Ausgabefunktion AFE ausgeführt werden, um die Analysenachricht an zum Beispiel auf einem Monitor M auszugeben. Es ist auch möglich eine Ausgabefunktion auf dem Intermediär I zu implementieren, der eine Ausgabe auf einer Menge von bestimmbaren Geräten auslöst.

In einer vorteilhaften Variante der Erfindung, die in Fig. 2 gepunktet dargestellt ist, kann die Analysenachricht an oder zumindest ein Teil davon auch an eine produktionsseitige Ausgabefunktion AFP zur Anzeige auf einer Ausgabeeinheit an das Produktionstool PT übertragen werden. Dies erhöht die Transparenz des Datenverarbeitungssystems. Auch beide Ausgabefunktionen AFE , AFP können implementiert sein.

In einer weiteren vorteilhaften Ausführungsform der Erfindung kann eine Auswerte-Funktion implementiert sein und ausgeführt werden. Die Auswerte-Funktion (in den Figuren nicht extra dargestellt) dient zum Auswerten, ob vordefinierbare Zusatzanforderungen an das Produktionstool erfüllbar sind, dazu zählen z.B. zeitliche oder sonstige Prozessanforderungen, qualitative Anforderungen. Die Auswerte-Funktion kann auf erfassten Metadaten basieren. Die Auswerte-Funktion kann auch eine Machbarkeitsfunktion umfassen, um zu repräsentieren, ob die Anforderungen bzw. der Zustand (Ressourcen, Zustand, Gegebenheiten) der beiden Systeme ET, PT in Übereinstimmung gebracht werden können.

Alternativ oder kumulativ kann ein Montageplanalgorithmus MPA ausgeführt werden, der auf Basis der empfangenen Analysenachricht an automatisch einen Montageplan erzeugt. Der Montageplan kann entweder über den Intermediär vermittelt (indirekt) oder direkt an das Produktionstool PT übermittelt werden. In einer bevorzugten Ausführungsform der Erfindung kann auf dem Entwicklungstool eine weitere Funktionalität implementiert sein, nämlich eine Geometrie- und Prozessfunktion GP zum Abgleich von Geometrie- und Prozessdaten zwischen Entwicklungstool ET und Produktionstool PT. Hier können insbesondere folgende Datensätze berücksichtigt und verrechnet werden:

Betriebsmitteldaten, wie z.B. Herstellerangaben und/oder Daten zu Baujahr, Typbezeichnung, vorhandenen Werkzeugen etc.; Produktdaten/eigenschaften, wie z.B. Daten zu Gehäusetyp, Material und/oder Gewicht, etc.

Geometriedaten, wie z.B. Daten zu Abmessungen (in allen drei Raumachsen), Durchmesser, Symmetrien und/oder Schraubenkopfform etc.

Prozessdaten und -Merkmale, wie z.B. Daten zu Haltestromabsenkung, Einpresskraft, Montagetiefe, Beschriftungsart, Druck, etc.

Prüfdaten, wie z.B. Prüf-Haltestromabsenkung, Prüfmedium, Prüfungspannung, Prüfdruck, Prüfstrom etc.

Umweltdaten, wie z.B. Außentemperatur, Luftdruck, Feuchtigkeit, Vakuum etc.

Qualifikationsdaten, wie z.B. eine Zertifizierung, Schulungsdaten, die repräsentieren, ob die Mitarbeiter ausreichend qualifiziert sind und ob z.B. eine vordefinierbare Schulung erfolgt ist etc.

In Figur 3 ist eine im Vergleich zu Figur 2 alternative Ausführungsform des Datenaustausches dargestellt. In dem in Fig. 3 dargestellten Beispiel wird der Datenaustausch von dem Intermediär I aus angestoßen. Grundsätzlich kann vorgesehen sein, dass sich das Entwicklungstool ET und/oder das Produktionstool PT erst bei dem Intermediär I zur Teilnahme an dem Datenaustausch anmelden müssen. Hier können Berechtigungsdaten und Authentifizierungsprozeduren ausgeführt werden, um die Sicherheit des Datenaustausches zu erhöhen. Dazu werden ein Datensatz init _E von dem Entwicklungstool ET an den Intermediär I und/oder ein Datensatz initpvon dem Produktionstool PT an den Intermediär I gesendet. Da dies optional ist, sind diese Datenübertragungen in Figur 3 gepunktet dargestellt. Die Authentifizierungsprozedur kann zum Beispiel Passwort-basiert sein oder nach einem symmetrischen oder asymmetrischen kryptographischen Verfahren und/oder gemäß einem biometrischen Verfahren (bestimmt für authentifizierte Anwender der T ools ET ; PT) ausgeführt werden. Nach erfolgreicher Authentifizierung kann auf dem Intermediär I ein abgewandelter Transformations-Algorithmus TA‘ ausgeführt werden, der eine standardisierte, vor konfigurierte Produktionsanfragenachricht pafn erzeugt, ohne dass er eine Entwicklungsanfragenachricht erhalten hat. Der modifizierte Transformations-Algorithmus TA‘ ist einfacher ausgebildet als der Transformations-Algorithmus TA und kann beispielsweise bestimmte, vorkonfigurierte Parameter nach einem Zeitschema von dem Produktionstool PT erfragen. Der modifizierte Transformations-Algorithmus TA‘ unterscheidet sich von dem ist Transformations-Algorithmus TA insbesondere dadurch, dass keine Entwicklungsanfragenachricht ean für dessen Ausführung notwendig ist. Die Analysenachricht an kann somit autonom bereitgestellt werden. Der Intermediär I agiert damit als autarker Knoten im Netzwerk NW. Die entsprechende Produktionsantwortnachricht patn, wird daraufhin wieder über den Analysealgorithmus AA in eine Analysenachricht an umgesetzt und an das Entwicklungstool ET übersendet. Dort können noch weitere Maßnahmen angestoßen werden, wie sie beispielsweise in Zusammenhang mit Figur 2 bereits beschrieben worden sind.

In Figur 4 ist schematisch dargestellt, dass der computerbasierte Intermediär I, der als Vermittlungsknoten zwischen dem Entwicklungstool ET und dem Produktionstool Tool PT dient, zumindest einen Prozessor P umfasst. Der Prozessor P ist ausgebildet, den Transformations-Algorithmus TA bzw. den modifizierten Transformations-Algorithmus TA‘ und den Analysealgorithmus AA auszuführen. Bei Bedarf können noch weitere Software Module mit weiteren Funktionalitäten bereitgestellt werden. Ebenso kann zumindest ein Speicher S bereitgestellt werden, um die Zwischenergebnisse und Ergebnisse zu speichern. Dies erweist sich insbesondere dann sinnvoll, wenn ein Algorithmus der künstlichen Intelligenz angewendet werden soll, um weitere Datenverarbeitungen auszuführen. Weitere Datenverarbeitungen können sich zum Beispiel darauf beziehen, automatisch Änderungsvorschläge für das Entwicklungstool ET zu erzeugen, falls die Anforderungen des Konstrukteurs/Entwicklers derzeit nicht mit den Produktionsmitteln des Produktionssystems erfüllt werden können und es von daher sinnvoll ist, dass Werkstück oder Produkt modifiziert zu entwickeln, sodass keine weiteren Änderungen am Produktionssystem durchgeführt werden müssen. Insbesondere kann hier ein künstliches neuronales Netz (artificial neural network, ANN) Anwendung finden, das zu einem Tupel aus entwicklungsseitigen Vorgaben, formalisiert in der Entwicklungsanfragenachricht ean und produktionsseitigen Möglichkeiten, formalisiert in der Produktionsantwortnachricht patn , einen Änderungsdatensatz zur Änderung bzw. Anpassung der Entwicklung an die Möglichkeiten des Produktionssystems erzeugt. Das ANN kann mit gespeicherten Trainingsdaten trainiert worden sein. Die Trainingsdaten umfassen Daten, die eine vorteilhafte bzw. korrekte Zuordnung von Entwicklungsanfragenachrichten ean und Produktionsantwortnachrichten patn bzw. Analysenachrichten an repräsentiert. Das ANN kann insbesondere als tiefes neuronales Netz (Deep Neural Network, DNN), als Faltungsnetz (convolutional nerual network, CNN) oder als ein Netzwerk mit anderer Topologie ausgebildet sein. Ebenso können andere maschinelle Lernmethoden zum Einsatz kommen, wie zum Beispiel ein Entscheidungsbaum, Random Forest Verfahren, eine Support Vector Machine (SVM) o. ä. Verfahren. Ziel dieser Ansätze ist es jeweils, auf Basis der vorhandenen Informationen eine Produktionsantwortnachricht patn und/oder eine Analysenachricht an zu erzeugen. Dazu können historische Daten und/oder Trainingsdaten ausgewertet werden. Wie in Figur 4 schematisch angedeutet, kann auf dem Intermediär I ein digitales Modell DM des Produktionstools PT gespeichert sein, um maschinell Berechnungen für die Analysenachricht ausführen zu können.

Die Produktionsantwortnachricht patn hat erfindungsgemäß eine vor-konfigurierte, bestimmte Struktur. Diese ist in Figur 5 dargestellt. Die Produktionsantwortnachricht patn kann in einer vorteilhaften Ausführungsform zumindest zwei unterschiedliche Abschnitte umfassen, nämlich einen Betriebsmittelabschnitt bma und einen Betriebsmittelfunktionalitätsabschnitt bmfa. Der Betriebsmittelabschnitt bma kennzeichnet die im Produktionssystem PT aktuell verfügbaren Betriebs/Produktionsmittel. Dabei handelt es sich zum Beispiel um Ventile, Schalter, Strom- /Spannungsversorgungsmodule etc. Der Betriebsmittelfunktionalitätsabschnitt bmfa kennzeichnet die im Produktionssystem PT aktuell ausführbaren Funktionen. Da die Funktionalität in der Regel von den jeweiligen Betriebs - und Produktionsmitteln abhängt, kann der Betriebsmittelfunktionalitätsabschnitt bmfa auch aus dem Betriebsmittelabschnitt bma berechnet werden. Beispielsweise können über Seriennummern oder Datamatrixcodes am Betriebsmittel die Funktionen über herstellerspezifische oder -neutrale Funktionsdatenbanken "heruntergeladen" werden.

Ein anderer Weg wäre die Generierung generischer Funktionen auf Basis grober Selektionsmöglichkeiten (Steuerung, Sensor, Aktor, Bearbeitungsraum, ...), die im Nachgang durch das nachträgliche Hinzufügen spezifischer Funktionen ergänzt werden können.

Figur 6 zeigt ein Ablaufdiagramm eines Verfahrens gemäß einer ersten Ausführungsform der Erfindung. Das Verfahren mit all seinen Schritten wird auf dem Intermediär I ausgeführt. Nach dem Start des Verfahrens wird in Schritt S4 die Produktionsantwortnachricht patn von dem Produktionstool PT empfangen. Dies erfolgt über die Produktionsantwortschnittstelle PANTS. In Antwort auf die empfangene Produktionsantwortnachricht patn wird in Schritt S5 die Analysenachricht an erzeugt. In Schritt S6 wird die erzeugte Analysenachricht an über die Analyseschnittstelle ANS an das Entwicklungstool ET gesendet. Daraufhin kann das Verfahren enden oder nach einem vor-konfigurierten Schema (Zeit - oder Ereignis basiert) wiederholt werden. In einer ersten Variante kann die Produktionsantwortnachricht patn, die zum Auslösen des Datenaustausches zwischen Entwicklungstool ET um Produktionstool PT dient, von dem Intermediär I angefordert werden, vorzugsweise in einer separaten Anforderungsnachricht, die von dem Intermediär I an das Produktionstool PT gesendet wird (nicht gezeigt). In einer zweiten Variante kann die Produktionsantwortnachricht patn (selbstständig) von dem Produktionstool PT nach einem vor-konfigurierbaren Schema dem Intermediär I automatisch und ohne Anforderung zur Verfügung gestellt werden. Die Cloud- basierte Vermittlungsplattform zum Datenaustausch zwischen Entwicklungstool ET und Produktionstool PT wird hier vom Intermediär I oder vom Produktionstool PT aus angestoßen.

Figur 7 zeigt ein Ablaufdiagramm eines Verfahrens gemäß einer zweiten Ausführungsform der Erfindung. Das Verfahren mit all seinen Schritten wird auf dem Intermediär I ausgeführt. Nach dem Start des Verfahrens wird in Schritt S1 die Entwicklungsanfragenachricht ean über die Entwicklungsanfrageschnittstelle EAS von dem Entwicklungstool ET bereitgestellt. In Schritt S2 wird die empfangene Entwicklungsanfragenachricht ean mittels des Transformations-Algorithmus TA in die Produktionsanfragenachricht pafn transformiert. Daraufhin kann die so erzeugte Produktionsanfragenachricht pafn in Schritt S3 an das Produktionstool PT zur weiteren Verarbeitung (Schritte S4 bis S6) übermittelt werden. Im Unterschied zu der Ausführungsform, die oben in Bezug auf Figur 6 beschrieben worden ist, werden in Figur 7 auch die Schritte S1 bis S3 ausgeführt. Mit anderen Worten wird die Cloud- basierte Vermittlungsplattform in dieser Ausführung von dem Entwicklungstool ET aus angestoßen.

Zusammenfassend ist ein wichtiger vorteilhafter technischer Effekt des hier vorgestellten Ansatzes mit darin zu sehen, dass der Informationsaustausch zwischen dem Entwicklungstool ET und dem Produktionstool PT in ausreichendem Maß sichergestellt werden kann. In einer Konfigurationsphase kann konfiguriert werden, welche Nachrichten zu welchem Zeitpunkt an welchen Kommunikationspartner gesendet werden müssen. In einer Weiterbildung der Erfindung kann zusätzlich noch der Inhalt der auszutauschen Nachrichten definiert werden.

Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Alle in Verbindung mit einzelnen Ausführungsformen der Erfindung erläuterten und gezeigten Merkmale können in unterschiedlicher Kombination in dem erfindungsgemäßen Gegenstand vorgesehen sein, um gleichzeitig deren vorteilhafte Wirkungen zu realisieren. Es liegt somit z.B. ebenso im Rahmen der Erfindung alternativ oder kumulativ zu den genannten elektronischen Geräten und Bauteilen andere Bedien- und/oder Steuerelemente zum Betrieb der Intermediären Plattform bereitzustellen. Der Intermediär ist vorzugsweise als Cloud-basierte Applikation vorgesehen, kann aber auch in das Produktionssystem und/oder in das Entwicklungssystem integriert sein. Für einen Fachmann ist es jedoch insbesondere offensichtlich, dass andere Architekturen mit separaten, in Datenaustausch stehenden Einheiten ebenso angewendet werden können, ohne die erfinderische Idee zu verlassen. Anders können die Bauteile des Systems auf mehrere physikalische Produkte verteilt realisiert sein.

Der Schutzbereich der vorliegenden Erfindung ist durch die Ansprüche gegeben und wird durch die in der Beschreibung erläuterten oder den Figuren gezeigten Merkmale nicht beschränkt.