Dock 4 con Matrice 5TD
Indica anche O4 Ground Station nella configurazione da verificare. Nel collaudo includi gli stati del sistema e il ciclo di ritorno, sostituzione della batteria e ripartenza.
Guida per i progetti aziendali
FlightHub 2 Cloud o On-Premises per DJI Dock 4 e Dock 3
La scelta tra FlightHub 2 Cloud e On-Premises riguarda dove viene gestita la piattaforma, come circolano i dati e chi mantiene disponibile il servizio. Non basta confrontare una licenza: occorre verificare rete, personale IT, accessi, backup e funzioni necessarie al progetto DJI Dock.
DJI Dock 4 e DJI Dock 3
Collega la scelta IT al modello installato
La guida si applica ai progetti con Dock 4 e Dock 3. Parti dall’elenco dei dispositivi e delle funzioni richieste: la scelta Cloud o On-Premises va verificata sulla specifica versione della piattaforma.
Dock 3 con Matrice 4D o 4TD
Documenta sensori, componenti e flussi già in uso. Prima di estendere o migrare il progetto verifica le funzioni necessarie e l’impatto su accessi, integrazioni e archivi.
Non assumere che tutte le funzioni siano identiche tra Cloud, On-Premises e AIO. Inserisci nella proposta versione, compatibilità, piano o licenza, risorse e criteri di accettazione.
Documentazione ufficiale Dock 4 · Manuali per entrambi i modelli
Cloud, On-Premises e AIO: che cosa si sta scegliendo
DJI propone FlightHub 2 e una soluzione FlightHub 2 On-Premises per il deployment locale. La famiglia include anche FlightHub 2 AIO, presentato da DJI come soluzione che semplifica il deployment rispetto a un’installazione tradizionale di server e software. Il dimensionamento e le funzioni vanno verificati sulla configurazione proposta. Riferimenti: DJI FlightHub 2, DJI FlightHub 2 On-Premises e FAQ ufficiali On-Premises e AIO.
Piattaforma Cloud
L’organizzazione utilizza la piattaforma secondo il servizio e il piano disponibili. Deve comunque gestire utenti, connessioni dei siti, utilizzo dei dati e integrazioni di propria competenza.
Deployment On-Premises
La piattaforma viene collocata nell’infrastruttura prevista dal progetto. Occorre chiarire chi gestisce il sistema, quale supporto è incluso e quali componenti hardware e software sono necessari.
Confrontare i modelli assegnando le responsabilità
La domanda pratica non è soltanto “dove risiede il server?”, ma “chi deve intervenire se una funzione non è disponibile?”. La tabella propone i punti da chiarire durante la progettazione, senza presumere la stessa dotazione per ogni piano o edizione.
| Aspetto | FlightHub 2 Cloud | FlightHub 2 On-Premises |
|---|---|---|
| Infrastruttura della piattaforma | Verificare il servizio offerto, le condizioni e le dipendenze di accesso. | Definire ambiente di deployment, risorse e soggetti responsabili della gestione. |
| Funzioni e licenze | Confermare che il piano copra le funzioni richieste. | Confermare funzioni dell’edizione, licenze e componenti proposti. |
| Rete dei siti | Verificare i percorsi di connessione richiesti dal servizio e dalle postazioni. | Progettare i percorsi tra Dock, server, postazioni e servizi eventualmente esterni. |
| Backup e ripristino | Chiarire esportazioni, recupero dei dati e responsabilità contrattuali. | Definire copie, ripristino, prove e responsabilità dell’infrastruttura locale. |
| Aggiornamenti | Valutare le modifiche del servizio e la compatibilità delle integrazioni. | Organizzare versioni, aggiornamenti supportati e verifica successiva. |
| Supporto | Identificare il referente per account, dispositivi e integrazioni. | Identificare anche chi interviene su server, rete e componenti locali. |
Le funzioni esposte dalle API e i requisiti dell’ambiente devono essere controllati sulle rispettive documentazioni: OpenAPI per Public Cloud e OpenAPI per Private Cloud. La presenza di una funzione in una guida o in una demo non basta a confermarla nel piano acquistato.
Mappare i dati prima di scegliere il deployment
Un contenuto acquisito dal drone può attraversare più sistemi: piattaforma operativa, postazione della sala di controllo, applicazione integrata e archivio di lavoro. Una mappa dei flussi evita di confondere la posizione della piattaforma con la posizione di tutte le copie dei dati.
- Origine: quali informazioni vengono prodotte da drone, Dock e utenti.
- Trasmissione: quali collegamenti e servizi sono necessari per la funzione richiesta.
- Conservazione: dove vengono mantenuti file, registri e copie di lavoro.
- Accesso: chi può visualizzare, scaricare, esportare o modificare i contenuti.
- Uscita: quali dati raggiungono VMS, gestionali, consulenti o altre applicazioni.
- Fine del ciclo: come vengono rimossi utenti, cancellati contenuti e gestiti dispositivi dismessi.
Quando le immagini riguardano persone, le scelte di conservazione e accesso vanno esaminate nel contesto del trattamento. Il modello di hosting, da solo, non risolve finalità, liceità e proporzionalità. Riferimento: Garante Privacy — indicazioni sulla videosorveglianza.
Per il collegamento con la sicurezza aziendale, la guida alle integrazioni con videosorveglianza e allarmi aiuta a distinguere flussi di eventi, video e registrazioni.
Disponibilità della piattaforma e continuità del servizio
Un servizio può fermarsi per motivi diversi: connessione del sito, postazione non disponibile, problemi della piattaforma, componente da mantenere oppure mancanza del personale previsto. La scelta Cloud o On-Premises va inserita in una mappa di queste dipendenze.
Chi osserva e segnala il problema
Individuare quale ruolo controlla lo stato dei servizi e chi riceve le segnalazioni. Un avviso non basta se non è assegnato a un referente disponibile.
Come si riprende il lavoro
Definire criteri di ripristino, verifica del sistema e trattamento delle missioni rinviate. Il riavvio della piattaforma non dimostra da solo che il servizio sia pronto a riprendere.
Con un deployment locale, le prove di ripristino dovrebbero coinvolgere il referente dell’infrastruttura. Con un servizio Cloud, occorre conoscere le modalità di assistenza e ciò che resta a carico dell’azienda. In entrambi i casi il personale deve sapere come gestire l’indisponibilità secondo le procedure delle missioni da remoto.
Una piattaforma disponibile non supera i limiti meteorologici, tecnici o normativi della missione. Il deployment va scelto insieme al quadro dell’operazione, evitando di usarlo come sostituto delle verifiche di volo.
Confrontare i costi includendo il lavoro necessario
Per confrontare due proposte, utilizzare lo stesso perimetro: numero di siti, utilizzo previsto, funzioni, integrazioni, conservazione e supporto. Un prezzo di licenza non è confrontabile con una soluzione che include anche infrastruttura e servizi.
| Voce | Domanda da porre |
|---|---|
| Software e licenze | Quale edizione, periodo, capacità e dotazione funzionale comprende la proposta? |
| Infrastruttura | Sono necessari server, appliance, archiviazione o altri componenti? Chi li mantiene? |
| Connessioni e rete | Quali servizi di rete sono richiesti per siti e postazioni? |
| Implementazione | Sono inclusi configurazione, trasferimento delle informazioni iniziali e collaudo? |
| Integrazioni | Quali collegamenti vengono realizzati e chi ne gestisce le modifiche? |
| Gestione nel tempo | Quali attività di supporto, aggiornamento, backup e ripristino sono comprese? |
| Personale | Quanto lavoro richiedono gestione operativa, IT e formazione dei ruoli coinvolti? |
Il calcolo dovrebbe separare investimento iniziale e costi ricorrenti, chiarendo le assunzioni. Non è corretto considerare l’On-Premises sempre più economico o il Cloud sempre meno impegnativo: dipende dall’organizzazione e dal servizio richiesto.
La formazione del personale e la gestione di manutenzione e aggiornamenti completano il confronto, perché incidono sul funzionamento nel tempo.
Quando valutare il Cloud e quando approfondire l’On-Premises
Un servizio Cloud può essere una direzione da esaminare quando l’azienda vuole utilizzare una piattaforma senza assumere il deployment locale, a condizione che servizio, dati e accessi soddisfino i requisiti. L’On-Premises merita un approfondimento quando esistono requisiti specifici sull’infrastruttura e un’organizzazione capace di gestirla.
La scelta dovrebbe essere motivata da un breve documento con requisiti indispensabili, funzioni confermate, responsabilità, costi e aspetti ancora aperti. Se un punto essenziale non è documentato, deve restare una verifica da completare, non diventare una caratteristica presunta.
- Concordare una missione e un flusso dati rappresentativi per la prova.
- Verificare gli accessi reali dei ruoli, senza utilizzare per tutti un account amministratore.
- Controllare la disponibilità dei contenuti e delle integrazioni richieste.
- Esaminare una situazione di indisponibilità con procedure e referenti concordati.
- Registrare il risultato del collaudo e le condizioni necessarie all’avvio.
Domande frequenti
On-Premises significa che tutti i dati rimangono sempre in azienda?
Occorre verificare l’architettura e ogni flusso: integrazioni, esportazioni, postazioni e servizi collegati possono creare ulteriori percorsi o copie. Il luogo della piattaforma non descrive da solo l’intero ciclo dei dati.
Le funzioni Cloud e On-Premises sono sempre identiche?
La corrispondenza va controllata per edizione, versione, licenze e configurazione. Non si dovrebbe assumere la disponibilità di tutte le funzioni basandosi soltanto sul nome FlightHub 2.
FlightHub 2 AIO elimina la necessità di un referente IT?
AIO è proposto per semplificare il deployment. Restano da organizzare rete, accessi, gestione del dispositivo e responsabilità dell’assistenza e della continuità.
Si può operare senza internet con la soluzione locale?
La possibilità va verificata per la configurazione e le funzioni richieste. Devono essere documentati i collegamenti e le dipendenze necessari ai dispositivi, alla piattaforma e ai servizi integrati.
Quale modello è più sicuro?
La valutazione dipende da architettura, accessi, configurazione e gestione nel tempo. Il deployment locale non garantisce da solo la corretta protezione, così come un servizio Cloud richiede un utilizzo e una gestione adeguati.
Quali informazioni servono per una proposta?
Numero di siti, dispositivi previsti, funzioni indispensabili, requisiti sui dati, integrazioni, organizzazione IT e modalità di supporto desiderata.
Fonti ufficiali e aggiornamento
Le indicazioni sui prodotti e sul quadro operativo rimandano ai riferimenti ufficiali riportati qui. Le checklist e gli esempi sono schemi di lavoro proposti per impostare il progetto; vanno adattati al sito, alla configurazione e alle procedure applicabili.
- DJI FlightHub 2 — prodotto
- DJI FlightHub 2 On-Premises — prodotto
- DJI — FAQ On-Premises e AIO
- FlightHub 2 — Public Cloud OpenAPI
- FlightHub 2 — Private Cloud OpenAPI
- Garante Privacy — videosorveglianza
Ultima consultazione: 10 ottobre 2026. Verificare revisioni dei manuali, compatibilità, licenze e disposizioni vigenti quando si definisce il progetto.
DJI Dock 4 — manuali di installazione, uso e manutenzione · consultato il 14 ottobre 2026.
Approfondisci gli altri aspetti del progetto
Continua il percorso
Tutte le guide, in un solo indice
Passa da questa pagina agli altri approfondimenti su software, operazioni, formazione, manutenzione e documentazione dei due modelli.
Drone Emotions SRL
Scegliamo la piattaforma partendo dai requisiti
Descrivi siti, funzioni e requisiti IT del progetto. La scelta della piattaforma può essere impostata su un confronto con lo stesso perimetro tecnico e organizzativo.
- Modello: DJI Dock 4, DJI Dock 3 oppure da individuare.
- Numero di siti e dispositivi previsti.
- Requisiti sui dati e sistemi da integrare.
- Referenti IT e modalità di gestione desiderata.
Nel messaggio indica anche il tema «FlightHub 2 Cloud oppure On-Premises», così da contestualizzare la richiesta.