Roadmap pubblica

Roadmap Cima

Cima evolve come ecosistema operativo per energia e infrastrutture distribuite: un insieme di servizi coordinati per monitoraggio, simulazione, governance, automazione, CRM operativo e controllo sul campo.

Leggi le direzioniEsplora l'orizzonte
Direzioni

Dove stiamo andando.

0.1.x Fondazioni operative

Rendere servizi, versioni, changelog, dati e stato della piattaforma più osservabili e comprensibili.

Fatto / in consolidamento

0.2.x Cliente e ownership

Rendere cliente, impianti, contratti, simulazioni e risorse applicative governabili come un unico modello operativo.

In corso

0.3.x Accesso pubblico

Separare superfici interne e pubbliche, preparando Iris come portale cliente in sola lettura e ad accesso autorizzato.

Prossimo

0.4.x Agenti sul campo

Governare agenti distribuiti, enrollment, identità macchina, inventario e stato operativo.

In corso

0.5.x Lifecycle agenti

Gestire versioni, release, aggiornamenti e rollback degli agenti senza perdere riconnessione e tracciabilità.

Avviato

0.6.x Operazioni remote

Introdurre un canale operativo affidabile tra piattaforma e agenti distribuiti.

Da fare

0.7.x Governance interattiva

Abilitare sessioni interattive, ruoli operativi, autorizzazioni granulari e audit centralizzato.

Da fare

0.8.x Reporting e analisi

Migliorare reportistica, confronti, esportazioni, mappe e viste analitiche condivisibili.

In corso

0.9.x Eventi e notifiche

Preparare notifiche, automazioni e integrazioni future tramite una base event-driven tra servizi.

Da fare

1.0.0 Piattaforma stabile

Integrare le capacità principali in un sistema governato, osservabile e pronto per uso continuativo.

Target
Orizzonte

Le prossime tappe della piattaforma.

Una vista sintetica delle aree su cui stiamo investendo: fondazioni, campo, governance ed esperienza.

01
10 fatte1 in corso

0.1.x - Stabilizzazione e visibilità

La prima linea di lavoro rende più leggibile ciò che esiste già: stato dei servizi, versioni, changelog, flussi di rilascio e dati operativi fondamentali.

  • Cima mostra versioni, changelog pubblico e roadmap pubblica.
  • Cima ha migliorato login, logout, navigazione mobile e pagina di dettaglio Helios.
  • Cima ha introdotto una console Alert Helios con KPI, filtri, matrix operativa, queue paginata e diagnosi rapida.
  • Cima ha introdotto una console Enrollment Helios con KPI, filtri, queue, dettaglio, timeline auth, creazione codice e revoca.
  • Cima ha ridotto chiamate identità ripetute sulle pagine protette, rendendo più reattiva la navigazione ordinaria.
  • Helios espone nuove capacità di ingest per meter e BESS e detail API più ordinata.
  • Helios espone una API UI per leggere alert attivi, aggregazioni per sito/asset, facets e lista eventi.
  • Helios espone API UI per enrollment agent, incluse lista, summary, dettaglio, timeline, creazione e revoca.
  • Atlas ha introdotto cache sulle decisioni autorizzative.
  • Cassandra ha allineato metadata, tariffe, dati zonali e validazioni di bolletta.
  • La visibilità operativa resta da rifinire man mano che arrivano viste customer-aware, notifiche e automazioni.
02
2 fatte3 in corso1 da fare

0.2.x - Customer foundation

Il secondo orizzonte introduce il cliente come entità di primo livello della piattaforma. Prima di esporre nuovi dati, Cima consolida ownership, profili e relazioni necessarie per governare gli accessi.

  • Janus gestisce anagrafiche cliente, impianti, contratti, listino, documenti, scadenzario e audit.
  • Janus permette editing completo di cliente, impianto, voci contratto e listino.
  • Cima deve unificare la navigazione customer-centric tra Janus, Cassandra, Helios e risorse applicative.
  • Cassandra deve collegare simulazioni, progetti, confronti e report alla ownership cliente.
  • Helios deve associare siti, gruppi, impianti e agenti ai clienti in modo interrogabile.
  • Atlas deve completare profili cliente, inviti e provisioning degli utenti finali.
03
1 fatte3 in corso2 da fare

0.3.x - Iris e accesso pubblico

Il terzo orizzonte abilita l'accesso pubblico ai dati tramite Iris, mantenendo separazione netta tra piattaforma interna e portale cliente.

  • Cima e Helios hanno una prima superficie pubblica/privata per la visualizzazione dei gruppi.
  • Atlas deve governare inviti, autenticazione pubblica e autorizzazioni degli utenti cliente.
  • Helios deve preparare viste read-only, schema dati pubblico e reporting esposto in modo controllato.
  • Cassandra deve rendere selezionabili risultati, confronti e report consultabili dal cliente.
  • Iris deve introdurre dashboard cliente, viste impianto assegnate, navigazione dedicata e gestione profilo.
  • Cima UI deve aggiungere amministrazione utenti cliente, onboarding e gestione accessi Iris.
04
19 fatte3 in corso1 da fare

0.4.x - Enrollment agenti

Il quarto orizzonte porta Helios Agent dentro il modello operativo della piattaforma, con identità, registrazione e inventario governati centralmente.

  • Helios ha avviato il flusso di enrollment agent e le API UI dedicate.
  • Cima UI ha introdotto la prima console enrollment con creazione token, queue filtrabile, detail panel, canali, timeline e revoca.
  • Helios espone contatori enrollment, detail read model, timeline auth e fix della summary tenant.
  • Helios ha iniziato a includere gli agenti nella lettura operativa degli alert tenant.
  • Helios espone una prima API UI per remote agents, con lista, summary, filtri, dettaglio operativo, impianti associati, canali e versione.
  • Cima UI ha introdotto la prima vista Agents in sola lettura, con KPI, filtri, tabella flotta, impianti associati e pannello di contesto sempre visibile.
  • Cima UI mostra lo stato dell'agent includendo ultimo sync e versione installata, così la diagnosi iniziale richiede meno passaggi.
  • Helios aggiorna lo stato operativo degli agent tramite heartbeat periodici e marca offline i dispositivi che non vengono più osservati.
  • Helios Agent sincronizza uno snapshot pubblico del proprio stato runtime, mantenendo fuori dal payload token, private key e altri dati sensibili.
  • La sincronizzazione stato dell'agent combina aggiornamenti periodici ed eventi interni, così la piattaforma può ricevere dati freschi senza aumentare inutilmente il traffico.
  • Lo storico dello stato agent viene conservato con retention di 12 mesi, preparando analisi operative e diagnosi senza crescita indefinita del database.
  • La creazione enrollment restituisce un comando terminale già preconfigurato, riducendo passaggi manuali tra console e tecnico sul campo.
  • Il comando generato dalla console scarica l'installer pubblico, passa il token monouso e include il nome impianto quando presente.
  • Helios migliora l'affidabilità delle letture aggregate agent e della manutenzione dello storico stato, riducendo il rischio di blocchi nei processi periodici.
  • Helios Agent v0.1.0 installa una runtime identity locale con credential, private key, fingerprint hash-safe e storage SQLite.
  • Helios Agent supporta enrollment esplicito e shortcut installer-only con solo token, senza richiedere tenant id al tecnico sul campo.
  • Helios Agent crea una sessione autenticata dopo l'enrollment e mantiene il primo polling runtime verso Helios.
  • Helios Agent gestisce in modo più ordinato le sessioni runtime già attive: evita retry aggressivi e attende la finestra corretta prima di riprovare.
  • Helios risolve il tenant dal token di enrollment e restituisce all'agent l'identità completa da salvare localmente.
  • Helios deve completare workflow successivi all'enrollment, azioni operative e stati runtime più ricchi.
  • Cima UI deve evolvere la vista Agents oltre la lettura, aggiungendo azioni controllate, diagnostica e gestione avanzata dei token.
  • Atlas deve preparare machine identity, permessi e governance centralizzata delle identità macchina.
  • L'obiettivo resta monitorare stato, versione e lifecycle dell'agente dalla piattaforma centrale.
05
8 fatte4 in corso1 da fare

0.5.x - Lifecycle management agenti

Il quinto orizzonte rende gli agenti aggiornabili e governabili nel tempo, prima di introdurre funzionalità operative più avanzate.

  • Cima UI mostra già la versione installata dell'agent nella vista flotta, come primo passo verso il lifecycle management.
  • Helios pubblica le basi per scaricare installer e release agent in modo più ordinato, con manifest e checksum pensati per installazioni ripetibili.
  • La distribuzione agent distingue pacchetto runtime, bundle di prima installazione e updater, preparando rollout e aggiornamenti più controllati.
  • Helios espone un installer pubblico che seleziona il bundle corretto per architettura, verifica i checksum e installa l'agent in /usr/local/helios.
  • Helios Agent introduce il controllo aggiornamenti manuale e automatico, con download del pacchetto agent corretto e preparazione di un piano di update.
  • Il manifest release distingue agent, bundle e updater, evitando che un aggiornamento agent usi per errore il pacchetto di prima installazione.
  • La pipeline di rilascio produce artifact separati per agent, bundle di prima installazione e updater.
  • Il runtime agent riduce il rumore operativo nelle riconnessioni, trattando le sessioni remote ancora attive come una condizione attesa e non come un errore da recovery continua.
  • Helios Agent deve completare esecuzione update, gestione rollout e rollback automatico in scenari reali.
  • Helios deve diventare il punto centrale per orchestrazione aggiornamenti, monitoraggio rollout e visibilità dei rollback.
  • La pipeline di rilascio deve completare metadata e pubblicazione controllata delle release.
  • Cima UI deve evolvere la vista versioni agenti in gestione release, monitoraggio update e visibilità rollout.
  • Gli aggiornamenti falliti non devono compromettere la riconnessione dell'agente.
06
1 fatte4 da fare

0.6.x - Operazioni remote

Il sesto orizzonte introduce il primo canale operativo affidabile tra piattaforma e agenti distribuiti.

  • Helios Agent e Helios hanno introdotto una prima sincronizzazione stato via HTTP, utile come base osservabile prima del canale operativo completo.
  • Helios Agent deve introdurre un layer di trasporto, canale MQTT, fallback HTTP ed esecuzione webhook.
  • Helios deve aggiungere dispatch comandi, orchestrazione operazioni, API di stato e monitoraggio operativo.
  • Cima UI deve introdurre dashboard operazioni agenti, viste di esecuzione comandi e diagnostica.
  • Funzionalità come autodiscovery, identificazione gateway e helper di provisioning restano evoluzioni successive, non blocchi della release.
07
5 da fare

0.7.x - Operazioni interattive e governance

Il settimo orizzonte abilita sessioni interattive in tempo reale mantenendo isolamento, auditabilità e controllo centralizzato.

  • Helios Agent deve supportare trasporto WebSocket, session management, shell remota, terminal streaming e audit sessione.
  • Helios deve agire come relay centrale per sessioni interattive, orchestrazione e monitoraggio.
  • Atlas deve introdurre policy di autorizzazione, permessi operativi, RBAC e contratti di validazione sessione.
  • Cima UI deve aggiungere gestione sessioni, workflow connessione agente, terminale web, stato sessione e timeline attività.
  • Ogni operazione sensibile deve essere riconducibile a utente, ruolo e sessione.
08
6 fatte2 in corso1 da fare

0.8.x - Esperienza utente, reporting e analisi

L'ottavo orizzonte aumenta il valore operativo percepito attraverso analisi, viste avanzate, confronti ed esportazioni.

  • Cassandra genera report PDF/Excel on demand e anteprima HTML per le simulazioni.
  • Cassandra supporta confronti multi-job con KPI affiancati e grafici dedicati.
  • Janus esporta CSV e rende più leggibile listino, contratti, clienti e attività.
  • Helios e Cima introducono una console alert con lettura aggregata per sito, asset, severità, codici errore e contesto diagnostico.
  • Helios e Cima introducono una console enrollment per ridurre il lavoro manuale su token agent e troubleshooting di registrazione.
  • Helios e Cima introducono una vista Agents per leggere stato flotta, rischio, canali e versione senza uscire dal contesto operativo.
  • Cima UI deve armonizzare workflow di export, viste reporting avanzate e visualizzazioni condivise.
  • Helios deve estendere reporting, esportazioni, mappe e analytics sugli asset monitorati oltre la console alert.
  • L'obiettivo è permettere a operatori e clienti di analizzare e condividere dati senza uscire dal contesto Cima.
09
1 in corso4 da fare

0.9.x - Fondazione event-driven

Il nono orizzonte prepara notifiche, automazioni e integrazioni future tramite una comunicazione event-driven tra servizi.

  • L'ecosistema deve introdurre backbone eventi, contratti, pubblicazione, consumo, retry e osservabilità.
  • Atlas deve pubblicare eventi di lifecycle cliente e identità.
  • Helios ha consolidato una base dati/query per gli alert e una prima gestione event-driven interna all'agent, ma deve ancora pubblicare eventi relativi a siti, alert, agenti e operazioni.
  • Janus deve abilitare eventi cliente e sincronizzazione con processi CRM.
  • Il sistema notifiche deve preparare email, notifiche in piattaforma e delivery guidato dagli eventi.
10
4 da fare

1.0.0 - Piattaforma integrata e stabile

La release stabile rappresenta il punto in cui le capacità principali risultano integrate, governate e osservabili.

  • Monitoraggio, simulazione, CRM, governance e operazioni sul campo devono condividere identità, audit e confini di accesso coerenti.
  • Clienti e operatori devono disporre di superfici differenziate, con dati contestuali e autorizzati.
  • Agenti, release e operazioni remote devono essere gestiti con lifecycle, tracciabilità e rollback.
  • Reporting, notifiche ed eventi devono rendere la piattaforma pronta per automazioni e integrazioni successive.