PotoP VMS Studio

Il client chiede al sistema operativo l’elenco dei display e al driver grafico i dettagli, così per ogni monitor vedi produttore, modello, numero di serie, risoluzione, frequenza di aggiornamento, connettore e la GPU che lo pilota, oltre a temperatura e VRAM quando il driver le riporta. Ogni schermo fisico viene identificato dall’hardware, non dalla posizione, e riceve un codice permanente come M1. Nomi e codici vengono salvati su quel client e sopravvivono a riavvii e ricollegamenti. Un monitor scollegato resta in elenco finché non lo elimini, così un wall salvato punta sempre allo stesso schermo.

L’editor gira nel browser e salva il multi-layout sul server, così la stessa ricetta è condivisa con i client desktop. Il browser elenca i propri schermi tramite la Window Management API, che richiede una connessione HTTPS sicura e l’autorizzazione dell’utente. Ogni voce mostra un codice monitor, e i codici assenti su questo browser vengono indicati come non presenti. Scegliendo un layout per un codice, lo aggiungi alla ricetta. La proiezione apre una finestra del browser per ogni schermo corrispondente e la posiziona lì, ciascuna con il proprio layout live.

I multi-layout sono salvati sul server come elenco di codici monitor, ciascuno con il proprio layout. Questa panoramica disegna ogni ricetta come una piccola immagine dei suoi schermi e mostra quanti di essi esistono sul browser che stai usando. Avvia proiezione apre una finestra su ogni schermo corrispondente e lì avvia i layout live. Modifica ed Elimina cambiano la ricetta salvata per tutti i client. L’accesso segue gli stessi diritti di utenti e gruppi del resto del sistema, e un wall può essere associato a utenti o gruppi in modo che si apra automaticamente per loro.

Tramite la Window Management API, che richiede HTTPS e un’autorizzazione da concedere una sola volta, il browser sa su quale schermo fisico si trova ogni finestra. Identifica apre una finestra senza bordi su ogni display rilevato, vi scrive in grande il codice e il nome del monitor e la chiude dopo qualche secondo. Il codice proviene da un registro conservato in questo browser, quindi i nomi assegnati restano e un monitor scollegato rimane in elenco finché non lo elimini. Il pannello dei dettagli riporta risoluzione, posizione, scala e profondità di colore così come li vede il browser.

Mentre la pipeline IA osservava lo stream live, ha salvato ogni rilevamento nel database di analisi con classe, affidabilità, riquadro di delimitazione e miniatura. La riproduzione legge quelle righe per l’istante mostrato e disegna il riquadro sopra il video nel browser, quindi nulla viene impresso nella registrazione. L’elenco laterale è alimentato dalle stesse righe e mostra classe, ora e affidabilità. Cliccando su una voce, la registrazione salta a quell’istante. Il tracker conta inoltre quanti avvistamenti appartengono allo stesso oggetto, così è facile distinguere un’auto parcheggiata da tante auto di passaggio.

Esamina prende il fotogramma sotto la testina e lo invia al server, che vi esegue il detector e ritaglia l’oggetto con la sua maschera. Il pulsante Identifica passa quel ritaglio a un modello linguistico visivo configurato nelle impostazioni IA, eseguito localmente o tramite un provider di tua scelta, e ne mostra la descrizione. Il colore si ricava dal ritaglio stesso. Cerca questo tipo e colore interroga poi il database di analisi alla ricerca di rilevamenti della stessa classe e dello stesso colore in tutte le registrazioni. La descrizione è la migliore ipotesi del modello, che lo dichiara quando l’inquadratura è scarsa.

Il server scorre i segmenti registrati nell’intervallo scelto, decifrandoli in memoria, e ne campiona i fotogrammi. Un filtro a sottrazione dello sfondo salta i fotogrammi vuoti, così detector e tracker girano solo dove qualcosa si muove. Ogni oggetto tracciato diventa un “tubo” di fotogrammi ritagliati con le marche temporali originali. I tubi vengono ripianificati per scorrere contemporaneamente su un unico sfondo comune, e ffmpeg genera il risultato come MP4 con l’ora reale di ogni oggetto impressa nell’immagine. Il processo gira in background con indicazione dell’avanzamento e può essere annullato. Cliccando un oggetto, la timeline salta al suo momento originale.

Il server ritaglia l’intervallo richiesto dai segmenti registrati con ffmpeg, decifrando in memoria le registrazioni crittografate se lo chiedi. Marca temporale, nome della telecamera e filigrana vengono impressi nell’immagine. Se attivi la crittografia, l’MP4 viene cifrato con AES-256 usando una chiave derivata dalla tua password tramite PBKDF2, e accanto viene scritto un file di firma. La password non viene mai salvata, quindi nulla può recuperarla. A seconda della destinazione scelta, il risultato resta sul server, viene scaricato sul tuo computer o entrambe le cose.

Il player funziona su qualsiasi computer, senza server PotoP. Scegli il video crittografato e il relativo file di firma, e inserisci la password. Prima verifica la firma con un HMAC per dimostrare che il file non è stato modificato, poi deriva la chiave dalla password con PBKDF2 e decifra con AES-256. Il video in chiaro esiste solo in memoria durante la riproduzione. Da lì puoi trascinare le maniglie verdi per ritagliare una selezione, salvare un fotogramma o esportare una semplice copia MP4. Una variante basata su browser è inclusa nelle cartelle di esportazione, con launcher per Linux, Windows e macOS.

Ogni telecamera ha le proprie impostazioni di registrazione salvate sul server, e il registratore le applica non appena salvi. I trigger possono essere continui, un programma settimanale oppure eventi come movimento, persona, targa, un ingresso di allarme o una macro, con buffer pre-evento e post-evento, così anche il momento prima del trigger viene conservato. I segmenti vengono tagliati a una lunghezza prestabilita e possono essere cifrati con AES-256 una volta chiusi. La conservazione rimuove i segmenti vecchi in base all’età o a una dimensione massima. Gli eventi di avvio, arresto e rilevamento possono generare notifiche tramite eventi di sistema, e-mail, Telegram o un webhook.

Il detector primario gira a un frame rate configurato, con propria soglia di affidabilità, soglia di sovrapposizione, numero massimo di rilevamenti e filtro di classe. Un tracker, in questa vista ByteTrack, collega i rilevamenti tra i fotogrammi in ID oggetto stabili, su cui si basano conteggio e tempo di permanenza. Gli stadi secondari sono attivati per classe: il riconoscimento targhe parte solo quando viene trovata un’auto, un camion, un autobus o una moto, e posa o segmentazione solo quando compare la loro classe di attivazione. Così il carico resta basso, perché i modelli più pesanti vedono un piccolo ritaglio e non l’intero fotogramma.

Un modello di posa gira sul ritaglio della persona trovato dal detector primario e restituisce i punti chiave del corpo, ciascuno con un’affidabilità. Il server salva lo scheletro e il browser lo disegna sopra l’immagine, con la tabella delle articolazioni a fianco. Il rilevamento delle cadute osserva come quei punti si muovono e si dispongono nel tempo, e un’impostazione di sensibilità ne regola le soglie. Quando scatta, l’evento viene salvato e può generare un avviso o avviare una macro. La tabella live sottostante interroga il database, quindi vedi le stesse righe che arrivano al sistema di allarme.

Un modello di segmentazione gira sugli oggetti trovati dal detector primario e restituisce una maschera a livello di pixel per ciascuno. Il server le invia al browser come immagini di maschera, e l’anteprima le dipinge sopra il fotogramma. Il tracker mantiene un ID per ogni oggetto, così la tabella può mostrare da quanto tempo ciascuno è inquadrato. Quando un oggetto resta fermo oltre la soglia di stazionamento, la logica del ciclo di vita lo segna come abbandonato e la riga diventa rossa. Gli eventi del ciclo di vita, come comparso o uscito, vengono registrati per ricerche successive.

Disegni poligoni e linee direttamente su un’immagine live, e il server li salva nelle coordinate normalizzate della telecamera, così restano corretti a qualsiasi risoluzione. Il tracker segue gli ID degli oggetti, e un attraversamento viene rilevato quando la posizione di un oggetto tracciato passa da un lato all’altro della linea, indicando la direzione da A a B o da B ad A. Le zone generano eventi di ingresso e di permanenza. Ogni evento finisce nel database di analisi con marca temporale e ID della traccia, dove contatori, report, allarmi e macro possono usarlo.

Il rilevamento del movimento ha due sorgenti. Il rilevamento della telecamera arriva come eventi di movimento ONVIF, mentre l’analisi sul server confronta i fotogrammi video con un modello di sfondo, usando CPU o GPU. La maschera è una griglia di blocchi che colori sull’immagine, e i blocchi segnati come ignorati vengono esclusi dal confronto, così foglie o traffico stradale non fanno scattare nulla. Sensibilità, area minima, frequenza di campionamento e riduzione di scala sono regolabili. La maschera viene salvata con la telecamera e applicata dal server non appena salvi.

Disegni dei blocchi su un fotogramma live, e il server li salva con la telecamera. A seconda degli interruttori, il server sfoca o copre quelle aree nello stream live, nelle istantanee e nelle registrazioni. Per il live e le registrazioni lo fa sul server, prima che il video venga salvato o inviato, e nelle registrazioni l’area mascherata va persa definitivamente dal video salvato, come avverte la pagina. Colore e intensità della sfocatura sono regolabili. Al salvataggio le maschere vengono inviate alla pipeline in esecuzione, quindi la modifica si applica senza riavviare la telecamera.

Ogni ritaglio di persona o veicolo viene trasformato in un vettore di aspetto a 256 valori da un piccolo modello di re-identificazione eseguito su OpenVINO, e salvato nel database di analisi. La ricerca codifica allo stesso modo l’immagine di riferimento e la confronta con i vettori salvati tramite similarità del coseno, usando un indice in memoria, così il risultato è esatto e rapido. Poiché confronta l’aspetto complessivo e non un volto, funziona anche con persone viste di spalle o a bassa risoluzione. Selezionando un risultato si caricano la cronologia degli avvistamenti e il percorso di quella traccia, e Segui in Riproduzione apre le registrazioni.

Quando un oggetto tracciato attraversa una linea configurata, il server registra l’evento con direzione, telecamera, linea e ora. Questa schermata legge quegli eventi in tempo reale nell’elenco Recenti. Il report storico li raggruppa in fasce orarie o giornaliere, con colonne entrate, uscite e totale, e può aggiungere tempo di permanenza e occupazione dove configurati. I limiti di occupazione generano un avviso quando vengono superati. Il pulsante CSV esporta il report per i fogli di calcolo, che è il modo in cui di solito si fanno gli studi su personale e occupazione.

Il server conta i rilevamenti per telecamera e per ora dai dati di analisi, comprese targhe e corrispondenze con la watchlist. Quei numeri vengono passati a un modello linguistico, qui un piccolo modello Llama servito localmente da Ollama, che scrive il briefing in linguaggio naturale. Se non è disponibile alcun modello, viene mostrato un semplice riepilogo statistico. Il rilevatore di anomalie non usa modelli IA: impara un conteggio tipico per ogni ora del giorno, separatamente per giorni feriali e fine settimana, e segnala un’ora che supera di molto quella base. Resta silenzioso finché non c’è abbastanza storico.

Una planimetria è una superficie di disegno con un’immagine di sfondo opzionale, elementi edilizi disegnati e icone, salvata sul server insieme al resto della configurazione di sistema. Ogni icona è collegata a un oggetto reale come una telecamera, una luce, un’uscita porta o un citofono, e il server invia lo stato di quell’oggetto a ogni client aperto, così il colore dell’icona cambia quando cambia il dispositivo. I client desktop, browser e telefono leggono tutti la stessa definizione della planimetria e la disegnano autonomamente: per questo una planimetria ha lo stesso aspetto ovunque. Per modificarla servono le autorizzazioni di visualizzazione.

La pagina Nuova planimetria contiene una serie di generatori integrati. Scegli una tipologia di edificio, rispondi a qualche parametro come il numero di ambulatori e quanta attrezzatura posizionare, e l’anteprima viene calcolata all’istante. Con Crea, il generatore scrive pareti, stanze, porte e icone in una normale planimetria sul server. Dopo non c’è nulla di bloccato: il risultato è una planimetria qualsiasi che modifichi come una disegnata a mano, e in alternativa puoi clonare una planimetria esistente, con o senza i suoi elementi edilizi.

I modelli sono generatori basati su codice che dispongono stanze, pareti e icone a partire da pochi parametri, qui il numero di file di server e il livello di dotazione. Le icone vengono create non collegate, con il tipo e l’etichetta giusti per ogni stanza, così l’installatore deve solo associare ciascuna a una telecamera, un sensore o un’uscita reali. Poiché il risultato viene salvato come una normale planimetria, si può rinominare, spostare, ampliare o clonare come qualsiasi altra. Tipologie di edificio diverse usano semplicemente generatori diversi dietro lo stesso modulo.

L’editor delle icone ha una scheda telecamera con un’anteprima a bussola. Trascini una maniglia per orientare, le maniglie laterali per l’ampiezza e una maniglia quadrata per la portata, oppure inserisci i valori e usi i preset degli obiettivi. L’anteprima mostra esattamente ciò che la planimetria disegnerà dopo OK, mentre l’anello e le linee guida esistono solo nell’editor. La stessa scheda sceglie quale telecamera e quale stream (principale o secondario) usa l’icona e cosa fa un clic, ad esempio aprire un’anteprima. Tutti i valori vengono salvati con l’icona.

La finestra mostrata è l’editor dell’icona luce, dove ogni stato (spenta, accesa, attenuata, guasto, offline) ha il proprio colore e pallini di stato opzionali per ingressi e uscite. Un’icona luce viene collegata tramite un plugin di dispositivo, come l’integrazione Philips Hue o l’I/O generico, e il server mantiene il suo stato sincronizzato con la lampada reale. L’accensione automatica da ingressi citofonici o di sensori è gestita dal motore di macro lato server, non dalla planimetria stessa. I problemi segnalati dal plugin, come l’assenza di connessione, hanno un colore dedicato sull’icona.

Un’icona citofonica è collegata a un plugin citofonico, nella finestra l’integrazione Commend ICX, e il server ascolta gli eventi di chiamata di quella postazione. Ogni evento corrisponde a uno stato dell’icona come inattivo, in chiamata uscente, squillo, in chiamata, in attesa, emergenza o guasto di linea, e ogni stato ha il proprio colore, visibile in anteprima nell’editor. Lo stato viene inviato a tutti i client collegati, così la planimetria riflette la postazione reale nel giro di pochi istanti. Le azioni sull’icona, come chiamare o aprire una porta, vengono inviate al dispositivo tramite lo stesso plugin.

Ogni azione di un’icona può essere bloccata con un PIN. Quando un operatore clicca un’icona di questo tipo, il client chiede il PIN prima di inviare il comando al server, così un clic accidentale non può commutare un’uscita o aprire una porta. I PIN possono essere permanenti o temporanei e si impostano per ogni icona nell’editor. Il blocco è una protezione aggiuntiva rispetto ai normali controlli delle autorizzazioni, che il server continua ad applicare a chiunque abbia effettuato l’accesso.

Il pannello Elementi edilizi elenca gli oggetti disegnabili come pareti, porte, finestre, scale, ascensori, strade, piante, recinzioni, piscine e cartelli, e puoi aggiungerne di tuoi. Gli elementi sono forme vettoriali salvate nella stessa planimetria delle icone dei dispositivi, con posizione, dimensione e ordine dei livelli, quindi restano nitidi a qualsiasi zoom. Una planimetria può così essere disegnata interamente all’interno del prodotto, oppure sopra uno sfondo PNG, JPG, BMP o GIF caricato, come il disegno di un architetto.

Ogni client desktop e browser si registra sul server con un ID univoco e continua a segnalare la propria presenza, così la pagina può mostrare cosa è online, l’utente, la GPU, il numero di monitor e l’ultimo contatto. Un amministratore può pre-registrare un client tramite il suo ID o rimuoverne uno. Assegnare un joystick collega il record di un dispositivo a quel client. I joystick di rete inviano piccoli pacchetti UDP o HTTP e restano disattivati quando vengono visti per la prima volta, così nessuno sulla LAN può pilotare le telecamere finché un amministratore non li abilita. I controller joystick IP si collegano tramite VISCA-over-IP: il server resta in ascolto su una porta comportandosi come una telecamera, e inoltra i comandi all’interfaccia PTZ della telecamera reale.

Un gruppo di dispositivi è un insieme di telecamere con un nome su un server. I gruppi di utenti sono collegati ai gruppi di dispositivi, e quando un utente chiede le telecamere il server restituisce solo quelle che appartengono a un gruppo di dispositivi collegato a uno dei suoi gruppi. Le statistiche mostrano il numero di telecamere e quanti gruppi di utenti e quanti utenti hanno accesso. Poiché la regola viene valutata dal server e non dal client, una telecamera aggiunta a un gruppo è subito visibile alle persone giuste, e l’amministratore integrato vede sempre tutto.

Il selettore elenca tutti i gruppi di utenti con una breve descrizione di ciò che ciascuno può fare, e un campo di ricerca restringe l’elenco. Aggiungere un gruppo salva sul server un collegamento tra quel gruppo di utenti e il gruppo di dispositivi. Da quel momento ogni membro del gruppo riceve le telecamere del gruppo in vista live, riproduzione e layout, e nessun’altra tramite questo collegamento. Collegare e scollegare è un’operazione unica e ha effetto sugli utenti già connessi senza riavvii.

Gli amministratori scelgono se registrare le azioni dei client e le modifiche lato server, la gravità minima, quali categorie conservare e per quanti giorni. Una pulizia in background rimuove le righe più vecchie secondo una pianificazione, e Applica conservazione ora la esegue su richiesta. Gli eventi di autenticazione e sicurezza vengono sempre conservati con la loro gravità. Il registro si può scaricare in CSV o PDF, e un processo programmato può inviare il report via e-mail ogni settimana o con la frequenza scelta, usando il server di posta configurato nelle impostazioni degli eventi.

Il PDF viene generato sul server a partire dalle stesse righe di audit mostrate dalla scheda Report, usando una libreria PDF standard per Python e non uno screenshot. Contiene l’intestazione e il logo del prodotto, chi ha generato il report e quando, i filtri attivi, una tabella paginata con riga di intestazione ripetuta e un piè di pagina. I risultati molto grandi vengono limitati, e il report lo dichiara esplicitamente, ad esempio mostrando 5000 voci sul totale. Il report programmato via e-mail allega proprio questo file.

L’editor di macro è un grafo visivo di nodi che gira sul server. Un nodo System Event scatta quando il monitoraggio dello stato genera un evento corrispondente, come un certificato in scadenza, un uso elevato del disco o della GPU o la batteria scarica di un dispositivo, e passa testo e valore dell’evento sulle sue porte di uscita. Collegato a un nodo Telegram Send, pubblica un messaggio tramite la Bot API di Telegram. Il grafo si verifica con Convalida, può essere simulato e, quando è attivo, l’editor mostra i valori che passano attraverso ogni nodo.

La schermata mostra il nodo Telegram Send dell’editor di macro: token del bot, ID della chat, un modello di messaggio con segnaposto per ora e valore, un pulsante Test e un intervallo minimo tra gli invii, così gli eventi ripetuti non inondano la chat. Il server pubblica tramite la Bot API di Telegram quando il nodo riceve un fronte di salita. Gli avvisi via e-mail usano il server SMTP configurato nelle impostazioni degli eventi. Gli eventi stessi provengono dal monitoraggio dello stato del server e dai flussi di eventi delle telecamere.

Il server definisce circa 144 autorizzazioni, ciascuna con un modulo e un livello di azione come usare o modificare. La finestra del gruppo le elenca in sezioni, con un campo filtro, le scorciatoie tutto/usa/modifica e preset che selezionano un insieme tipico. Il server verifica l’autorizzazione pertinente a ogni chiamata API e su ogni canale live, quindi un utente senza diritti PTZ o di registrazione viene respinto anche se chiama direttamente l’API. I tentativi negati vengono scritti nel registro di audit con il nome dell’autorizzazione.

Invece di concedere i diritti utente per utente, un amministratore sposta gli utenti tra gruppi già pronti come Operatori, Visualizzatori e coppie redattore/utente per layout, macro, mappe, PTZ, dispositivi e altro ancora. I diritti effettivi di un utente sono l’unione dei diritti di tutti i gruppi a cui appartiene, più i loro layout e le telecamere dei gruppi di dispositivi collegati a quei gruppi. Modificare un gruppo modifica tutti i membri in una volta, il che mantiene i ruoli coerenti su molti account.

La scheda Risorse di un gruppo imposta tetti numerici, dove zero significa illimitato: telecamere e stream simultanei che un membro può aprire, durata, dimensione e numero di esportazioni al giorno, quanti layout, macro e segnalibri può creare, e richieste API e token all’ora. Il server li applica al momento della richiesta, ad esempio rifiutando uno stream oltre il limite. Le impostazioni del singolo utente possono sovrascrivere il valore del gruppo, così un’installazione condivisa resta prevedibile anche sotto carico.

La scheda Sicurezza di un gruppo definisce sessioni simultanee, timeout della sessione, autenticazione a due fattori obbligatoria, lunghezza minima della password, complessità, scadenza, divieto di riutilizzo, blocco dopo tentativi falliti e relativa durata, oltre a livello di audit e conservazione dei log. Il server applica la policy all’accesso e al cambio password, e le password vengono salvate come hash bcrypt con salt, mai in forma leggibile. I tempi di risposta all’accesso sono uniformati, così un nome utente inesistente non si distingue da una password errata.

La scheda Autorizzazioni dell’utente mostra la stessa matrice di un gruppo, con due colori: le caselle blu sono autorizzazioni dirette modificabili qui, quelle viola provengono dai gruppi dell’utente e in questa vista sono di sola lettura. Il server combina i due insiemi quando verifica una richiesta. Le autorizzazioni dirette sono utili per eccezioni puntuali, e il contatore mostra quante sono attive sul totale e quante provengono dai gruppi. Rimuovi tutte le dirette elimina le eccezioni senza toccare i diritti dei gruppi.

La scheda Sicurezza gestisce il secondo fattore dell’utente, una password monouso basata sul tempo (TOTP) compatibile con le comuni app di autenticazione, insieme ai codici di backup monouso. Mostra inoltre lo stato dell’account, come blocco, tentativi falliti e ultimo accesso, e permette a un amministratore di sbloccarlo o reimpostarlo. Le sessioni attive sono elencate con IP e browser e si possono terminare una per una o tutte insieme. I token API sono credenziali separate con nome e scadenza, così script e integrazioni non hanno bisogno della password dell’utente, e si possono revocare in qualsiasi momento.

La scheda Attività legge dal server due cose per un utente: le sessioni attive, con indirizzo IP, stringa del client e ultima attività, e gli ultimi eventi di sicurezza dal registro di audit. Le azioni rifiutate, come un’autorizzazione negata o una telecamera che l’utente non può vedere, vengono registrate nel momento in cui il server respinge la richiesta, insieme al nome dell’autorizzazione o della risorsa. Le sessioni mostrano il tipo di client, ad esempio un browser o uno script che usa l’API, il che aiuta a distinguere l’uso normale da accessi inattesi.

Il server può generare un’autorità di certificazione o importarne una esistente. Il certificato della CA e la sua chiave privata vengono salvati sul server, con il file della chiave leggibile solo dall’account di servizio e facoltativamente protetto da password, e dalla macchina escono solo certificati firmati. La scheda permette anche di scaricare il certificato della CA, farne il backup e ripristinarlo, installarlo nell’archivio attendibile del sistema, revocare certificati per numero di serie e creare un elenco di revoca (CRL). Dalla stessa CA si può emettere anche un certificato per un server RADIUS per l’802.1X.

Viene generata una nuova coppia di chiavi e la CA salvata firma un certificato per il nome e le voci DNS e IP indicati, con validità e tipo di chiave a scelta. Il risultato viene offerto in PEM (certificato, chiave e CA) o come bundle PKCS#12. Spuntando l’opzione server, il certificato viene installato come certificato del server, la CA diventa attendibile per il client desktop, il vecchio certificato autofirmato viene ritirato e il servizio si riavvia, così i browser smettono di mostrare avvisi non appena si fidano della CA.

Elenchi le telecamere a mano o importi un CSV con indirizzo, produttore, credenziali e porte. Per ogni riga il server emette un certificato del dispositivo dalla CA, invia certificato e CA alla telecamera tramite l’API web del produttore e poi attiva l’HTTPS. Ci sono anche azioni per disattivare l’HTTPS e per testarlo. Il server deve raggiungere le telecamere in rete, e le credenziali vengono usate solo per l’esecuzione. Il risultato è un solo passaggio invece di dover accedere a ogni telecamera.

Per una telecamera, il server firma un certificato del dispositivo, lo carica tramite l’API del produttore e può inviare la CA, attivare l’HTTPS, disattivare l’HTTP in chiaro e testare la connessione sicura. La seconda sezione si collega a un altro host PotoP via SSH, copia certificato, chiave e file della CA nella directory di destinazione e può riavviare un servizio. Entrambe le operazioni girano sul server, che quindi deve poter raggiungere la destinazione, e richiedono diritti di amministratore.

Il pannello mostra il certificato attualmente caricato per il web client con soggetto, emittente, validità, tipo e lunghezza della chiave, algoritmo di firma e impronta SHA-256, e può esportarlo in PEM. La sezione mobile offre il certificato della CA da scaricare o come codice QR da inquadrare con un telefono o un tablet, così il dispositivo si fida del server una volta per tutte e smette di mostrare avvisi. Istruzioni e script di installazione sono forniti per Linux, macOS e Windows.

Prima di inviare la password, la pagina di accesso contatta il server scelto via HTTPS e verifica il certificato con l’archivio attendibile del browser. Se la catena è valida e corrisponde, compare il messaggio verde Connessione sicura, altrimenti l’utente vede un avviso. Il controllo viene eseguito dallo stack TLS del browser stesso, quindi la pagina non può falsificarlo. Le credenziali vengono poi inviate al server verificato tramite la connessione crittografata.

Il pannello RAID nelle impostazioni di amministrazione del server è un motore di disegno che dispone dischi, stripe e parità per il livello scelto. In modalità simulazione scegli un livello e il numero di dischi e il pannello genera un array sintetico, senza toccare nulla di reale. Su un server live la stessa vista viene riempita dal controller effettivo: RAID software tramite mdadm, oppure controller hardware tramite gli strumenti a riga di comando del produttore. Tolleranza ai guasti e capacità utile vengono calcolate dal livello e dal numero di dischi, e lo schema mostra come la parità ruota tra i membri, così gli installatori possono pianificare prima di creare un array.

Lo stesso monitor RAID può disegnare livelli annidati. Qui un RAID 60 simulato di sedici dischi viene mostrato come quattro gruppi RAID 6, con lo striping tra i gruppi in cima. Il pannello calcola la tolleranza ai guasti per gruppo, per cui ogni gruppo sopravvive a due dischi guasti, e la capacità utile come otto dischi su sedici. Il cursore di simulazione sottostante passa quella capacità al calcolatore del tempo di registrazione, che la divide per il bitrate misurato delle telecamere. La pianificazione si basa sui dati del server senza toccare alcun disco.

La finestra Gestione RAID gira nel client desktop ma agisce sul server a cui hai effettuato l’accesso. Un amministratore reinserisce la propria password per ottenere un token di amministrazione di breve durata. La creazione di un array genera un piano: il server elenca i dischi rilevati e prepara il comando esatto come elenco di argomenti, mai come stringa di shell, mostrandolo in anteprima. In fase di pianificazione non viene eseguito nulla. Applica esegue solo quel piano salvato tramite un elenco fisso di strumenti RAID consentiti, e le azioni pericolose ti chiedono prima di digitare l’identità della destinazione. Il RAID software usa mdadm.

Le azioni di espansione e manutenzione seguono lo stesso flusso pianifica-poi-applica della creazione degli array. Il client invia la richiesta, il server convalida ogni nome di dispositivo e costruisce il comando mdadm esatto per aggiungere dischi, espandere, cambiare la dimensione dei chunk o convertire il livello, e lo restituisce per la revisione. Controllo e riparazione di scrub avviano la scansione di coerenza del kernel sull’array. Le velocità minima e massima di risincronizzazione sono i limiti standard del RAID software di Linux, così una ricostruzione può essere rallentata mentre le telecamere registrano. L’applicazione richiede il token di amministrazione e, per i passaggi rischiosi, la conferma dell’identità.

La scheda Configurazione stabilisce come viene rilevato un guasto e come lo standby resta aggiornato. Il monitor verifica ogni server all’intervallo impostato, e un server viene dichiarato guasto solo dopo il numero configurato di verifiche consecutive fallite. I servizi obbligatori sono sempre monitorati, mentre quelli opzionali come VoIP o analisi video contano solo se spuntati. Intervallo dei backup, numero di snapshot conservati e un limite di banda controllano l’agente di replica sul nodo di failover. Gli avvisi possono essere inviati via e-mail (SMTP), Telegram o notifica desktop.

Durante un ciclo di backup il nodo di failover richiede un manifesto dei file e dei database del server live, poi preleva solo ciò che è cambiato dall’ultimo snapshot. I file invariati vengono collegati dalla copia precedente: per questo il pannello può mostrare migliaia di file di cui solo una manciata effettivamente prelevati. L’avanzamento in file e megabyte viene scritto in un record di stato che il client mostra in tempo reale. L’esportazione completata viene ruotata in una cartella di snapshot, e la riga del database dello standby indica In sincronizzazione mentre i dati vengono applicati.

Il subentro avviene automaticamente al raggiungimento della soglia di errore, oppure manualmente con Force Takeover. Lo standby serve allora le telecamere del server guasto, che viene segnato come offline, e il banner e la riga di stato in alto diventano rossi. Quando il server originale risponde di nuovo alle verifiche, Failback riporta a casa le telecamere. La scheda Configurazione può farlo anche automaticamente, dopo che il server è rimasto in salute per un numero di minuti stabilito. I client continuano a funzionare perché utenti e sessioni erano già stati replicati sullo standby.

La scheda Registro eventi annota ogni fase del processo di ridondanza nel momento in cui avviene, con l’ora locale: un ciclo di replica forzato, la richiesta di subentro, l’avvio del processo di subentro, la migrazione delle telecamere, il numero di stream arrestati sul server guasto e il risultato finale. Le voci provengono dalla sequenza di subentro del server e restano per la durata della sessione, con un pulsante Cancella. Poiché ogni transizione viene scritta in ordine, un operatore può verificare in seguito cosa ha fatto il sistema e copiarlo in un rapporto sull’incidente.

La scheda Addestramento contiene i controlli di dataset, augmentation e sorgente delle immagini che alimentano un addestramento. Un dataset è una cartella di immagini con etichette, riempita da file caricati, una webcam, un file video o uno stream RTSP. Le impostazioni di augmentation come mosaico, ribaltamenti, scala, rotazione e variazioni di colore vengono applicate al volo durante l’addestramento. La quota di validazione e il seed casuale rendono le esecuzioni riproducibili. La finestra mostrata compare quando si preme Avvia addestramento senza aver selezionato un dataset. La conversione in ONNX e nei formati per acceleratori si trova in una scheda separata.

Il riconoscimento delle azioni funziona in due fasi. Prima un modello di posa analizza video o immagini ed estrae i punti chiave del corpo di ogni persona, salvati con l’etichetta che scegli, ad esempio cammina o cade. Poi un piccolo classificatore di sequenze, per impostazione predefinita una LSTM, viene addestrato su finestre di fotogrammi consecutivi di quei punti chiave, usando PyTorch sul dispositivo selezionato. Dopo l’addestramento, precisione, richiamo e F1 vengono calcolati per ogni classe su dati di validazione tenuti da parte. Il risultato può essere esportato con un frammento di codice di inferenza da usare nelle analisi.

La scheda targhe addestra una rete di riconoscimento di sequenze di caratteri di tipo LPRNet, che legge l’immagine ritagliata di una targa e decodifica i caratteri con CTC. Scegli il set di caratteri del paese e la dimensione di input, poi raccogli ritagli di targhe da registrazioni, cartelle di immagini, elenchi di URL o dataset pubblici. L’editor delle etichette ti permette di correggere le targhe non etichettate, con suggerimenti OCR opzionali. Test su fotogramma esegue il modello corrente su un’immagine. I modelli completati vengono esportati, e possono essere compilati in un bundle per gli acceleratori Axelera Metis e installati nella cascata di riconoscimento live.

La scheda di annotazione è uno strumento di etichettatura all’interno del Training Studio. Definisci le classi di oggetti, sfogli le immagini del dataset e disegni con il mouse riquadri di delimitazione o poligoni. Ogni annotazione viene salvata con la sua classe e le sue coordinate nella cartella del dataset, nel formato letto dai trainer. Auto-Annotate esegue un modello di rilevamento esistente sull’immagine e propone etichette da accettare o correggere. Il pannello delle statistiche conta le annotazioni totali e i riquadri per classe, così vedi quali classi hanno pochi esempi.

Le domande sull’inventario ricevono risposta direttamente dal database del server, senza un modello linguistico. Scrivere list cameras esegue una ricerca sul server e restituisce nomi, indirizzi IP, produttori e se la telecamera è accesa e in registrazione, presentati come tabella di testo nella Result Board. Lo stesso motore copre planimetrie, server, layout e macro. La chat si limita a presentare il risultato, quindi la risposta riflette la configurazione live e rispetta le autorizzazioni dell’utente collegato.

Le richieste a cui manca un dettaglio, come una query avanzata su una telecamera, avviano un breve dialogo sul server. L’assistente elenca le scelte valide dalla configurazione corrente, qui ogni telecamera con il suo indirizzo, e attende la risposta. Puoi rispondere con la lettera, il nome o l’indirizzo IP. Indietro torna alla domanda precedente e Annulla chiude il dialogo. Il selettore viene generato dai dati live, quindi propone solo telecamere che esistono.

Le domande su database e backup ricevono risposta da funzioni dirette del server. Il comando db status legge la connessione PostgreSQL attiva e riporta tipo, versione, dimensione, numero di tabelle, pool di connessioni e host, con la password mascherata. Il comando backups elenca i backup della configurazione salvati sul server con data e dimensione. L’interruttore LLM abilita un modello linguistico opzionale che gira localmente tramite Ollama, così le domande in forma libera possono essere gestite senza inviare dati a un servizio cloud.

La finestra del livello di dettaglio cambia il modo in cui la chat formatta le risposte del server. I quattro livelli vanno da conteggi su una sola riga all’output completo, valori grezzi compresi. Marche temporali, icone di stato e tabelle ASCII si possono attivare o disattivare, insieme a una modalità di spaziatura compatta e a un limite sugli elementi mostrati negli elenchi. Le impostazioni si applicano sul client quando le risposte vengono visualizzate, così operatori diversi possono usare livelli diversi sullo stesso server. Il pannello dietro la finestra è l’elenco di guida per categorie con i comandi di esempio.