Un anno fa ci siamo impegnati in un’impresa difficile. Volevamo conservare le parti migliori del sistema operativo Ajax Hub (2G) già esistente, rimuovendone al contempo qualsiasi punto debole e gettando solide basi per sviluppare ulteriormente il sistema di sicurezza Ajax. Dopotutto, l’hub è come una concentrazione di cervelli. Deve essere l’anello più eccezionale e affidabile della catena. Migliaia di ore di ingegneria, centinaia di iterazioni e diverse eleganti soluzioni di software ci hanno condotto a OS Malevich. Non è solo un altro aggiornamento. È un sistema operativo dell’hub completamente nuovo.
Una volta raggiunto un vicolo cieco, non bisogna aver paura di voltarsi indietro
Tre anni fa, abbiamo deciso di creare un centro di gestione della sicurezza intelligente, Ajax Hub (2G). Abbiamo redatto l’incarico tecnico e abbiamo iniziato a pensare a come farlo. C’erano tre opzioni: usare C, usare un sistema operativo in tempo reale o usare Linux.
Un tipico programma in C avrebbe assicurato il controllo assoluto come sistema operativo, poiché avremmo programmato noi stessi ogni componente del sistema. Ciò che ci ha fatto desistere è che il progetto avrebbe richiesto lungo tempo, la sua scalabilità sarebbe stata ridotta e avrebbe richiesto un ampio lavoro di debug.
Linux offriva una gran quantità di soluzioni già pronte, così come anche la possibilità di agire in parallelo, con un conseguente rapido sviluppo. Saremmo stati in grado di programmare in linguaggi di alto livello, fare uso di astrazioni e costruire un’applicazione più complessa. Ma, allo stesso tempo, avremmo avuto delle vulnerabilità, non avremmo avuto un limite di tempo per le operazioni e spesso non avremmo avuto i driver migliori. Questo sarebbe stato inaccettabile: vendiamo sicurezza e affidabilità.
Perciò abbiamo scelto un sistema operativo in tempo reale (RTOS). Ci ha dato l’opportunità di creare un’applicazione al contempo multifunzionale e affidabile. I sistemi operativi in tempo reale sono utilizzati per gli ascensori, i freni delle autovetture e i missili balistici. Sono massimamente affidabili, poiché, se un meccanismo non funziona entro una rigida finestra di tempo, l’evento non avrebbe più alcun senso e avverrebbe una catastrofe. Questa è una differenza fondamentale tra RTOS e Linux, in cui le operazioni vengono messe in coda per l’esecuzione. Ed è questa una delle ragioni per cui Linux non viene utilizzato nei sistemi di sicurezza professionali.
Lo sviluppo ha richiesto un anno e mezzo. Abbiamo creato un OS che supporta protocolli avanzati di comunicazione in cloud su diversi canali. Gestisce una rete di centinaia di dispositivi radio. Può inviare messaggi di allarme tramite canali IP, comporre numeri telefonici e inviare SMS, tutto simultaneamente. Possiede tutte le capacità richieste dai sistemi di sicurezza professionali e protegge dagli attacchi. Pertanto, siamo stati in grado di raggiungere il nostro obiettivo iniziale. Abbiamo fornito funzionalità esaustive, assicurando al contempo l’elevata affidabilità.
Ma appena l’hub è stato lanciato, c’è stata un’ondata di richieste di nuove funzioni. Gli istituti di vigilanza ci hanno chiesto una connessione diretta all’hub, bypassando il nostro cloud. I nostri partner norvegesi volevano un rilevatore di incendio che fosse in grado di far scattare tutti i rilevatori di incendio di un sistema quando rilevasse un incendio e volevano che ciò avvenisse alla velocità degli allarmi antincendio cablati. Il mercato tedesco ha richiesto che il prodotto fosse conforme agli standard europei di Grado 2 e supportasse una tastiera del sistema di sicurezza. In Malesia e Danimarca, gli utenti volevano ampie capacità di automazione per le abitazioni. Per l’Italia era di grande importanza che gli impiantisti avessero un ruolo separato.
L’architettura esistente non ci consentiva una rapida espansione delle funzionalità. Potevamo aggiungere rapidamente funzioni alle applicazioni per smartphone poiché avevano ambienti di sviluppo di alto livello, ma programmare il software per l’hub richiedeva più tempo. Era difficile testare le modifiche e implementarle richiedeva troppe risorse. Per poter costruire una logica complessa, avevamo bisogno di un nuovo livello di astrazione, una separazione tra l’hardware e il software.
Dovevamo decidere come continuare a costruire il sistema. Avremmo dovuto passare a Linux? O affinare gradualmente il nostro OS? Dovevamo mantenere l’affidabilità e la stabilità del sistema operativo in tempo reale ma, allo stesso tempo, avevamo bisogno della scalabilità di un sistema operativo di alto livello come Linux. Ancora una volta, le soluzioni già pronte all’uso non facevano al caso nostro, quindi abbiamo dovuto trovarne un’altra da noi stessi.
La semplicità ha un valore solo se parte da una base di complessità
Alla base del nostro nuovo OS vi è l’idea della semplificazione. Abbiamo stabilito da soli le nostre condizioni: aggiungere funzioni non doveva complicare il sistema né ridurne la velocità di sviluppo. Per non perdere la rotta, abbiamo dato al progetto il nome in codice “Malevich”, in onore del famoso artista Kazimir Malevich nato a Kyiv. Il suo “Quadrato nero” è un vivido esempio di un’idea brillante basata su un’infinita semplicità.
Per poter creare OS Malevich, abbiamo dovuto cambiare tutto: l’architettura, l’approccio della programmazione, gli standard dei codici e del design, l’organizzazione del lavoro, l’ambiente di sviluppo. Sebbene il sistema operativo continuava a essere incentrato sul tempo di esecuzione dei processi, ha iniziato ad assumere alcuni tratti funzionali di Linux. Abbiamo implementato un meccanismo simile per l’assegnazione del tempo della CPU. Come risultato, il processore dell’hub utilizza un massimo del 20%, anche quando esegue compiti che richiedono elevate risorse. Inoltre, il sistema è divenuto modulare; le API standard vengono utilizzate per consentire l’interazione tra gli elementi. È facile lavorare per moduli, si identificano ed eliminano gli errori rapidamente ed è semplice aumentare le funzionalità e sperimentare per poter raggiungere l’efficienza ideale.
Impostiamo i prodotti Ajax in modo che siano uguali in termini di velocità di sviluppo. Possiamo implementare nuove funzioni per l’hub altrettanto velocemente che per il server e l’app. Non vi sono limitazioni tecniche alle nostre idee.
Processo di aggiornamento dell’hub
A oggi, un programma per computer non viene generalmente considerato un oggetto d’arte. La sua bellezza non è capita dalle masse. Ma abbiamo fiducia che, col tempo, le idee che abbiamo implementato diventeranno un classico dell’internet delle cose.
Leggete anche: