Skip to main content

Modalità operative: Autonoma, Multiutente e CLI

Modalità autonoma (applicazione desktop)

Il backend viene avviato come processo locale all'avvio della sessione e arrestato al termine della stessa. Viene eseguito con i permessi dell'utente del sistema operativo che lo ha avviato. Non è richiesto alcun login aggiuntivo. CODESYS 4. Su Windows, la voce nel menu Start viene utilizzata per aprire l'interfaccia utente in una finestra dell'applicazione separata. In alternativa, sia su Windows che su Linux è possibile utilizzare anche c4-cli standalone-session Comando per avviare la sessione. Per una descrizione del comando, vedere quanto segue: c4-cli standalone-session.

Requisiti

Windows

Linux

Windows x64

Debian Linux (x64 e ARM64)

Attualmente, solo Debian è ufficialmente supportato.

.NET Desktop Runtime E ASP.NET Core Runtime sistemi runtime nell'ultima versione minore del ramo 8.0

Debian Linux (x64): Il aspnetcore-runtime-8.0 pacchetto aggiornato all'ultima versione della patch;

Sistema di runtime per Debian Linux (ARM64) – vedi Installazione tramite script

WebView2 Runtime– disponibile di default in Windows 11 – è necessario per la visualizzazione in una finestra dell'applicazione separata.

Un'interfaccia grafica attiva per avviare l'interfaccia nel browser.

Per entrambi i sistemi operativi: A CODESYS porta e un CODESYS I sistemi runtime non sono inclusi nell'installazione o nel pacchetto Debian. Vengono installati separatamente dal CODESYS Store. Il requisito è un sistema runtime CODESYS Versione 3.5 SP16 o superiore (non sono ammessi runtime compatti). Il gateway e il controller devono essere accessibili dal computer della workstation.

. Restrizioni
  • Un solo utente e una sola porta per sessione. Uno spazio di lavoro non può essere modificato contemporaneamente da più utenti nella stessa sessione.

  • La modalità autonoma è limitata all'accesso tramite localhost.

  • È possibile utilizzare solo gateway raggiungibili dal computer della workstation. Anche il controller deve essere accessibile dal gateway.

  • L'installazione, le estensioni, i repository delle librerie e i repository dei dispositivi vengono gestiti separatamente su ciascuna workstation. Inoltre, sono disponibili repository remoti (per impostazione predefinita per le librerie) forniti tramite CODESYS Deployment Server.

  • Su Linux, solo Debian è ufficialmente supportato. L'esecuzione in emulatori come QEMU – anche implicitamente tramite Docker Multi-Platform – non è attualmente supportata da .NET.

Modalità multiutente (funzionamento come server web)

Il backend viene eseguito come servizio persistente su un server Linux gestito tramite systemd o in un'immagine Docker creata dall'utente. Gli utenti accedono tramite browser attraverso la rete ed effettuano il login con i propri account utente del server. Ogni utente dispone di una sessione individuale, isolata dalle altre. Non viene installato nulla sul dispositivo finale, il che consente di utilizzare come workstation non solo computer Windows e Linux, ma anche, ad esempio, macOS. I progetti sono archiviati centralmente nel file system del server, solitamente nella directory home di ciascun utente.

. Requisiti
  • Server: Debian Linux (x64 e ARM64). Windows non è supportato come sistema operativo server. aspnetcore-runtime-8.0 pacchetto nell'ultimo livello di patch e il CODESYS 4 Sono necessari i pacchetti Debian. Il servizio viene eseguito con un utente di sistema dedicato. Per motivi di sicurezza, c4-server si rifiuta di iniziare come root.

  • Account utente: Ogni utente necessita di un account sul sistema operativo del server. L'account può essere autenticato tramite password ed è membro del codesys-4 gruppo o un gruppo che è stato specificato nel --login-groups opzione all'avvio. Nel container Docker, gli account devono essere forniti all'interno del container, ad esempio tramite PAM, e le directory home devono essere montate come volumi persistenti. Per ulteriori informazioni, consultare quanto segue: Preparazione: Creazione degli account utente.

  • Crittografia È necessario un proxy inverso a monte, ad esempio nginx, che gestisca la crittografia TLS e inoltri le connessioni WebSocket, e un certificato TLS valido o considerato attendibile all'interno della propria organizzazione. Per ulteriori informazioni, consultare quanto segue: Preposizionamento di un proxy inverso TLS.

  • Controllori: UN CODESYS porta e un CODESYS sistema runtime dal CODESYS Store con i seguenti requisiti: il gateway deve essere raggiungibile dal server e il sistema runtime deve essere raggiungibile dal gateway. In alternativa, è possibile implementare un gateway locale direttamente sul server.

  • Conoscenza Amministrazione di sistemi Linux, gestione utenti (PAM, LDAP, IPA, ecc.), gestione pacchetti su Debian, gestione certificati TLS, nonché Docker e nginx se necessario.

. Restrizioni
  • CODESYS 4 Il sistema stesso non implementa ancora la crittografia TLS. Senza un proxy inverso a monte, l'interfaccia utente non funzionerà quando si accede tramite la rete, poiché utilizza API del browser disponibili solo in un contesto sicuro.

  • Il processo di accesso si basa sulla gestione degli utenti del sistema operativo del server. CODESYS 4 non gestisce i propri account utente, ruoli o permessi. Le informazioni sulla versione dell'istanza possono essere richiamate anche tramite /version.json percorso senza effettuare l'accesso.

  • CODESYS 4 Attualmente non viene distribuito come immagine Docker. Per eseguire il sistema in un container, è necessario creare un'immagine separata. Non è possibile fornire supporto per l'utilizzo di base di Docker. Per un esempio di Dockerfile, consultare il seguente link: Esempio di Dockerfile Questo è solo un file di esempio che deve essere adattato alle vostre esigenze specifiche.

  • Solo Debian è ufficialmente supportato. L'esecuzione in emulatori come QEMU – anche implicitamente tramite Docker Multi-Platform – non è attualmente supportata da .NET.

Modalità operativa: c4-cli

Questa modalità operativa è disponibile su tutte le piattaforme, sia localmente tramite terminale che da remoto sul server (ad esempio tramite SSH) o in script (ad esempio in ambienti CI/CD, processi a tempo controllato, ecc.).