1: Flotten-HMI-Rollout für ähnliche Maschinen
Szenario: Sie verfügen über mehrere ähnliche Assets, wie Linien, Skids, Zellen oder Standorte, und möchten eine konsistente Bedienererfahrung mit Mensch-Maschine-Schnittstelle (HMI) sowie ein vorhersehbares Aktualisierungsmodell.
Ein containerbasierter Ansatz bietet Konsistenz, indem die Laufzeitanwendung in einem standardisierten Containerkontext gestartet wird, und Wiederholbarkeit durch die Verwendung dokumentierter Container-Startparameter wie Portpublizierung, Containerbenennung und optionales Wiederanlaufverhalten. Wenn die Laufzeitanwendung Dateien oder Einstellungen beibehalten soll, die sie erstellt, verbinden Sie den Container mit einem echten Ordner auf dem Computer. So bleiben die Daten auch dann erhalten, wenn der Container neu gestartet oder ersetzt wird.
2: Nebeneinander angeordnete modulare Edge-Services
Szenario: Sie möchten Visualisierung am Edge und möglicherweise auch benachbarte Funktionen bereitstellen (zum Beispiel FactoryTalk® Remote Access™ Runtime).
Container ermöglichen die Bereitstellung mehrerer Komponenten nebeneinander auf einem Host, während sie unabhängig voneinander verpackt bleiben. Die FactoryTalk Optix-Containerlaufanleitung bietet den konkreten Mechanismus für die Ausführung der Optix-Laufzeitanwendung in Docker als Visualisierungskomponente innerhalb der Bereitstellungen.
In einer composable Edge-Architektur ist es zudem vorteilhaft, dezentrale Konnektivitätsdienste neben der Visualisierungs-Laufzeit auszuführen. Zum Beispiel ist FactoryTalk® Remote Access™ Runtime als Docker-Image verfügbar, sodass es als separater Container neben einem FactoryTalk Optix-Laufzeit-Container (oder neben einem anderen ergänzenden containerisierten Dienst auf demselben Host) bereitgestellt werden kann. Dies ist eine natürliche Lösung für Container-Hosts, da Container so konzipiert sind, dass sie benachbart auf derselben Maschine ausgeführt werden können, während die Prozessisolation aufrechterhalten wird.
3: Cloud-Bereitstellungen
Szenario: Einige Unternehmen erweitern diesen Container-Ansatz auch auf Cloud-gehostete Umgebungen, wenn sie eine zentral verwaltete Laufzeitumgebung, standardisierte Rollout-Mechanismen oder eine einfachere Ausrichtung auf cloudessenzielle Operationen wünschen.
In diesen Szenarien gilt dasselbe grundlegende Prinzip der containerisierten Software. Eine Optix-Laufzeit kann als containerisierte Workload verpackt und betrieben werden, während die zugrunde liegende Rechenleistung von der Cloud-Infrastruktur des Kunden bereitgestellt und durch dessen IT-Richtlinien und Sicherheitslage gesteuert wird.
Dies passt natürlich zu den cloudfähigen Workflows von Optix: FactoryTalk® Optix Studio™ Pro unterstützt cloudbasierte Zusammenarbeit und repositorybasierte Entwicklung. Und Rockwell Automation beschreibt Muster für die dezentrale Bereitstellung, die FactoryTalk Remote Access nutzen, um die Notwendigkeit zu verringern, für Updates physisch vor Ort sein zu müssen.
Überlegungen zur containerisierten Bereitstellung von FactoryTalk Optix
Drittanbieter-Grenze
Wenn Sie gerade erst mit containerisierter Software beginnen, wenden Sie sich bitte an den Drittanbieter, wie Docker oder Portainer, um Unterstützung und Lizenzbedingungen zu erhalten.
Lizenzierungsverhalten
Wenn Sie keinen Berechtigungsschlüssel angeben, wird die FactoryTalk Optix-Anwendung nach 120 Minuten beendet. Weitere Informationen finden Sie in der FactoryTalk Optix-Hilfe.
Portpublizierung ist an die Anwendungskonfiguration gebunden
Wenn Optix in einem Container ausgeführt wird, wählen Sie einen Port auf dem Host-Computer und „leiten“ ihn an den Port weiter, den Optix für seinen Web-Client verwendet. Dieser interne Port ist der Web Presentation Engine-Port, den Sie in FactoryTalk® Optix Studio™ festgelegt haben.
Persistenz sollte gezielt erfolgen
Entscheiden Sie im Voraus, was gespeichert werden soll und was temporär sein kann. Die Volumenbindung dient dazu, zur Laufzeit vorgenommene Änderungen zu speichern, indem Laufzeitänderungen in einen lokalen Ordner auf dem Host-Computer geschrieben werden, damit die Änderungen beim Wiederanlauf oder Austausch des Containers nicht verloren gehen.
Wiederholbarkeit steht an erster Stelle, alles andere ist zweitrangig
Der praktische Nutzen der Bereitstellung von FactoryTalk Optix mit containerisierter Software liegt in der Wiederholbarkeit.
Software-Container bieten eine konsistente, dokumentierte Möglichkeit, dieselbe Laufzeitanwendung über verschiedene Umgebungen hinweg auszuführen, indem sie standardisierte Containerstartkonzepte wie Portpublizierung, Wiederanlaufverhalten und (bei Bedarf) Volumenzuordnung für Persistenz verwenden. Dies unterstützt das übergeordnete Ziel der Containerisierung, Abweichungen zwischen Umgebungen zu verringern und die Konsistenz von der Entwicklung bis zur Produktion in der gesamten Informationstechnologie und Betriebstechnologie zu verbessern.
Möchten Sie den nächsten Schritt gehen? Erfahren Sie, wie ThinManager®-Software und FactoryTalk Optix im breiteren Containerisierungskontext zusammenhängen, ohne die beschriebenen Grundlagen zu verändern. Und Sie können das gesamte Portfolio der cloudbasierten FactoryTalk Optix-Software und Hardwaregeräte hier entdecken.
