1: Implementazione HMI della flotta su macchine simili
Scenario: Avete più asset simili, come linee, skid, celle o siti, e desiderate offrire agli operatori un'esperienza uniforme con l'interfaccia uomo-macchina (HMI) e un modello di aggiornamento prevedibile.
Un approccio basato su container offre uniformità avviando l'applicazione runtime in un contesto container standardizzato, e ripetibilità utilizzando parametri di avvio container documentati come la pubblicazione delle porte, la denominazione dei container e il comportamento di riavvio opzionale. Se avete bisogno che l'applicazione runtime mantenga i file o le impostazioni che crea, collegate il container a una cartella reale sul computer. In questo modo i dati rimangono anche se il container viene riavviato o sostituito.
2: Servizi edge modulari affiancati
Scenario: Desiderate la visualizzazione all’edge e potreste anche voler implementare funzionalità adiacenti (ad esempio, FactoryTalk® Remote Access™ Runtime).
I container consentono di implementare più componenti affiancati su un host mantenendoli confezionati in modo indipendente. Inoltre, la guida all’esecuzione dei container FactoryTalk Optix fornisce il meccanismo concreto per eseguire l’applicazione runtime Optix in Docker come componente di visualizzazione all’interno delle implementazioni.
In un’architettura edge componibile, è anche vantaggioso eseguire servizi di connettività remota insieme al runtime di visualizzazione. Ad esempio, FactoryTalk® Remote Access™ Runtime è disponibile come immagine Docker, consentendo di implementarlo come container separato accanto a un container runtime FactoryTalk Optix (o insieme a un altro servizio containerizzato complementare sullo stesso host). Questo si adatta perfettamente agli host di container, poiché i container sono progettati per funzionare affiancati sulla stessa macchina mantenendo l’isolamento dei processi.
3: Implementazioni cloud
Scenario: Alcune organizzazioni estendono questo approccio containerizzato anche agli ambienti basati su cloud quando desiderano un runtime gestito centralmente, meccaniche di rollout standardizzate o un allineamento più semplice con le operazioni essenziali per il cloud.
In questi scenari, si applica lo stesso principio principale del software containerizzato. Un runtime Optix può essere confezionato e gestito come carico di lavoro containerizzato, mentre la potenza di calcolo sottostante è fornita dall’infrastruttura cloud del cliente e regolata dalle sue policy IT e dalla postura di sicurezza.
Questo si integra naturalmente con i workflow abilitati al cloud di Optix: FactoryTalk® Optix Studio™ Pro supporta la collaborazione basata su cloud e lo sviluppo basato su repository. Inoltre, Rockwell Automation descrive modelli di implementazione remota che sfruttano FactoryTalk Remote Access, riducendo la necessità di essere fisicamente in sede per fornire aggiornamenti.
Considerazioni sull’implementazione containerizzata di FactoryTalk Optix
Confine di terze parti
Per chi inizia con il software containerizzato, fate riferimento al fornitore terzo, come Docker o Portainer, per assistenza e condizioni di licenza.
Comportamento della licenza
Se non fornite una chiave di licenza di diritto, l’applicazione FactoryTalk Optix si interrompe dopo 120 minuti. Ulteriori informazioni sono disponibili nella Guida di FactoryTalk Optix.
La pubblicazione delle porte è collegata alla configurazione dell’applicazione
Quando Optix viene eseguito in un container, scegliete una porta sul PC host e “inoltratela” alla porta utilizzata da Optix per il suo client web. Quella porta interna è la porta Web Presentation Engine che impostate in FactoryTalk® Optix Studio™.
La persistenza deve essere intenzionale
Decidete in anticipo cosa deve essere salvato e cosa può essere temporaneo. L’opzione di binding del volume serve a rendere persistenti le modifiche apportate a runtime scrivendo le modifiche in una cartella locale sull’host, così che non vadano perse quando il container viene riavviato o sostituito.
La ripetibilità viene prima di tutto
Il valore pratico dell’implementazione di FactoryTalk Optix con software containerizzato è la ripetibilità.
I container software offrono un modo uniforme e documentato per eseguire la stessa applicazione runtime in diversi ambienti utilizzando concetti standard di avvio container come la pubblicazione delle porte, il comportamento di riavvio e (quando necessario) la mappatura dei volumi per la persistenza. Questo supporta l’obiettivo più ampio della containerizzazione di ridurre la deriva degli ambienti e migliorare l’uniformità dallo sviluppo alla produzione tra IT e OT.
Volete fare il passo successivo? Esplorate come ThinManager® software e FactoryTalk Optix si inseriscono nella più ampia discussione sulla containerizzazione, senza modificare i principi fondamentali descritti. Inoltre, potete approfondire l’intero portafoglio di dispositivi hardware e software FactoryTalk Optix basati su cloud qui.
