1: Rollout HMI per la flotta su macchine simili
Scenario: Avete più asset simili, come linee, skid, celle o siti, e desiderate un’esperienza operatore HMI uniforme 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 occorre che l’applicazione runtime mantenga file o impostazioni che crea, collegate il container a una cartella reale sul computer. In questo modo i dati restano 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 insieme a essa (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 accanto a un altro servizio containerizzato complementare sullo stesso host). Questo si adatta perfettamente agli host di container perché i container sono progettati per funzionare uno accanto all’altro sulla stessa macchina mantenendo l’isolamento dei processi.
3: Implementazioni cloud
Scenario: Alcune organizzazioni estendono questo approccio container anche ad ambienti basati su cloud quando desiderano un runtime gestito centralmente, meccaniche di rollout standardizzate o un allineamento più semplice con le operazioni essenziali del cloud.
In questi scenari, si applica lo stesso aspetto principale del software containerizzato. Un runtime Optix può essere confezionato e gestito come carico di lavoro containerizzato, mentre la computazione sottostante è fornita dall’infrastruttura cloud del cliente e regolata dalle sue policy IT e dalla sua 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 pattern 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 di terze parti, come Docker o Portainer, per assistenza e condizioni di licenza.
Comportamento di licenza
Se non fornite una chiave di licenza di diritto, l’applicazione FactoryTalk Optix si interrompe dopo 120 minuti. Maggiori 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 che Optix usa 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ì le modifiche non vanno perse quando il container viene riavviato o sostituito.
La ripetibilità viene prima di tutto, tutto il resto viene dopo
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 dell’ambiente e migliorare l’uniformità dallo sviluppo alla produzione tra information technology e operational technology.
Volete fare il passo successivo? Esplorate come ThinManager® software e FactoryTalk Optix si inseriscono nella conversazione più ampia sulla containerizzazione, senza cambiare i fondamenti descritti. E potete approfondire l’intero portafoglio di software e dispositivi hardware FactoryTalk Optix basati su cloud qui.
