-
QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
-
Diese Offenbarung beansprucht die Vorteile der vorläufigen
US-Anmeldung Nr. 63/429,538 mit dem Titel „MACHINE LEARNING MODEL DISTRIBUTION ARCHITECTURE“, die am 1. Dezember 2022 eingereicht wurde und deren Offenbarung hier durch Bezugnahme in vollem Umfang enthalten ist.
-
GEBIET DER TECHNIK
-
Diese Offenbarung bezieht sich auf Test- und Messsysteme und insbesondere auf Test- und Messsysteme, die eine trainierbare maschinelle Lernmodellkomponente verwenden.
-
HINTERGRUND
-
U.S.-Patentanmeldung Nr.
18/482,765 , eingereicht am 6. Oktober 2023, die die Priorität von U. S. Prov. Pat. App. Nr.
63/415,588 , eingereicht am 12. Oktober 2022, mit dem Titel „COMPREHENSIVE MACHINE LEARNING MODEL DEFINITION“, im Folgenden „die '765-Anmeldung“ genannt, deren Inhalt hiermit durch Bezugnahme in die vorliegende Offenbarung aufgenommen wird, beschreibt eine Modelldefinition für maschinelles Lernen, die eine effiziente und bequeme Verteilung der maschinellen Lernmodelle ermöglicht.
-
Die Steuerung, Verteilung und andere damit zusammenhängende Aspekte der maschinellen Lernmodelle können die Komplexität des Systems erhöhen. Dies kann dazu führen, dass das System für die Kunden weniger nützlich ist als gewünscht.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
- 1 a zeigt ein Blockdiagramm einer Ausführungsform eines Fertigungssystems.
- 2 zeigt ein Blockdiagramm einer Ausführungsform eines Systems zur Verteilung und Pflege trainierter und untrainierter Modelle von neuronalen Netzen mit tiefem Lernen und zugeordneten Informationen.
- 3 zeigt eine detaillierte Ansicht eines Kundenrepositorys und eines Fertigungssubsystems, das im System von 2 verwendet werden kann.
- 4 zeigt eine detaillierte Ansicht einer Ausführungsform eines Repositorys, das in dem System von 2 verwendet werden kann.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Die Ausführungsformen bieten eine Systemarchitektur und ein Verfahren für das Trainieren und die Verteilung von trainierten und untrainierten maschinellen Lernmodellen. Die Ausführungsformen umfassen lokale Kundenrepository an jedem Kundenstandort, ein zentrales Repository mit Partitionen für jeden Kunden und bietet eine Möglichkeit für die Verteilung von lokalen trainierten Kundenmodellen an Fertigungsstationen und das Kopieren und Speichern im zentralen Repository. All dies geschieht unter der Kontrolle eines Systems, das den Zugang zu den Daten und Modellen jedes Kunden, ob geschult oder nicht, verwaltet und kontrolliert, damit alles gesichert ist und nur denjenigen zur Verfügung steht, die Zugang haben.
-
1 zeigt eine Ausführungsform eines Fertigungssystems 10, in dem OptaMI, eingesetzt wurde. In 1 wird die kundenseitige Automatisierungssoftware oder das System 20 vom Kunden geschrieben und gewartet. Sie fungiert als übergeordnete Fertigungssteuerungssoftware. Sie steuert Öfen, optische Schalter, Oszilloskope, die ML Tools SW-Anwendung und möglicherweise weitere Komponenten. Zu ihren Aufgaben gehört die Steuerung des DUTs und der Messinstrumente, um Wellenformen, S-Parameter oder andere Daten von den DUTs zu sammeln, die für das Trainieren der neuronalen Netze der ML Tools-Anwendung verwendet werden. Dazu gehören auch die Aufgaben, die Metadaten zu definieren, die die neuronalen Netze vorhersagen und/oder mit den gesammelten DUT-Daten verknüpfen sollen. Eine weitere Aufgabe besteht darin, alle Trainingsdaten zu sammeln, sie mit vordefinierten Namenskonventionen zu formatieren und sie an vordefinierten Datenspeicherorten abzulegen. In einer Ausführungsform legt das Kundenautomatisierungssystem die Trainingsmetadaten auch in Datendateien eines universelleren Formats ab, z. B. in *.csv-Dateien. Während der Laufzeit sammelt es Daten vom DUT und steuert den Prozess der Bereitstellung dieser Daten an die ML Tools-Anwendung, um eine Abstimmungs- oder Messvorhersage zu erhalten.
-
Die Anwendung 20 des Kundenautomatisierungssystems kann viele andere als die in 1 dargestellten Komponenten enthalten. Der Datenerfassungsblock 22 sammelt die erforderlichen Daten von DUTs für das Trainieren der Deep-Learning-Netze in der ML-Tools-Anwendung SW. Anschließend speichert er die Daten und Metadaten im Datenspeicher. In einer Ausführungsform kann der Trainingsdatenteil 32 des Speichers 30 die Daten in einer Struktur mit einem Ordner oder einem anderen bezeichneten Bereich wie 34 für jede Temperatur, bei der die DUTs getestet werden, speichern.
-
Das Kundensystem wird so ausgebildet, dass es viele DUTs abtastet und deren optimale Abstimmung mit dem Standardabstimmungsprozess des Kunden für die DUTs bei 24 ermittelt. Sobald dies geschehen ist, erstellt es die Referenzabstimmungsparametersätze, die für das Trainieren und die Laufzeitvorhersagen benötigt werden. Dieser Block speichert dann die Referenzparametersätze im Datenspeicher bei 36.
-
Während der Laufzeit lädt das System des Kunden Referenzparameter in sein DUT und sammelt Wellenformen oder S-Parameter bei 26. Diese werden dann über den Kommunikationsteil des Datenspeichers 40 als Eingabe an die ML Tools-Anwendung übermittelt, die dann ebenfalls über den Kommunikationsteil des Datenspeichers vorhergesagte Metadaten zurückerhält. Dabei kann es sich um einen Satz optimaler Abstimmungsparameter handeln, die in 42 gespeichert sind, oder um eine Messung wie TDECQ oder andere in 44.
-
Wie bereits erwähnt, dient der Datenspeicher 30 als Kommunikationsschnittstelle zwischen dem Kundenautomatisierungssystem 20 und der Anwendung ML Tools 50. Er enthält alle Daten 32 und 36, die zum Trainieren des Modells verwendet werden, die trainierten neuronalen Netze 38, alle ML-Tools-System-Klassenvariablen, die sowohl für das Trainieren als auch für die Vorhersagen eingerichtet wurden, sowie die Kommunikationsordner 40, 42 und 44 für die Erstellung von Laufzeitvorhersagen.
-
Der Trainingsdatenordner 32 kann Eingabedaten in Form von Wellenformdaten, S-Parameterdaten oder anderen Daten empfangen und enthalten, die für das Trainieren und die Vorhersage verwendet werden. Er enthält Eingabemetadaten, die mit den eingegebenen Wellenform- oder S-Parameterdaten verknüpft sind, möglicherweise in Form von Eingabedateien wie den oben erwähnten *.csv-Dateien. Die ML Tools-Anwendung kann während des Trainingsverfahrens Animationsdateien erstellen. Sie enthalten ein Frame des Bildtensors und die Metadaten für jede der Tausenden von Eingangswellenformen. Die ML-Tool-Anwendung speichert diese im Datenspeicher.
-
Der Ordner 36 mit den Referenzabstimmparametern enthält drei oder mehr Sätze von Referenzabstimmparametern, die für die Erfassung von Trainingsdaten oder für die Erfassung von Daten in Laufzeitvorhersageprozessen für Abstimmprozesse benötigt werden. Das Kundenautomatisierungssystem 20 lädt die Referenzparametersätze in die DUTs und sammelt drei Wellenformen oder drei Sätze von S-Parametern. Das System verwendet diese als Eingabe für die Deep-Learning-Netze 54 zum Trainieren oder zur Laufzeitvorhersage.
-
Sobald ein Modell trainiert wurde, erstellt die ML Tools-Anwendung eine Einrichtungsdatei und speichert sie im Speicher oder Unterspeicher 38 des Datenspeichers 30. Diese Datei enthält die trainierten neuronalen Netze. Sie enthält auch die Werte der Setup-Klassenvariablen für die gesamte ML Tools-Anwendung sowohl für das Trainieren als auch für die Laufzeitvorhersage. Der Benutzer kann mehr als ein trainiertes Setup-Dateimodell für sein bestimmtes DUT-Modell erstellt haben. Normalerweise trainiert die ML Tools-Anwendung nur ein Modell und speichert es in diesem Teil. Vielleicht wurde beispielsweise ein neues Modell trainiert, weil sich die Eigenschaften des DUTs zu einem bestimmten Zeitpunkt geändert haben. Die ML Tools-Anwendung speichert dann möglicherweise das alte und das neue Modell. Es kann auch andere Gründe geben, warum mehrere trainierte Setups gespeichert werden können.
-
Während der Laufzeit der Vorhersagen unter Verwendung der trainierten Netze speichert das Kundenautomatisierungssystem 20 Daten aus dem DUT in einem der Kommunikationsspeicher 40. Die Daten stammen aus der Eingabe der Referenzabstimmungsparameter in ein DUT, und ein PI-Befehl (programmatische Schnittstelle) oder ein Tastendruck an der Frontplatte veranlasst die ML Tools-Anwendung, eine Vorhersage unter Verwendung der Daten als Eingabe zu treffen. Die MI,-Tools-Anwendung speichert die Vorhersage dann wieder im Kommunikationsspeicher 40. Ein PI OK Handshake kann an das Kundenautomatisierungssystem zurückgehen, das dann die vorhergesagten Ergebnisse liest. Der Kommunikationsspeicher 40 kann einen Kommunikationsordner für die Erstellung von DUT-Abstimmungsvorhersagen (z. B. 42) und einen Kommunikationsordner für die Durchführung von Messungen (z. B. 44) enthalten. Der Kommunikationsspeicher 40 kann auch andere Kommunikationsordner enthalten, je nach dem in der ML Tools-Anwendung ausgewählten System. Ebenso kann es innerhalb des Datenspeichers weitere Speicher geben. Verschiedene Systemanwendungen, die zur Auswahl durch den Benutzer aus dem Menü ML Tools System implementiert werden können, erfordern möglicherweise Änderungen an dieser Modellfilterstruktur.
-
Das Modell ist so strukturiert, dass die Systemarchitektur es schrittweise verarbeiten kann, um die Trainingsdaten-Arrays zu erstellen. Dadurch bleiben alle Eingabedaten und alle Metadaten konsistent. Wie bereits erwähnt, unterstützt der Datenspeicher auch das Trainieren bei verschiedenen Werten von Betriebsparametern, wie z. B. der Temperatur. Auch dies vereinfacht die interne Datenverarbeitung und -zuordnung. Dies erleichtert dem Kunden die Steuerung und Visualisierung der Daten und gibt ihm einen besseren Einblick in die Beschaffenheit seines DUTs. Eine solche Visualisierung kann die Temperatur als Balkendiagramm in den für die Vorhersage und das Trainieren erstellten Tensorbildern darstellen.
-
Ein wichtiges Element des Speichers ist das trainierte Modell, das entweder gespeichert oder mit Hilfe des Pulldown-Menüs Datei > Trainiertes Setup abrufen oder des PI-Befehls Datei Trainiertes Setup speichern abgerufen wird. Diese Datei enthält alle Systemklassenvariablen, die für die Einrichtung der gesamten Systemanwendung sowohl für Trainings- als auch für Laufzeitprognosen benötigt werden. Sie enthält auch die trainierten neuronalen Netze im System.
-
Die verschiedenen Elemente des Datenspeichers werden durch eine Struktur von Speichern oder Unterspeichern, wie Ordnern und Dateien, dargestellt. Die Organisation der Daten kann aus einzelnen Dateien bestehen, wie in der Abbildung gezeigt, oder aus Kombinationen von Dateien, die die Daten in andere Strukturen als das gezeigte Beispiel bringen. Der Datenspeicher hat mehrere Aspekte, einschließlich eines einzigen strukturierten Speichers, der Daten enthält, die auf mehrere Computer übertragen werden können, auf denen die Software OptaML™ ML Tools zur Erstellung von Abstimmungsvorhersagen läuft, einer Reihe von Ordnern zur Unterstützung von Wellenformdaten und Metadaten für das Trainieren der Deep-Learning-Netzwerke sowie Unterspeicher und Dateien zur Unterstützung des spezifischen Systemtrainings und der Laufzeitvorhersage. Diese können Referenzabstimmparameter und ein Array von OptaML™ Abstimmparametern enthalten, die zur Bestimmung der Referenzabstimmparameter verwendet werden. Der Speicher umfasst auch einen Speicher, der die Datei des trainierten Modells mit den trainierten neuronalen Netzen für tiefes Lernen sowie alle Zustände der Systemklassenvariablen enthält, die für ein Trainieren und eineVorhersage benötigt werden. Der Datenspeicher umfasst auch einen oder mehrere Kommunikationsspeicher für die Eingabe von Wellenformdaten zur Erstellung von Vorhersagen aus den trainierten Netzwerken und zur Aufnahme der vorhergesagten Ergebnisse. In verschiedenen Ausführungsformen können der Datenspeicher und die Unterspeicher in verschiedenen Hierarchien organisiert sein.
-
Die ML-Tools-Anwendung 50 führt die erforderliche digitale Signalverarbeitung (DSP) 52 durch, um die Eingabedaten in Tensorstrukturen umzuwandeln, die als Eingabe zum Trainieren der Deep-Learning-Netze oder zum Erhalten von Vorhersagen von ihnen verwendet werden können. Die ML-Tools-Anwendung verfügt über einen Block 56 zum Speichern/Abrufen trainierter Modelle, der die gesamte Systemkonfiguration einschließlich der trainierten neuronalen Netze in einem oder mehreren Datenspeichern speichert. Die Systemkonfiguration 58 stellt alle Anwendungsklassenvariablen und Zustände des neuronalen Netzes dar, die für die Durchführung von Trainings- und Laufzeitprognosen erforderlich sind. In einer Ausführungsform kann der Datenspeicher 38 aus einer einzigen Datei bestehen. Alternativ kann es sich auch um mehr als eine Datei handeln. Dieser Block ermöglicht auch das Abrufen und Laden einer gespeicherten Modell-Setup-Datei in das System.
-
Der oben erwähnte DSP-Block 52 enthält alle DSP-Transformationen des Systems, die für die Anwendung auf die Wellenformen oder S-Parameter der Eingangsdaten erforderlich sind, um sie dann in ein Tensorformat zu überführen, das für die Eingabe in das verwendete Deep-Learning-Netzdesign geeignet ist. Zwei davon sind in den Blockdiagrammen dargestellt, aber es handelt sich nur um einen DSP-Block 52, der in der Anwendung in zwei verschiedenen Bereichen verwendet wird, sowohl bei der Vorhersage als auch beim Trainieren. Dadurch wird sichergestellt, dass das gesamte System sowohl für das Trainieren als auch für die Vorhersage einheitlich aufgebaut ist. Die Daten müssen für ein Trainieren und eine Vorhersage identisch verarbeitet werden.
-
Die hier beschriebenen Ausführungsformen bauen auf dem System der oben genannten Anmeldung '588 auf, um eine Architektur für das Training, die Verteilung, den Einsatz und die Pflege von trainierten und untrainierten Modellstrukturen für maschinelles Lernen zu definieren. In dieser Offenlegung kann eine beispielhafte Ausführungsform einer solchen Architektur als in einer OptaML™ -Anwendung implementiert bezeichnet werden.
-
Im Folgenden werden Computergeräte erwähnt, die sich beim Kunden vor Ort befinden, und solche, die vom Kunden entfernt sind, aber unter der Kontrolle von Tektronix stehen. Diese Computer verfügen jeweils über einen oder mehrere Prozessoren, aber der hier verwendete Begriff „ein oder mehrere Prozessoren“ kann auch für alle Prozessoren stehen, die im gesamten Software-System arbeiten, unabhängig vom Standort.
-
Ein spezielles Beispiel für eine OptaML™ -Anwendung wird in dieser Offenlegung als OptaML™ Pro bezeichnet. Die Anwendung OptaML™ Pro dient der Ermittlung optimaler Abstimmungsparameter für optische Sender/Transceiver, beispielsweise in einer Fertigungsumgebung. Die Anwendung OptaMI, Pro™ empfängt Wellenformen vom Sender eines Kunden und verwendet maschinelles Lernen, um den optimalen Satz von Abstimmungsparametern für diesen Sender vorherzusagen.
-
Der Begriff „OptaMI,“ bezieht sich auf eine beliebige Version einer Softwareanwendung, die von Tektronix, Inc. für Kunden zum Testen von DUTs bereitgestellt wird. Der Name OptaMI, kann geändert oder vollständig umbenannt werden, aber unabhängig von der Bezeichnung verwendet die hier beschriebene Anwendung Trainingsdaten aus dem Test und der Abstimmung von DUTs (DUT = device under test = zu testende Vorrichtung), um Modelle zu trainieren, die es dem maschinellen Lernen ermöglichen, den Test und die Abstimmung durchzuführen.
-
Jeder Kunde kann mehrere Sendermodelle zum Trainieren haben. Jeder Kunde sollte für seine eigenen Modelle trainieren und nicht für die Modelle eines anderen Kunden. Ausführungsformen der Offenbarung ermöglichen diese Fähigkeit im Allgemeinen.
-
Der hier verwendete Begriff „untrainiertes Modell“ bezeichnet einen Ordner oder eine andere Speicherstruktur, der/die die Trainingssignalformen und Metadaten enthält, aber die neuronalen Netze des tiefen Lernens wurden noch nicht trainiert. Das untrainierte Modell enthält keine gespeicherte Modelldatei mit trainierten neuronalen Netzen und Systemklassenvariablenzuständen. Der hier verwendete Begriff „trainiertes Modell“ bezeichnet einen Ordner oder eine andere Speicherstruktur, die das trainierte neuronale Netz und alle für die Ausführung des Modells erforderlichen Systemklassenvariablenzustände enthält.
-
Ein Anwendungsingenieur, der im Folgenden als OptaML-Ingenieur bezeichnet wird, kann ein untrainiertes Modell nehmen und es trainieren, um es für den Einsatz beim Kunden vorzubereiten. Das trainierte Modell enthält nun eine Modelldatei mit den trainierten neuronalen Netzen und allen Zuständen der Systemklassenvariablen, die zur Ausführung des Modells erforderlich sind. In einigen Ausführungsformen der Offenlegung kann der Zugriff auf die Trainingsfunktionalität auf Anwendungstechniker beschränkt sein. In anderen Ausführungsformen kann das System jedoch auch Kunden den Zugriff auf die Trainingsfunktionalität ermöglichen.
-
2 zeigt ein allgemeines Blockdiagramm einer beispielhaften Ausführungsform einer Modellverteilungsarchitektur gemäß einigen Ausführungsformen der Offenlegung. 3-4 zeigen detailliertere Ausführungsformen der Elemente von 2. 2 zeigt das Kunden-Repository 60, das auch als lokales Repository bezeichnet wird oder sich an einem Kundenstandort befindet. Der Kunde besitzt und verwaltet ein oder mehrere Datenverarbeitungsgeräte wie Computer, Server usw., auf denen seine trainierten und untrainierten Modelle gespeichert werden können. Das Kundenrepository kann sich beispielsweise in den Räumlichkeiten des Kunden, auf einem vom Kunden kontrollierten Cloud-Server oder Konto befinden oder über mehrere physische Standorte des Kunden verteilt sein. Der Kunde hat die Kontrolle über das Kunden-Repository, unabhängig davon, wo oder wie es ausgebildet ist.
-
Das System hat eine Anzahl, M, von Kunden. Jeder Kunde 1 bis M hat sein eigenes privates lokales Repository, auf das weder andere Kunden, die das OptaML-System nutzen, noch OptaML-Techniker Zugriff haben, es sei denn, der Kunde hat ihnen ausdrücklich Zugang gewährt. Der Zugang für den Techniker ergibt sich typischerweise daraus, dass der Kunde das System nutzt, um den Zugang zu gewähren. Die Daten eines Kunden werden niemals mit einem anderen Kunden geteilt. Jedes Sendermodell ist einzigartig, so dass die Daten eines Sendermodells nicht für das Trainieren eines anderen Sendermodells verwendet werden.
-
Im Blockdiagramm von 2 interagiert das lokale Kunden-Repository 60 mit einem zentralen Repository, das hier als OptaML-Repository 70 bezeichnet wird. Das zentrale Repository, das die oben beschriebenen Konfigurationen für das Kunden-Repository aufweisen kann, hat eine Partition für jeden Kunden. Das zentralisierte Repository verfügt über ein zentralisiertes Repository für jeden Kunden, für eine Anzahl Q von Kunden. Diese Repositorys bleiben voneinander getrennt, so dass keine Daten aus einem Repository eines Kunden in die Repositorys anderer Kunden gelangen können.
-
Das Kundenrepository 60 kann die trainierten Modelle mit den Trainingsdaten an die Kundenpartition 70 im zentralen Repository übertragen. Wie das Kunden-Repository über die trainierten Modelle und ihre Daten verfügt, wird in der Diskussion zu 3 behandelt. Das Kunden-Repository 60 kann auch untrainierte Modelle und Trainingsdaten an das OptaML-Repository übertragen. Das OptaMI,-Repository 70 kann das Trainieren dieser Modelle durchführen und überträgt die trainierten Modelle nach dem Trainieren zurück an das Kunden-Repository und speichert sie im OptaML-Repository für diesen Kunden. Darüber hinaus kann das OptaML-Repository auf Anfrage des Kunden andere trainierte Modelle und deren Trainingsdaten aus dem Repository des Kunden an den Kunden übertragen. Der Kunde kann ein gespeichertes Modell aus vielen Gründen anfordern, z. B. zur Validierung, Fehlersuche usw.
-
2 zeigt auch die Kundenteststationen (MFG-Teststation) 1 bis zu einer gewissen Anzahl von N. Das Kundenrepository 60 interagiert mit diesen Stationen, wie z. B. 80. Jede Station 80 enthält eine Kopie der Modellstruktur von 1. Die MFG-Stationen sammeln die Trainingsdaten, die zum Trainieren der Modelle verwendet werden. Die MFG-Stationen testen die DUTs, die getestet werden müssen. Während des Tests der DUTs sammeln die MFG-Stationen Trainingsdaten. Die MFG-Stationen senden die untrainierten Modelle und ihre zugeordneten Daten zurück an das Kunden-Repository. Sobald die Modelle trainiert sind (siehe unten), kann das Kunden-Repository das trainierte Modell oder das trainierte Modell und die zugeordneten Trainingsdaten an die MFG-Stationen senden. Die Übermittlung des Modells und der zugeordneten Trainingsdaten ist mit einem größeren Datenvolumen verbunden. Es bietet jedoch den Vorteil, dass OptaMI, bessere Debugging-Möglichkeiten auf einzelnen MFG-Stationen bietet, wenn Probleme mit der MFG-Station auftreten. Der Kunde kann die Trainingskurven sofort in OptaMI, visualisieren und sie dann mit den aktuellen Vorgängen in der MFG-Station vergleichen. Wenn der Kunde nur die trainierten Modelle sendet, ist die Datenmenge wesentlich geringer. Diese Option bedeutet, dass der Vergleich der MFG-Linien-Wellenformen mit den für das Trainieren verwendeten Wellenformen für die Fehlersuche oder die Visualisierung in dem/den Kundengerät(en) mit den Trainingsdaten durchgeführt werden muss.
-
Die MFG-Teststationen bestehen aus Computern für jede Teststation in der Fertigungslinie des Kunden zum Test und zur Abstimmung von DUTs. Auf dem Computer läuft die Testautomatisierungssoftware des Kunden zur Steuerung der MFG-Linie für diese Teststation. In einer Ausführungsform führt der Computer die OptaML-Software aus, die auch als MI,-Tools-Anwendung bezeichnet wird, um optimale Abstimmungsvorhersagen für das DUTs zu treffen. Andere Ausführungsformen der OptaML-Software können in Zukunft weitere Funktionen bieten. In dieser Ausführungsform empfängt die MFG-Teststation das trainierte Modell aus dem Kunden-Repository. Das trainierte Modell dient als Kommunikationsschnittstelle zwischen der Testautomatisierungssoftware des Kunden und der OptaML-Software. Das trainierte Modell enthält die trainierten Deep-Learning-Netze und die OptaML-Systemklassenvariablenzustände, die für die Verwendung der Deep-Learning-Netze zur Erstellung von Abstimmungsvorhersagen oder Messvorhersagen erforderlich sind.
-
Das Modell kann ein untrainiertes Modell auf der MFG-Teststation sein. Wenn die MFG-Teststation die Live-Trainingsdatenerfassung während des Betriebs der MFG-Linie durchführt, sammelt sie Trainingsdaten in der Speicherstruktur für untrainierte Modelle, bis sie genügend Daten gesammelt hat. Zu verschiedenen Zeitpunkten können die untrainierten Modelle von der MFG-Teststation zurück in den Kundenrepository übertragen werden.
-
Wenn die Testautomatisierungssoftware des Kunden eine Live-Trainingsdatenerfassung implementiert hat, kann ein untrainiertes Modell auf der MFG-Teststation verwendet werden, während die Daten erfasst werden. Sobald die Station genügend Daten gesammelt hat, werden die Daten von der MFG-Teststation an das Kunden-Repository übertragen, wo sie dann für das Trainieren verwendet werden können, um ein trainiertes Modell zu erhalten. Das Modell kann auch vom Kundenrepository in den OptaML-Speicher übertragen und am OptaML-Standort trainiert werden. Die Schulung des Modells, auf die weiter unten näher eingegangen wird, erfolgt entweder per Fernzugriff durch einen Techniker, lokal beim Kunden oder im zentralen Repository. Die Schulung vor Ort kann auf der Grundlage eines Passworts oder einer anderen Zugangsberechtigung des OptaMI,-Systems für den Kunden erfolgen.
-
3 zeigt eine detailliertere Ansicht einer Ausführungsform des Kundenrepositorys. Die Speicherstrukturen 62 und 66 stellen spezifische Implementierungen des Datenspeichers 30 aus 1 dar. Die MI,-Tool-Anwendung 64 stellt eine spezielle Implementierung der ML-Tool-Anwendung OptaMI, 50 aus 1 dar.
-
Das Kunden-Repository kann untrainierte Modelle enthalten, für die der Kunde die Modellspeicherstruktur erstellt und Trainingsdaten gesammelt hat, um sie darin zu speichern. Aus den untrainierten Modellen können auf verschiedene Weise trainierte Modelle werden. In einer Ausführungsform kann der OptaML-Techniker den Trainingsvorgang im lokalen Repository des Kunden durchführen und ein trainiertes Modell erstellen, das nun im lokalen Repository gespeichert wird (siehe Pfeil 65). Das lokale Repository überträgt dann eine Kopie des trainierten Modells an das entfernte, zentralisierte OptaMI,-Repository, wie durch Pfeil 69 angezeigt. Die Übertragung des Modells vom lokalen Repository 60 zum entfernten Repository 70 kann auf beliebige Art und Weise erfolgen, über ein Netzwerk, kopiert über eine Art physisches Medium. In einigen Ausführungsformen ist es auch möglich, dass die OptaML-Softwareanwendung eine direkte Kommunikation und verwaltete Datenverbindung zwischen den Versionen, die auf dem lokalen Kunden-Repository laufen, und den Versionen, die auf dem entfernten OptaML-Repository laufen, implementiert. Einige Kunden können jedoch keine direkte Kommunikationsverbindung von einer MFG-Teststation des Kunden zurück zu einem OptaML-Remote-Repository herstellen.
-
Alternativ kann der Kunde das untrainierte Modell an das entfernte OptaML-Repository senden, wo der OptaML-Techniker das Modell trainieren kann. Der Pfeil 61 am unteren Rand des Speichers für untrainierte Modelle 62 steht für diese Ausführungsform. In einer anderen Variante kann der Kunde, sofern seine OptaML-Lizenz dies zulässt, das Trainieren durchführen und im Kunden-Repository speichern, wie durch Pfeil 67 dargestellt. Er kann auch eine Kopie an OptaMI, senden, um sie im OptaML-Repository zu speichern (Pfeil 69), wie es in seiner Lizenzvereinbarung vorgesehen ist. Das OptaML-Repository überträgt dann das trainierte Modell zurück in das Kunden-Repository für trainierte Modelle 66, wie durch den Pfeil 63 am unteren Rand des Repository für trainierte Modelle angezeigt wird.
-
Eine Überlegung betrifft die Benennung der Modelle, wenn sie für das Trainieren erstellt werden. Eine Versionsnummer für ein Modell kann in den Namen des Modells aufgenommen werden. Während des Trainings können viele Modelle mit verschiedenen Versionen aus dem Prozess der Abstimmung des Tensor-Erstellers und der Hyperparameter für das Trainieren des neuronalen Netzes resultieren. Das System kann dann die Leistung der Modelle verfolgen, um das beste Modell zu ermitteln. Dies würde in Zukunft helfen, wenn ein neues Trainieren mit neuen Trainingsdaten durchgeführt werden muss. Der Kunde kann dann alle Modelle, die nicht gut abschneiden, löschen und nur die relevanten Modelle behalten. Die Versionskontrolle kann die Versionsnummer und/oder andere Kennzeichnungen, die Historie und andere Metadaten wie Leistungsstatistiken umfassen.
-
4 zeigt eine detailliertere Ausführungsform des zentralisierten OptaMI,-Fern-Repositorys 70. Das unten beschriebene Fern-Repository soll es dem OptaML-Ingenieur ermöglichen, jederzeit eine der Modellversionen des Kunden ferngesteuert zu laden. Der OptaML-Ingenieur kann dann den Kunden bei allen Wartungs- oder Fehlerbehebungsproblemen helfen, die ferngesteuert angegangen werden können, ohne dass der Benutzer die Testautomatisierungs-SW des Systems nutzt. Dies könnte zum Beispiel Datenanalysen und Modellvalidierungsprüfungen umfassen.
-
Wie bereits erwähnt, befindet sich das zentralisierte Repository 70 beim Anbieter Tektronix. Wie in 2 dargestellt, verfügt das zentrale Repository über Q-Repositorys oder Partitionen im zentralen Repository, z. B. eine für jede unterschiedliche OptaMI,-Anwendung, die im Laufe der Zeit erstellt wird. Beispiele hierfür sind verschiedene Modelle für die Abstimmung optischer Transceiver, Anwendungen für andere Anwendungsfälle, Tests, Messungen, Kalibrierungen, Abstimmungsanwendungen usw. Dieses Repository kann die trainierten Modelle für alle Kunden enthalten, die für das Trainieren ihrer Modelle bezahlt haben. Die Kundenpartition kann wiederum Partitionen als Unter-Repositorys haben, die für verschiedene Modelle, verschiedene Versionen desselben Modells und verschiedene Komponenten bestimmt sind.
-
Wie in 4 dargestellt, verwaltet OptaMI, die Modelldaten auf verschiedene Weise, wie unten beschrieben. Dieses Repository kann trainierte oder untrainierte Modelle enthalten. Der Teil 76 für trainierte Modelle des OptaMI,-Repository 70 kann ein trainiertes Modell aus einem Kunden-Repository erhalten (siehe Pfeil 77), wenn das Trainieren im lokalen Kunden-Repository entweder von einem OptaML-Techniker oder einem Kunden durchgeführt wurde. Das OptaMI,-Remote-Repository kann untrainierte Modelle, dargestellt durch Pfeil 75, zum untrainierten Modellteil 72 erhalten. Diese kommen aus dem Kunden-Repository, nachdem der Kunde genügend Trainingsdaten gesammelt hat, um mit dem Trainieren fortzufahren.
-
Ein OptaML-Ingenieur kann die OptaML- oder Tool-Anwendung 74, die die spezifische Implementierung der Tool-Anwendung 50 aus 1 darstellt, verwenden, um das Trainieren in diesem OptaMI,-Repository durchzuführen, wenn ein untrainiertes Modell von einem Kunden-Repository empfangen wird. 4 stellt den Trainingsprozess mit Pfeil 71 dar, der dann in dem durch Pfeil 73 dargestellten trainierten Modellteil 76 gespeichert wird. Nach dem Trainieren sollte das System eine Kopie des trainierten Modells zurück in das Kunden-Repository übertragen, dargestellt durch Pfeil 77. Wie bereits erwähnt, gibt das System die trainierten Modelle niemals an andere Kunden weiter, es sei denn, die Kunden haben dem gemeinsam zugestimmt. Es sendet das trainierte Modell nur an den Kunden zurück, der das untrainierte Modell für das Trainieren zur Verfügung gestellt hat.
-
Die Speicherung der Modelle in einem zentralen Repository hat mehrere Vorteile. Sie ermöglichen Service-Interaktionen mit den verschiedenen Kunden. Dies kann z. B. die Behebung von Problemen oder die Unterstützung der Kunden bei der Visualisierung ihrer Daten umfassen.
-
Zusammenfassend beschreiben die Ausführungsformen eine Architektur für die Verteilung und Steuerung von Modellen des maschinellen Lernens, um die Interaktionen zwischen dem lokalen Modell-Repository eines Kunden und einem entfernten OptaML-Modell-Repository zu verwalten. Die ursprünglichen Trainingsdaten werden von der Testautomatisierungs-SW des Benutzers gesammelt und in einer untrainierten Modellstruktur im Repository des Kunden abgelegt. Das untrainierte Modell kann im lokalen Repository des Kunden trainiert werden, oder es kann in das OptaMI,-Repository kopiert und dort trainiert werden. Wenn ein Modell trainiert wird, muss eine Kopie davon sowohl im Kunden-Repository als auch im OptaML-Repository gespeichert werden. OptaMI, kann das Modell in seinem Repository für Service-Interaktionen mit dem Kunden verwenden und es für andere Forschungszwecke nutzen, wenn der Kunde dies erlaubt. Der Kunde kann dann die trainierten Modelle aus seinem lokalen Repository an seine einzelnen MFG-Teststationen verteilen. Jeder Kunde hat seine eigenen lokalen Repositorys, und die Daten eines Kunden werden niemals an andere Kunden weitergegeben. Diese Übertragung an die MFG-Teststationen kann die Trainingsdaten in das Modell einschließen. Diese Übertragung kann die Trainingsdaten aus dem Modell ausschließen, je nachdem, wie sie das System betreiben wollen. Daher beschreibt diese Offenlegung eine vollständige Architektur für die Steuerung von trainierten und untrainierten Modellen zwischen Kunden-Repositorys und OptaML-Repositorys.
-
Aspekte der Offenlegung können auf einer speziell entwickelten Hardware, auf Firmware, digitalen Signalprozessoren oder auf einem speziell programmierten Allzweckcomputer mit einem Prozessor, der nach programmierten Anweisungen arbeitet, arbeiten. Die hier verwendeten Begriffe „Controller“ oder „Prozessor“ sollen Mikroprozessoren, Mikrocomputer, anwendungsspezifische integrierte Schaltungen (ASICs) und spezielle Hardware-Controller umfassen. Ein oder mehrere Aspekte der Offenbarung können in computerverwendbaren Daten und computerausführbaren Anweisungen verkörpert sein, beispielsweise in einem oder mehreren Programmmodulen, die von einem oder mehreren Computern (einschließlich Überwachungsmodulen) oder anderen Geräten ausgeführt werden. Im Allgemeinen umfassen Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren, wenn sie von einem Prozessor in einem Computer oder einem anderen Gerät ausgeführt werden. Die computerausführbaren Anweisungen können auf einem nicht transitorischen, computerlesbaren Medium wie einer Festplatte, einer optischen Platte, einem Wechselspeichermedium, einem Festkörperspeicher, einem Random Access Memory (RAM) usw. gespeichert sein. Wie dem Fachmann klar sein wird, kann die Funktionalität der ProgrammModule in verschiedenen Aspekten beliebig kombiniert oder verteilt werden. Darüber hinaus kann die Funktionalität ganz oder teilweise in Firmware oder Hardware-Äquivalenten wie integrierten Schaltungen, FPGA und dergleichen verkörpert sein. Bestimmte Datenstrukturen können verwendet werden, um einen oder mehrere Aspekte der Offenbarung effektiver zu implementieren, und solche Datenstrukturen werden im Rahmen der hier beschriebenen computerausführbaren Anweisungen und computerverwendbaren Daten in Betracht gezogen.
-
Die offengelegten Aspekte können in einigen Fällen in Hardware, Firmware, Software oder einer Kombination davon implementiert werden. Die offengelegten Aspekte können auch in Form von Befehlen implementiert werden, die auf einem oder mehreren nicht-übertragbaren computerlesbaren Medien gespeichert sind, die von einem oder mehreren Prozessoren gelesen und ausgeführt werden können. Solche Anweisungen können als Computerprogrammprodukt bezeichnet werden. Computerlesbare Medien, wie hier beschrieben, sind alle Medien, auf die ein Computer zugreifen kann. Computerlesbare Medien können zum Beispiel Computerspeichermedien und Kommunikationsmedien umfassen, ohne darauf beschränkt zu sein.
-
Computerspeichermedien sind alle Medien, die zur Speicherung von computerlesbaren Informationen verwendet werden können. Zu den Computerspeichermedien gehören beispielsweise RAM, ROM, EEPROM (Electrically Erasable Programmable Read-Only Memory), Flash-Speicher oder andere Speichertechnologien, CD-ROM (Compact Disc Read Only Memory), DVD (Digital Video Disc) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen sowie alle anderen flüchtigen oder nicht flüchtigen, entfernbaren oder nicht entfernbaren Medien, die in einer beliebigen Technologie eingesetzt werden. Computerspeichermedien schließen Signale als solche und vorübergehende Formen der Signalübertragung aus.
-
Kommunikationsmedien sind alle Medien, die für die Übertragung von computerlesbaren Informationen verwendet werden können. Zu den Kommunikationsmedien gehören beispielsweise Koaxialkabel, Glasfaserkabel, Luft oder jedes andere Medium, das für die Übertragung von elektrischen, optischen, Hochfrequenz- (HF), Infrarot-, akustischen oder anderen Signalen geeignet ist.
-
BEISPIELE
-
Im Folgenden werden Beispiele für die offengelegten Technologien aufgeführt. Eine Ausführungsform der Technologien kann eines oder mehrere und jede Kombination der unten beschriebenen Beispiele umfassen.
-
Beispiel 1 ist ein Steuerungssystem für maschinelles Lernen, das Folgendes umfasst: ein Repository mit einer oder mehreren Partitionen, wobei die eine oder die mehreren Partitionen von anderen der einen oder mehreren Partitionen getrennt sind; eine Kommunikationsschnittstelle; und einen oder mehrere Prozessoren, die so ausgebildet sind, dass sie Code ausführen, um zu bewirken, dass der eine oder die mehreren Prozessoren Folgendes veranlassen: ein ausgewähltes Modell und zugeordnete Trainingsdaten für das ausgewählte Modell über die Kommunikationsschnittstelle von einem Kunden zu empfangen; das ausgewählte Modell und die zugeordneten Trainingsdaten in einer für den Kunden bestimmten Partition zu speichern; und die eine oder die mehreren Partitionen zu verwalten, um sicherzustellen, dass der Kunde nur auf die für den Kunden bestimmte Partition zugreifen kann.
-
Beispiel 2 ist das Steuerungssystem für maschinelles Lernen aus Beispiel 1, wobei der eine oder die mehreren Prozessoren ferner so ausgebildet sind, dass sie Folgendes veranlassen: das ausgewählte Modell unter Verwendung der zugeordneten Trainingsdaten zu trainieren, bevor sie das ausgewählte Modell und die zugeordneten Trainingsdaten speichern; und das ausgewählte Modell und die zugeordneten Trainingsdaten nach dem Trainieren an den Kunden zu übermitteln.
-
Beispiel 3 ist das Steuerungssystem für maschinelles Lernen aus einem der Beispiele 1 und 2, wobei das ausgewählte Modell ein trainiertes Modell ist.
-
Beispiel 4 ist das Steuerungssystem für maschinelles Lernen nach einem der Beispiele 1 bis 3, wobei der eine oder die mehreren Prozessoren ferner so ausgebildet sind, dass sie folgendes veranlassen: eine Anforderung für ein trainiertes Modell zu empfangen, das in der für den Kunden bestimmten Partition gespeichert ist; auf die für den Kunden bestimmte Partition zuzugreifen, um das trainierte Modell und die dem trainierten Modell zugeordneten Trainingsdaten abzurufen; und das trainierte Modell und die dem trainierten Modell zugeordneten Trainingsdaten an den Kunden zu übermitteln.
-
Beispiel 5 ist das Steuerungssystem für maschinelles Lernen nach einem der Beispiele 1 bis 41, wobei der eine oder die mehreren Prozessoren ferner so ausgebildet sind, dass sie einen Code ausführen, der es dem einen oder den mehreren Prozessoren ermöglicht, auf ein oder mehrere Computergeräte zuzugreifen, die sich an einem Kundenstandort befinden.
-
Beispiel 6 ist das Steuerungssystem für maschinelles Lernen von Beispiel 5, wobei der Code, der den einen oder die mehreren Prozessoren veranlasst, auf das eine oder die mehreren Computergeräte zuzugreifen, einen Code umfasst, der es dem einen oder den mehreren Prozessoren ermöglicht, untrainierte Modelle auf dem einen oder den mehreren Computergeräten ferngesteuert zu trainieren.
-
Beispiel 7 ist das Steuerungssystem für maschinelles Lernen von Beispiel 5, wobei der Code, der den einen oder die mehreren Prozessoren veranlasst, auf das eine oder die mehreren Computergeräte zuzugreifen, den einen oder die mehreren Prozessoren veranlasst, trainierte Modelle auf dem einen oder den mehreren Computergeräten ferngesteuert zu debuggen.
-
Beispiel 8 ist das Steuerungssystem für maschinelles Lernen nach einem der Beispiele 1 bis 7, wobei der eine oder die mehreren Prozessoren ferner so ausgebildet sind, dass sie Code ausführen, der veranlasst, dass der eine oder die mehreren Prozessoren dem Kunden ermöglichen, Modelle lokal an einem Kundenstandort zu trainieren.
-
Beispiel 9 ist das Steuerungssystem für maschinelles Lernen nach einem der Beispiele 1 bis 6, wobei die für den Kunden bestimmte Partition in dem Repository eine oder mehrere Partitionen enthält, wobei jede der einen oder mehreren Partitionen Unter-Repositorys umfasst, die für ein oder mehrere von verschiedenen Modellen, für verschiedene Versionen desselben Modells und für verschiedene Komponenten bestimmt sind.
-
Beispiel 10 ist ein Verfahren, das Folgendes umfasst: Empfangen eines ausgewählten Modells und zugeordneter Trainingsdaten für das ausgewählte Modell über eine Kommunikationsschnittstelle von einem Kunden; Speichern des ausgewählten Modells und der zugeordneten Trainingsdaten in einer für den Kunden bestimmten Partition in einem Repository; und Verwalten der einen oder mehreren Partitionen, um sicherzustellen, dass der Kunde nur auf die für ihn bestimmte Partition zugreifen kann.
-
Beispiel 11 ist das Verfahren aus Beispiel 10, das ferner Folgendes umfasst: Trainieren des ausgewählten Modells unter Verwendung der zugeordneten Trainingsdaten vor dem Speichern des ausgewählten Modells und der zugeordneten Trainingsdaten; und Übermitteln des ausgewählten Modells und der zugeordneten Trainingsdaten an den Kunden nach dem Trainieren.
-
Beispiel 12 ist das Verfahren nach einem der Beispiele 10 oder 11, wobei das Empfangen des ausgewählten Modells und der zugeordneten Trainingsdaten ein Empfangen eines trainierten Modells und zugeordneter Trainingsdaten vom Kunden umfasst.
-
Beispiel 13 ist das Verfahren nach einem der Beispiele 10 bis 12, das ferner Folgendes umfasst: Empfangen einer Anfrage nach einem trainierten Modell, das in der für den Kunden bestimmten Partition gespeichert ist; Zugreifen auf die für den Kunden bestimmte Partition zum Abrufen des trainierten Modells und der mit dem trainierten Modell verbundenen Trainingsdaten; und Übermitteln des trainierten Modells und der mit dem trainierten Modell verbundenen Trainingsdaten an den Kunden.
-
Beispiel 14 ist das Verfahren von Beispiel 13, das ferner ein Zugreifen auf ein oder mehrere Computergeräte umfasst, die sich an einem Kundenstandort befinden.
-
Beispiel 15 ist das Verfahren von Beispiel 14, wobei das Zugreifen auf das eine oder die mehreren Computergeräte, die sich am Standort des Kunden befinden, ein Zugreifen auf das eine oder die mehreren Computergeräte umfasst, um das eine oder die mehreren Computergeräte zu verwenden, um ein oder mehrere untrainierte Modelle auf der einen oder den mehreren Computergeräten ferngesteuert zu trainieren.
-
Beispiel 16 ist das Verfahren von Beispiel 14, wobei das Zugreifen auf das eine oder die mehreren Computergeräte, die sich am Standort des Kunden befinden, ein Zugreifen auf das eine oder die mehreren Computergeräte umfasst, um das eine oder die mehreren Computergeräte zu verwenden, um trainierte Modelle auf dem einen oder den mehreren Computergeräten ferngesteuert zu debuggen.
-
Beispiel 17 ist das Verfahren nach einem der Beispiele 10 bis 16, bei dem der Kunde ferner die Möglichkeit hat, Modelle lokal beim Kunden zu trainieren.
-
Die zuvor beschriebenen Versionen des offengelegten Gegenstands haben viele Vorteile, die entweder beschrieben wurden oder für eine Person mit normalen Kenntnissen offensichtlich sind. Dennoch sind diese Vorteile oder Merkmale nicht in allen Versionen der offengelegten Geräte, Systeme oder Verfahren erforderlich.
-
Außerdem wird in dieser schriftlichen Beschreibung auf bestimmte Merkmale verwiesen. Es ist davon auszugehen, dass die Offenbarung in dieser Spezifikation alle möglichen Kombinationen dieser besonderen Merkmale umfasst. Wenn ein bestimmtes Merkmal im Zusammenhang mit einem bestimmten Aspekt oder Beispiel offenbart wird, kann dieses Merkmal, soweit möglich, auch im Zusammenhang mit anderen Aspekten und Beispielen verwendet werden.
-
Auch wenn in dieser Anmeldung auf ein Verfahren mit zwei oder mehr definierten Schritten oder Vorgängen Bezug genommen wird, können die definierten Schritte oder Vorgänge in beliebiger Reihenfolge oder gleichzeitig ausgeführt werden, sofern der Kontext diese Möglichkeiten nicht ausschließt.
-
Obwohl spezifische Beispiele der Erfindung zum Zwecke der Veranschaulichung dargestellt und beschrieben wurden, können verschiedene Modifikationen vorgenommen werden, ohne von Geist und Umfang der Erfindung abzuweichen. Dementsprechend sollte die Erfindung nicht eingeschränkt werden, außer wie durch die beigefügten Ansprüche.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 63429538 [0001]
- US 18/482765 [0003]
- US 63/415588 [0003]
