Ein mehrjähriges Forschungsprojekt konzentrierte sich auf den Übergang von der Entwicklung zur Produktion bei einem globalen Luft- und Raumfahrtunternehmen und insbesondere auf die Frage, wie produktionsbezogene Fragen viel früher im Entwicklungszyklus eines Programms beantwortet werden können, als dies heute möglich ist. Eine grundsätzliche Schwierigkeit besteht darin, dass der Zeitaufwand und das Fachwissen, die für die Formulierung geeigneter Analysemodelle erforderlich sind, deren routinemäßigen Einsatz verhindern, insbesondere bei der Entwicklung neuer Programme. Ziel des Projekts war es, diese Anforderungen zu verringern, und Ende 2014 wurde eine Methodik für die bedarfsgerechte Erstellung von Analysen zur Beantwortung von Routinefragen zu Produktionssystemen entwickelt. Im Jahr 2015 wurde ein Pilotprojekt durchgeführt, um die Wirksamkeit zu demonstrieren und zu zeigen, dass eine Implementierung der Methodik die Zeit, die für die Beantwortung einer häufig gestellten Frage benötigt wird, tatsächlich um mindestens eine Größenordnung reduzieren kann, und zwar auf wiederholbare Weise, während sich die Spezifikationen der Produkte, ihre Prozesspläne, geplanten Anlagen und verfügbaren Ressourcen häufig ändern. In diesem Beitrag werden die Methodik, die Umsetzung des Pilotprojekts und die vorläufigen Ergebnisse zusammengefasst.
Ein weltweit tätiges Luft- und Raumfahrtunternehmen möchte die Konstruktion seiner Produktionssysteme verbessern, indem es die wichtigsten Fragen bereits zu einem früheren Zeitpunkt im Produktlebenszyklus behandelt. Computer-Aided Design (CAD)- und Engineering (CAE)-Werkzeuge unterstützen Produktdesigner, indem sie auf Knopfdruck mechanische, luft- und raumfahrttechnische, thermische und andere Arten von Metriken zu Produktkandidaten auswerten können. Computergestützte Werkzeuge, die den Konstrukteuren von Produktionssystemen mit bedarfsgerechten Analysefunktionen helfen, sind jedoch eher begrenzt. Die Vision des Unternehmens ist es daher, die Werkzeugunterstützung für den Entwurf, die Diagnose und die kontinuierliche Verbesserung von Produktionssystemen zu verbessern, indem den Konstrukteuren auf Knopfdruck die Möglichkeit gegeben wird, Metriken und Fragen zur "Produzierbarkeit" zu bewerten:
Unabhängig von der Liste der Fragen geht es in der Forschung darum, wie man sie auf Knopfdruck beantworten kann, und es gibt mehrere Faktoren, die dies erschweren. Erstens erfordert die Fähigkeit, auf Knopfdruck zu antworten, die Formulierung und Lösung einer Vielzahl von Operations Research-Analysemodellen, einschließlich statistischer, ereignisdiskreter Simulations- und Optimierungsanalysemodelle.Lösungsmethoden und Algorithmen sind in der Literatur gut erforscht, nicht aber die Frage, wie man ein Analysemodell anhand einer analyse-neutralen Systembeschreibung und einer Frage zum System auf automatisierte, robuste und wiederverwendbare Weise formulieren kann. Zweitens kann die Spezifikation eines Produkts in frühen Entwurfsphasen nur auf einer hohen Abstraktionsebene vorliegen, was bedeutet, dass die Drucktastenfunktionalität einen unterschiedlichen Detailgrad aufweisen muss. Drittens werden zwar Informationen über Produkte und Prozesse in PLM-Systemen (Product Lifecycle Management) erfasst, nicht aber Informationen über Ressourcen und Anlagen - das Wissen über die Produktion ist in vielen Unternehmen oft informell, stillschweigend und flüchtig. Wenn die Architektur eines Unternehmens aus CAD, PDM (Product Data Management), MES (Manufacturing Execution Systems) und MRP (Manufacturing Resource Planning) besteht, fehlen in der Kombination dieser Systeme immer noch Informationen, die für die Beantwortung vieler Fragen zur Herstellbarkeit benötigt werden, einschließlich der oben genannten. Wenn ein Konstrukteur auf den Knopf drückt, sollte er daher auch erwarten, dass er zusätzliche Informationen liefert, was die Frage aufwirft, was genau diese Informationen sind, in welcher Sprache und in welchem Format sie vorliegen sollten und welche Flexibilität für ihre Ausführlichkeit besteht.
Eine Analogie für die Vision des Unternehmens ist die Erweiterung persönlicher Assistenten wie Apples Siri, Googles Sprachsuche oder Microsofts Cortana um zusätzliche Funktionen, die zur Beantwortung von Fragen zur Produzierbarkeit von Entwürfen benötigt werden. Um zu verstehen, inwiefern sich die benötigte Funktionalität von dem unterscheidet, was bereits vorhanden ist, muss man sich vergegenwärtigen, dass viele Fragen, die an persönliche Assistenten gestellt werden, durch einfache Datenbank- oder Websuche beantwortet werden können. Es gibt auch vereinzelte Beispiele für fortschrittlichere Funktionen, wie z. B. das Berechnen von Wegbeschreibungen. Fragen zur Navigation in zivilen Verkehrsnetzen werden in der Regelnichtdurch die Suche nach vordefinierten Routen in Datenbanken beantwortet, sondern durch die Formulierung einer Analyse zur Optimierung des kürzesten Weges im Netz, die dann (vielleicht unter Verwendung des Dijkstra-Algorithmus mit Heuristiken) innerhalb von Sekunden und für den Endbenutzer unsichtbar gelöst wird. Mit dieser Analogie lassen sich die oben genannten Faktoren zu zwei Herausforderungen zusammenfassen: (1) eine notwendige Verallgemeinerung und Erweiterung der Fähigkeiten von persönlichen Assistenten zur Formulierung und Lösung von Analysen und (2) Modellierung. Die Beantwortung von Fragen zur Wegbeschreibung ist möglich, da persönliche Assistenten bereits über detaillierte Kenntnisse des zivilen Verkehrsnetzes verfügen. Sie haben jedoch keine Kenntnisse über die firmeneigenen Produkte, Prozesse, Ressourcen und Einrichtungen eines beliebigen Unternehmens - und selbst wenn sie Zugang zu den Informationssystemen des Unternehmens hätten, sind diese weder vollständig noch können sie in der Regel in der erforderlichen Rolle einer experimentellen Entwurfsumgebung funktionieren.
Ende 2014 wurde eine Methodik entwickelt, um diese Herausforderungen und insbesondere die Herausforderung der Modellierung zu bewältigen. Das Pilotprojekt konzentrierte sich jedoch ausschließlich auf die Formulierung von ereignisdiskreten Simulationsmodellen, was der Beobachtung von Nelson entspricht, dass "Simulation zunehmend dieeinzigeMethode ist, die in der Lage ist, die großen, komplexen und unsicheren Systeme, an denen wir interessiert sind, zu analysieren, zu entwerfen, zu bewerten oder zu steuern" (Taylor et al. 2013). Eine vom Unternehmen auferlegte Anforderung ist die Verwendung von kommerziellen Standardwerkzeugen (COTS) für automatisch formulierte Simulationsmodelle, darunter Simio und Tecnomatix Plant Simulation.
Viele technische Analysten haben versucht, ihre Arbeitsabläufe zu automatisieren, indem sie das Paradigma der Trennung von Systembeschreibung und Systemanalyse verfolgten, indem sie Systembeschreibungen auf eine vermeintlich einfachere Art und Weise verfassten und diese dann bei Bedarf automatisch in die Semantik und Syntax einer bestimmten Analysesprache transformierten. Yuan et al. (1993) beschreibt einen Generator für Simulationsmodelle in der SIMAN-Sprache für "diskrete operative Systeme", die mit einem "Operationsnetz" und "Operationsgleichungen" modelliert werden. Son und Wysk (2001) beschreiben die automatische Erstellung von Simulationsmodellen in der Arena-Sprache zur Beantwortung von Fragen der Fertigungssteuerung, wobei eine Netzwerkabstraktion namens "message-based part state graph" verwendet wird, um potenzielle Routings durch die Ressourcen einer Werkstatt zu erfassen. Fournier (2011) beschreibt die automatische Erstellung von Simulationsmodellen in verschiedenen Sprachen (QUEST, Arena, ProModel, FlexSim) unter Verwendung des Standards Core Manufacturing Simulation Data (CMSD), und Bergmann et al. (2012) bildet CMSD auf die Simulationssprache SLX ab. Dong und Chen (2001) generieren objektorientierte Petri-Netze aus Verhaltensregeln der Computer Integrated Manufacturing Open System Architecture (CIMOSA), und Deavours et al. (2002) generieren stochastische Aktivitätsnetze (SAN) aus Modellierungsformalismen, die mit dem Mobius-Rahmen kompatibel sind. Generatoren für Simulationsanalysemodelle, die Systemmodelle in SysML-Sprache eingeben, sind Batarseh et al. (2015) und Kapos et al. (2014), wobei letztere ausführbare Modelle der Discrete Event System Specification (DEVS) erzeugen.
Beachten Sie die Vielfalt der Systembeschreibungssprachen in den obigen Zitaten. Neben "diskreten operativen Systemen", "nachrichtenbasierten Teilzustandsgraphen", CMSD und anderen gibt es viele weitere Sprachen, die von Forschungsideen bis zu angenommenen Standards reichen. Ein OASIS-Standard für den Austausch von Produktionsplanungs- und -terminierungsdaten ist (OASIS 2011). Zu den Ergebnissen des ISO TC 184/SC4 Komitees gehört der ISO 10303 Standard für die maschinenlesbare Erfassung und den Austausch von Produktdaten (Pratt 2001). AutomationML ist ein Standard der Standards für den Austausch von Daten zwischen Engineering-Tools in einer Produktionsanlage (Drath et al. 2008). Diese Bestrebungen standardisieren Datenschemata, und es gibt auch Bestrebungen, Semantik und Ontologien zu standardisieren. Ein OMG-Standard zur Formalisierung der Semantik von Geschäftsprozessen ist Business Process Model and Notation (BPMN) (OMG 2011). Ein Standard des Supply Chain Council zur Formalisierung der Semantik des Lieferkettenmanagements ist die Supply Chain Operations Reference (SCOR) (SCC 2012). Vorschläge zur Formalisierung der Fertigungssemantik umfassen die Manufacturing Semantics Ontology (MASON) (Lemaignan et al. 2006) und auch Molina und Bell (1999), Cutting-Decelle et al. (2007) und Guerra-Zubiaga und Young (2008).
Tanenbaum (1981) stellt fest: "Das Schöne an Standards ist, dass man so viele zur Auswahl hat."In den ersten Jahren des Forschungsprojekts suchten die Autoren nach einer einzigen und "perfekten" Systembeschreibungssprache für Produktionssysteme (Thiers und McGinnis 2013), indem sie verschiedene zitierte Beiträge zusammenfassten und Lücken füllten. Es wurde jedoch nie eine Sprache entwickelt, von der die Autoren plausibel behaupten konnten, dass sie von der ganzen Welt verwendet werden sollte. Dies liegt unter anderem an der grundsätzlichen Spannung zwischen Konkretheit und Abstraktheit (erstere wird für die Zugänglichkeit für den Benutzer benötigt, letztere für die Robustheit und Wiederverwendbarkeit) und auch daran, dass eine Sprache unweigerlich von den Anwendungsfällen der Autoren zu einem bestimmten Zeitpunkt geprägt ist.Unweigerlich ändern sich sowohl die Anwendungsfälle als auch die Zeit, die Sprache muss sich weiterentwickeln, Transformationsprogramme, die eng an die Sprache gekoppelt sind, gehen kaputt, und der Autor muss Code pflegen, den er längst vergessen hat, wenn der ursprüngliche Autor überhaupt noch auffindbar ist. Der Fortschritt kam erst wieder in Gang, als man schließlich akzeptierte, dass es eine einzige "perfekte" Systembeschreibungssprache für Produktionssysteme möglicherweise nie geben wird, und einen Weg fand, eine Vielzahl ähnlicher, aber unterschiedlicher Systembeschreibungssprachen unterzubringen.
Zusätzlich zu einer großen Anzahl von Sprachen für die Systembeschreibung gibt es auch eine große Anzahl von Sprachen für die Analyse der ereignisdiskreten Simulation - im Gegensatz zum Bereich der Optimierungsanalyse, der eine kanonische Sprache "A Mathematical Programming Language" (AMPL) (Fourer et al. 1993) hat, hat der Bereich der ereignisdiskreten Simulation nach bestem Wissen der Autoren keine solche kanonische Sprache, und jede Sprache unterscheidet sich von anderen Sprachen sowohl in der Semantik als auch der Syntax. Wenn es m Möglichkeiten der Systembeschreibungssprache undn Möglichkeiten der Simulationsanalysesprache gibt, dann ergeben sichm n Permutationen von Transformationen von der Systembeschreibung zur Simulationsanalyse, was die Rentabilität der Erstellung und Pflege jeder einzelnen stark einschränkt. Die in dieser Arbeit beschriebene Methode reduziertm auf1, lässt aber immer nochm Systembeschreibungssprachenzu, indem sie einen Zwischenschritt der Transformation hinzufügt, der jede Sprache lose mit einer Back-End-Brückenabstraktionssprache koppelt.
Unter den in Abschnitt 1.1 zitierten Bemühungen zur automatischen Generierung von Simulationsmodellen gibt es eine beträchtliche Vielfalt in Bezug auf den Ort, an dem die "Intelligenz" der Transformation angesiedelt ist - sie kann stromaufwärts in der Systembeschreibungssprache (und damit in der nachgelagerten Analysesprache), in der Transformation selbst (wie bei allgemeinen Modell-zu-Modell-Transformationssprachen und -werkzeugen wie QVT (OMG 2016) und ATL (EMF 2016)) oder stromabwärts in der Systemanalysesprache (und damit in der nachgelagerten Beschreibungssprache, dem de-facto-Ansatz vieler COTS-Simulationswerkzeuganbieter) liegen. In einigen Fällen versuchen Forscher, die Transformationen zu vereinfachen, indem sie ihre eigene ereignisdiskrete Simulationssprache und ihren eigenen Solver schreiben, wie in Biswas und Narahari (2004), Chatfield et al. (2006) und Schonherr und Rose (2009), die eine Transformation der Systembeschreibung in die Simulationsanalyse durch einfache Eins-zu-Eins-Mappings ermöglichen. Nach Einschätzung der Autoren ist die Entwicklung von Ad-hoc-Analysewerkzeugen kein nachhaltiger Weg, wenn geeignete COTS-Werkzeuge zur Verfügung stehen - selbst wenn deren Sprache unbequem ist. Die in diesem Papier beschriebene Methodik legt den größten Teil der Transformations-"Intelligenz" in die Modell-zu-Modell-Transformationen selbst, schlägt aber einen kleinen Schritt nach vorne vor, indem Simulationsmodelle so weit wie möglich unter Verwendung von Modellbibliotheksblöcken aufgebaut werden, die ausführbare Versionen von überbrückenden Abstraktionsmodellelementen sind.
Eine Methodik ist eine Sammlung von zusammenhängenden Prozessen, Methoden und Werkzeugen (Estefan 2008), und der Prozess in der Methodik dieses Papiers ist in Abbildung 1 dargestellt. Sowohl das Systemmodell oben links als auch das überbrückende Abstraktionsmodell oben in der Mitte sind reine Beschreibungsmodelle und bestehen aus zwei verschiedenen Modellierungsabstraktionsebenen, die man als Schema und Daten oder Metamodell und Instanzmodell oder Klassendefinitionen und Objektinstanziierungen in der objektorientierten Softwareterminologie bezeichnen könnte. Die in Abschnitt 1.1 ausführlich behandelte Systembeschreibungssprache ist die obere Schema- oder Metamodellschicht, und die Unterscheidung ist wichtig, weil Modell-zu-Modell-Transformationen nur von dieser Schicht abhängen und mit jedem konformen Daten- oder Instanzmodell funktionieren sollten. Das Bridging Abstraction Metamodel ist eine abstrakte Schöpfung, die die zugrundeliegenden Gemeinsamkeiten aller ereignisdiskreten Logistiksysteme erfasst - Fertigungssysteme, Lieferketten, Lager- und Distributionssysteme, Transport- und Logistiksysteme, Systeme für die Gesundheitsversorgung und andere. Eine wichtige Beobachtung ist, dass die meisten Systeme, die im Wirtschaftsingenieurwesen untersucht werden, eine Netzwerkstruktur haben, und die meisten Betriebsforschungsanalysen dieser Systeme sind netzwerkbasierte Analysen. Das Bridging Abstraction Metamodel hat sich seit seinen Anfängen zu einer Sammlung von Schichtenmodellen entwickelt, aber die ursprüngliche und grundlegende Schicht bezeichnen die Autoren als Token-Flow-Netzwerk, ein Auszug ist in Abbildung 2 dargestellt.
Das Bridging Abstraction Model wird eingeführt, um ein grundlegendes Spannungsverhältnis zwischen konkret und abstrakt zu vermitteln - ein Systemmodell sollte so konkret sein, wie es für die Zugänglichkeit erforderlich ist, das Bridging Abstraction Model sollte so abstrakt wie möglich sein, um Robustheit und Wiederverwendbarkeit zu gewährleisten, und die Wirksamkeit hängt von einfach zu erstellenden und zu pflegenden Mappings zwischen den beiden ab. Die Mappings werden als deklarative Spezifikationen von Modell-zu-Modell-Transformationen realisiert, und ihre Aktualisierung als Reaktion auf neue oder sich entwickelnde Systemmodelle muss so einfach und schnell wie möglich sein. In der Software-Terminologie hat der hinzugefügte Zwischenschritt den Effekt, die enge Kopplung zwischen Systembeschreibungssprachen und Systemanalysesprachen abzumildern, um die Kosten zu verringern, wenn sich eine Systembeschreibungssprache zwangsläufig mit den Anwendungsfällen und der Zeit ändern muss. In Abbildung 1 bleibt die Kopplung der zweiten Stufe zwischen dem Bridging Abstraction Model und dem Analysemodell eng, aber die Kopplung der ersten Stufe zwischen dem Systemmodell und dem Bridging Abstraction Model sollte so locker wie möglich sein, um neue oder sich entwickelnde Systemmodelle aufzunehmen. Wichtig ist, dass aufgrund der Stabilität des überbrückenden Abstraktionsmodells die Aufgabe, die Transformationen der zweiten Stufe zu schreiben und zu pflegen, einen ausreichenden Return-on-Investment hat, der von einem speziellen Team übernommen werden kann, im Gegensatz zu verschiedenen Analysten.
Viele neue Ideen sind Variationen alter Ideen, und der Prozess in Abbildung 1 kann als solcher klassifiziert werden, als eine Verpflanzung von Best Practices aus der Software- in die Systemtechnik. Das Neue an der Methodik liegt in den Methoden und Werkzeugen, die sich mit den großen Forschungsherausforderungen befassen, die bestehen, um sie für die Systemtechnik nutzbar zu machen:
Eine ausführliche Erörterung der Prozesse, Methoden und Werkzeuge der Methodik findet sich in Thiers (2014), Sprock und McGinnis (2014) und Sprock (2016). Die Suche nach und das Experimentieren mit neuen Methoden und Werkzeugen wird fortgesetzt, z. B. eine Methode zur Verwendung von Modellbibliotheksblöcken, bei denen es sich um ausführbare Versionen von überbrückenden Abstraktionsmodellelementen handelt, soweit dies möglich ist, wenn Analysemodelle in einem Bereich ohne kanonische Sprache erstellt werden.
PILOTPROJEKT
Ende 2014 war die Methodik auf dem Papier ausgereift, und 2015 wurde ein Pilotprojekt durchgeführt, um die Wirksamkeit zu demonstrieren, d. h. dass eine Implementierung der Methodik die Zeit, die für die Beantwortung einer häufig gestellten Frage benötigt wird, tatsächlich um mindestens eine Größenordnung reduzieren kann, und zwar auf wiederholbare Weise, während sich die Spezifikationen der Produkte, ihre Prozesspläne, die geplanten Anlagen und die verfügbaren Ressourcen ständig ändern. Die beteiligten Schritte waren:
Schritt 1: Der Benutzer sollte ein häufig auftretendes Szenario auswählen, für das die Formulierung von ereignisdiskreten Simulationsmodellen auf Knopfdruck zur Beantwortung einer Vielzahl von Fragen sehr wertvoll sein könnte.Das Szenario für dieses Projekt betraf die Bewertung der Fertigungskapazität für die Herstellung von Verbundwerkstoffteilen mit der häufig gestellten Frage "Welche Mindestanzahl von Ressourcen ist erforderlich, um eine bestimmte Produktionsrate zu unterstützen?" Von Interesse sind Ressourcen für die Herstellung von Verbundwerkstoffformen und Autoklaven, die für große Luft- und Raumfahrtteile sehr teuer sein können und lange Beschaffungszeiten erfordern.
Schritt 2: Erstellen einer Systembeschreibungssprache für das gewählte Szenario.Dieser Schritt erfordert die Erfassung einer analyse-neutralen Semantik, die Benutzer verwenden, um über ihr Geschäft zu sprechen und es in Informationssystemen darzustellen. Diese Sprache wurde während des Pilotprojekts iterativ weiterentwickelt, und ihr Zustand bei der letzten Iteration ist in Abbildung 3 dargestellt. Beachten Sie, dass es sich hierbei um ein Modell auf Schema-Ebene handelt und nicht um eine Instanz eines Produktionssystems - es dient als gemeinsame Definition für Anlagen, Fertigungsprozesse, Alternativen dazu, gewünschte künftige Zustände für sie und mehr.
Eignet sich die Sprache in Abbildung 3 als abstraktes Metamodell zur Beschreibung beliebiger Produktionssysteme? Sicherlich nicht - es handelt sich um das Schema eines bestimmten Benutzers, und zwar um ein minimales Schema für einen bestimmten Anwendungsfall, das sich syntaktisch und sogar semantisch von den Schemata anderer Benutzer unterscheiden kann. Zu den wichtigen Merkmalen gehören die Chargierung am Autoklaven (nach Teilevolumen oder nach einer bestimmten Liste von Teiletypen und -mengen) sowie die Verknüpfung von Ressourcen mit Teilen über mehrere Prozessschritte hinweg (Komposit-Layup-Formen vom Pre-Layup bis zum Post-Curing). Diese Semantik ermöglicht es auch, physische Anlagen von funktionalen Prozessdefinitionen zu trennen, da eine Schlüsselkomponente der Kapazitätsfrage darin besteht, dass Prozesspläne nicht in einem Vakuum ausgeführt werden, sondern in bestimmten Anlagen, die mehrere Prozesspläne gleichzeitig ausführen und dabei gemeinsame Ressourcen nutzen. Zu den Semantiken, die nicht berücksichtigt werden, aber in anderen Szenarien wichtig sein können, gehören Aufträge mit Terminen, Reisenetzwerke innerhalb und zwischen Einrichtungen, Routing-Kontrolle von Aufträgen und Ressourcen und mehr. Die Innovation der Methodik besteht darin, dass die Analysegeneratorprogramme nur lose an die Systembeschreibungssprache in Abbildung 3 gekoppelt sind, so dass diese Programme weiterarbeiten können, während sich die Sprache weiterentwickelt (während des Pilotprojekts wurde die Sprache in etwa acht Iterationen im Abstand von einem Monat weiterentwickelt). Mit anderen Worten: Die Methodik entlastet von dem Zwang, eine Systembeschreibungssprache "perfekt" zu machen, bevor man in Analysegeneratorprogramme investiert, die von ihr abhängen.
Schritt 3: Präzisierung der Fragestellung:Dieser Schritt sollte überflüssig werden, sobald ein gewisser Reifegrad der Werkzeugunterstützung erreicht ist, ist aber in frühen Pilotprojekten unerlässlich. Es geht darum, zu bestimmen, welche Informationen der Fragesteller in einer Antwort erwartet und wie diese Informationen aus der Simulationsausgabe extrahiert oder abgeleitet werden können. Nehmen wir an, die Antwort auf die Frage"Wie viele Ressourcen sind mindestens erforderlich, um eine bestimmte Produktionsrate zu erreichen?" lautet: "x undy Einheiten der Ressourcentypen A und B sind die Mindestmengen, die erforderlich sind, um durchschnittlich 20 Flugzeuge pro Monat zu produzieren." Reicht das aus, oder werden auch Risikobeschränkungen erwartet, wie z. B."x und y Einheiten der Ressourcentypen A und B ergeben in α% der Monate nur 19 Flugzeuge und in β% der Monate nur 18 Flugzeuge"? Ein wichtiger Punkt für die zukünftige Entwicklung ist die Rückgabe von Antworten mit Interpretationen, Risikoqualifikatoren und mehr. Die Methodik ermöglicht ein Werkzeug zur Entscheidungsunterstützung, nicht zur Entscheidungsfindung, denn die Entscheidungsfindung sollte eine menschliche Risikobewertung widerspiegeln, die die x-Achse auf einer Art Pareto-Frontier-Diagramm sein könnte, das als Antwort auf eine Frage zurückgegeben wird.
Auch die Präzisierung der Frage war mit einem Aufwand verbunden, der für das erste Projekt einzigartig war. Da der größte Teil der Arbeit in der Softwareentwicklung bestand, wurde ein spiralförmiges Entwicklungsparadigma mit einer Iterationszeit von etwa einem Monat verfolgt. Die Frage "Wie viele Ressourcen sind mindestens erforderlich, um eine bestimmte Produktionsrate zu erreichen?" wurde zum Schlusspunkt einer Reihe von Meilensteinfragen:
Schritt 4: Abbildung des Front-End-Systemmodells auf das Back-End-Bridging-Abstraktionsmodell, soweit dies für die Beantwortung der Frage erforderlich ist. Die Wirksamkeit der Methodik hängt von einer möglichst lockeren Kopplung zwischen diesen beiden Modellen ab, und die lockerste Form, die wir uns vorstellen können, ist eine deklarative Spezifikation einer Modell-zu-Modell-Transformation, wie sie in Abbildung 4 dargestellt ist.
Bei der XML-Datei in Abbildung 4 handelt es sich um eine Low-Level-Darstellung, mit der die Benutzer nicht direkt interagieren sollten - durch Verbesserungen der Benutzerfreundlichkeit sollte das Verfassen und Aktualisieren deklarativer Spezifikationen von Modell-zu-Modell-Transformationen wesentlich benutzerfreundlicher werden. Zu Beginn des Projekts hatten sich die Autoren vorgestellt, diese Mappings über den Mechanismus der UML-Stereotyp-Anwendung (Batarseh et al. 2012) durchzuführen. Die Anwendung eines UML-Stereotyps definiert effektiv eine Eins-zu-Eins-Transformationsregel, die das Systemmodell und das überbrückende Abstraktionsmodell dazu zwingt, sehr ähnlich auszusehen und sich effektiv nur in der Syntax zu unterscheiden. Als nächstes zogen die Autoren allgemeine und standardisierte Modell-zu-Modell-Transformationssprachen wie QVT oder ATL in Betracht, aber die Transformationsspezifikationen waren recht ausführlich, und es wurde schnell klar, dass die Einbeziehung des Wissens über das Ziel der Transformation eine drastische Vereinfachung ermöglicht. Diese Vereinfachung bringt einen Verlust an Flexibilität mit sich, der aber nicht notwendig war, was mit der Schlussfolgerung von Cleenewerck und Kurtev (2007) übereinstimmt, dass "das Problem der Übersetzungssemantik im Model-Driven Engineering besser mit einer domänenspezifischen Transformationssprache angegangen werden sollte als mit einer Allzwecksprache." Zukünftige Arbeiten beinhalten die Abstimmung der benutzerdefinierten und domänenspezifischen Transformationssprache mit einem Standard wie QVT.
Schritt 5: Instanzmodelle erstellen und loslegen: Um eine Frage zur Produzierbarkeit auf Knopfdruck zu beantworten, muss im letzten Schritt der Gegenstand der Frage schnell beschrieben werden - Instanzen von Produkten, Prozessen, Ressourcen und Anlagen. Das Metamodell in Abbildung 3 entspricht den Klassendefinitionen von Software, die eine große Anzahl von Objektinstanziierungen hervorbringen können, und dieser Schritt erfordert die Erstellung dieser Objektinstanziierungen. Im Pilotprojekt wurde dies in einer tabellarischen und Excel-ähnlichen Umgebung durchgeführt, und ein Auszug ist in Abbildung 5 dargestellt.
Die Tabellen und ihr Schema in Abbildung 5 entsprechen dem Metamodell in Abbildung 3 - eine Operation entspricht einer Tabelle, und jedes Attribut entspricht einer Spalte. Die Tabellen und das Schema eines Instanzmodells werden über ein objektrelationales Mapping erzeugt, und ein Benutzer beschreibt den Gegenstand der Frage, indem er die Tabellen ausfüllt. Dies ist eine Modellierungsumgebung, die von vielen Verbesserungen der Benutzerfreundlichkeit profitieren könnte; eine davon ist, dass die Tabellen, die den Benutzern angezeigt werden, effektiv rohe relationale Datenbanktabellen sind, und das Hinzufügen einer Ansichtsschicht wird eine Vereinfachung, Organisation und das Ausblenden redundanter Daten ermöglichen (z. B. Kreuzungstabellen, die aus jedem Attribut folgen, dessen Multiplizitätsobergrenze > 1 ist). Eine weitere Verbesserung besteht darin, dass in Abbildung 5 für jedes Metamodellelement in Abbildung 3 zwar Tabellen und Spalten angezeigt werden, die Kenntnis der Frage eines Benutzers jedoch eine visuelle Filterung auf die für die Beantwortung dieser Frage relevanten Tabellen und Spalten ermöglicht. Eine weitere Verbesserung ist das Hinzufügen der Visualisierung unabhängig vom Systemmodell des Benutzers. Während Tabellenzeilen gefüllt werden, wird im Hintergrund ein überbrückendes Abstraktionsmodell erstellt, und die Visualisierung sollte zumindest für Prozess- und Anlagenansichten möglich sein. Die Verbesserung der Benutzerfreundlichkeit dieser Umgebung ist entscheidend für die größtmögliche Reduzierung des Zeitaufwands und der Fachkenntnisse, die für die Beantwortung von Routinefragen zur Produzierbarkeit erforderlich sind.
Ein Beispiel für ein ereignisdiskretes Simulationsmodell und ein Experiment, die auf Knopfdruck automatisch generiert werden, ist in Abbildung 6 dargestellt.
Der Übergang vom Entwurf zur Produktion ist ein komplexer Geschäftsprozess, und die in diesem Papier beschriebene Forschung unterstützt diesen Prozess, indem sie es den Designern ermöglicht, die Auswirkungen von Designentscheidungen auf die Produktion viel früher im Designzyklus eines Programms zu erkennen, als dies heute möglich ist. Es wurde eine Methodik entwickelt, die es ermöglicht, Fragen zur Produzierbarkeit auf Knopfdruck zu beantworten, und deren Neuheit im Grad der Trennung der Belange liegt - sie trennt die Systembeschreibung von der Systemanalyse und trennt zusätzlich die konkrete Front-End-Systembeschreibung von der abstrakten Back-End-Beschreibung. Eine Pilotprojekt-Implementierung unterstützt die Erstellung von Systemmodellen in der Sprache Ecore, die in Abschnitt 3 aufgezählten Fragen und die Generierung von Simulationsmodellen und Experimenten in den Sprachen Simio, SimEvents und Tecnomatix Plant Simulation per Knopfdruck, um diese Fragen zu beantworten. Die Frage des Pilotprojekts bezog sich auf die Anzahl der Ressourcen - eine parametrische Änderung - und die Implementierung wurde auch demonstriert, um strukturelle Änderungen zu berücksichtigen, einschließlich Änderungen der Prozesspläne, Änderungen der Job-Arbeitsplatz-Zuweisungen, Verfeinerung der Ressourcentypen, Beschreibung auf Abstraktionsebenen und mehr. Zum Zeitpunkt der Erstellung dieses Berichts gibt es keinen funktionalen Unterschied zwischen parametrischen und strukturellen Änderungen, da die Implementierung ein Simulationsmodell bei jeder Änderung des Instanzmodells vollständig neu generiert, obwohl dies in Zukunft aus Effizienzgründen noch ausgefeilter werden könnte.
Am Ende des Pilotprojekts wurde die Proof-of-Concept-Softwareimplementierung dem Pilotkunden zur Verfügung gestellt. Der Kunde schätzt, dass bei Routinefragen zu Produktionssystemen eine Tool-Implementierung der Methodik zu einer drastischen Verringerung des Zeit-, Kosten- und Know-how-Aufwands für die Verwendung von Simulationen und anderen Analysemethoden zur Beantwortung dieser Fragen führen kann, zumindest zu einer Verringerung in der Größenordnung. Diese Zeitersparnis kann entweder eingespart oder dafür verwendet werden, mehr Produktionsszenarien und deren Auswirkungen zu bewerten, mehr Verbesserungsideen und -alternativen in Betracht zu ziehen und einen größeren Teil des Designraums eines Produktionssystems zu untersuchen. Der Kunde stellt jedoch auch fest, dass mehrere Verbesserungen erforderlich sind, um eine fortgeschrittene technische Bereitschaftsstufe (TRL) zu erreichen und ein Werkzeug zu entwickeln, das Analysten bei ihrer täglichen Arbeit begrüßen würden. Das Tool ist eine Modellierungs- und Modelltransformationsumgebung, und es sind Verbesserungen der Sprache und der Benutzerschnittstelle erforderlich, um Systembeschreibungsschemata, konforme Systeminstanzmodelle, Transformationen zu überbrückenden Abstraktionsmodellen und automatisierte Analyseformulierungsprozesse zu erstellen. Diese Verbesserungen werden dazu beitragen, die Arten von Fragen zu Produktionssystemen abzugrenzen, die tatsächlich "Routine" sind, und das könnte eine überraschend großzügige Menge sein.
Es ist zu hoffen, dass diese Forschung den Markt für Operations Research-Analysen vergrößern kann. Statistische, ereignisdiskrete Simulations- und Optimierungsanalysen können wichtige Fragen beantworten, aber die Zeit, die Kosten und die Anforderungen an das Fachwissen, die für ihren Einsatz erforderlich sind, können für alle außer den größten Unternehmen unerschwinglich sein. Es gibt viele Möglichkeiten für künftige Arbeiten, wobei nach Ansicht der Autoren die Entwicklung von Systembeschreibungen von der Struktur zu ausgereifteren Modellen, einschließlich Verhalten und Steuerung, und das Verständnis von Prozessen auf höherer Ebene, einschließlich Konstruktion, Diagnose und kontinuierlicher Verbesserung, am dringlichsten sind. Ein tiefes Verständnis von Systemen der Industrietechnik und die Fähigkeit, Operations Research-Analysen bei Bedarf kosteneffizient einzusetzen, sind Voraussetzungen dafür, dass die Gestaltung von Produktionssystemen ebenso anspruchsvoll wird wie die Gestaltung von Produkten selbst.
Die hier vorgestellten Forschungsarbeiten wurden von der Georgia Tech durch den Gwaltney-Lehrstuhl für Fertigungssysteme, durch einen Zuschuss von Rockwell-Collins und durch Forschungsprojekte unterstützt, die vom United Technologies Research Center und der Boeing-Georgia Tech Strategic University Partnership finanziert wurden.