1: Flotten-HMI-Rollout für ähnliche Maschinen
Szenario: Sie verfügen über mehrere ähnliche Anlagen wie Linien, Skids, Zellen oder Standorte und wünschen sich eine konsistente Bedienerfahrung 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 Portfreigabe, Container-Benennung und optionales Wiederanlaufverhalten. Wenn Sie möchten, dass die Laufzeitanwendung die von ihr erstellten Dateien oder Einstellungen beibehält, verbinden Sie den Container mit einem realen Ordner auf dem Computer. Auf diese Weise bleiben die Daten auch dann erhalten, wenn der Container neu gestartet oder ersetzt wird.
2: Modulare Edge-Services nebeneinander
Szenario: Sie möchten Visualisierung am Edge und möglicherweise auch benachbarte Funktionen daneben bereitstellen (zum Beispiel FactoryTalk® Remote Access™ Runtime).
Container ermöglichen die Bereitstellung mehrerer Komponenten nebeneinander auf einem Host, während sie unabhängig voneinander paketiert bleiben. Zudem bietet die Anleitung zum Ausführen von FactoryTalk Optix in Containern den konkreten Mechanismus für die Ausführung der Optix-Laufzeitanwendung in Docker als Visualisierungskomponente innerhalb der Bereitstellungen.
In einer modularen Edge-Architektur ist es außerdem vorteilhaft, Remote-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. Das passt auf natürliche Weise zu Container-Hosts, da Container dafür ausgelegt sind, benachbart auf demselben Computer ausgeführt zu werden und dabei die Prozessisolation aufrechtzuerhalten.
3: Cloud-Bereitstellungen
Szenario: Einige Unternehmen erweitern diesen Container-Ansatz auch auf in der Cloud gehostete Umgebungen, wenn sie einen zentral verwalteten Laufzeit-Footprint, standardisierte Rollout-Mechanismen oder eine einfachere Abstimmung mit für die Cloud wesentlichen Betriebsabläufen wünschen.
In diesen Szenarien gilt dasselbe Kernprinzip containerisierter Software. Eine Optix-Laufzeit kann als containerisierter Workload paketiert und betrieben werden, während die zugrunde liegende Rechenleistung von der Cloud-Infrastruktur des Kunden bereitgestellt wird und deren Steuerung den IT-Richtlinien und der Sicherheitsausrichtung des Kunden unterliegt.
Dies passt auf natürliche Weise zu den cloudbasierten Workflows von Optix: FactoryTalk® Optix Studio™ Pro unterstützt in der Cloud gehostete Zusammenarbeit und repositorybasierte Entwicklung. Zudem beschreibt Rockwell Automation Muster für die Remote-Bereitstellung, die FactoryTalk Remote Access nutzen und den Bedarf verringern, Updates physisch vor Ort bereitzustellen.
Überlegungen zur containerisierten Bereitstellung von FactoryTalk Optix
Abgrenzung zu Drittanbietern
Wenn Sie gerade erst mit containerisierter Software beginnen, wenden Sie sich bitte an den Drittanbieter, zum Beispiel Docker oder Portainer, um Unterstützung und Informationen zu den Lizenzbedingungen zu erhalten.
Lizenzverhalten
Wenn Sie keinen Lizenzschlüssel für Berechtigungen angeben, wird die FactoryTalk Optix-Anwendung nach 120 Minuten angehalten. Weitere Informationen finden Sie in der FactoryTalk Optix-Hilfe.
Die Portfreigabe ist an die Anwendungskonfiguration gebunden
Wenn Optix in einem Container ausgeführt wird, wählen Sie einen Port auf dem Host-PC und leiten Sie ihn an den Port weiter, den Optix für seinen Web-Client verwendet. Dieser interne Port ist der Port der Web Presentation Engine, den Sie in FactoryTalk® Optix Studio™ festlegen.
Persistenz sollte bewusst geplant werden
Entscheiden Sie im Voraus, was gespeichert werden soll und was temporär sein darf. Mit der Option zur Volume-Bindung lassen sich zur Laufzeit vorgenommene Änderungen persistent speichern, indem diese Änderungen in einen lokalen Ordner auf dem Host-Computer geschrieben werden. So gehen Änderungen beim Wiederanlauf oder Ersetzen des Containers nicht verloren.
Wiederholbarkeit steht an erster Stelle, alles andere an zweiter
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, und zwar mithilfe standardisierter Container-Startkonzepte wie Portfreigabe, Wiederanlaufverhalten und, falls erforderlich, Volume-Zuordnung zur Persistenz. Dies unterstützt das übergeordnete Ziel der Containerisierung, Unterschiede zwischen Umgebungen zu verringern und die Konsistenz von der Entwicklung bis zur Produktion über die Informationstechnologie und die Betriebstechnologie hinweg zu verbessern.
Möchten Sie den nächsten Schritt gehen? Erfahren Sie mehr darüber, wie ThinManager®-Software und FactoryTalk Optix im breiteren Kontext der Containerisierung zusammenhängen, ohne die beschriebenen Grundlagen zu verändern. Außerdem können Sie sich hier eingehender mit dem gesamten Portfolio cloudbasierter Software und Hardwaregeräte von FactoryTalk Optix befassen.
