Quando è nato il concetto di controllo programmabile e perché?

Lombello: Oggi, i controlli elettronici si distinguono tra parametrici e programmabili. I controlli parametrici sono controlli progettati per applicazioni verticali; ci sono moltissimi parametri tra i quali scegliere (anche più di 200) e i costruttori possono adattarli in maniera specifica per la propria applicazione. Ma è già tutto definito.
I controlli programmabili, invece, normalmente sono utilizzati per macchine più potenti, più complesse e più costose e permettono ai costruttori di unità di definire completamente le strategie di programmazione. Negli anni ’80 esistevano solo i controlli parametrici nel nostro settore.
Poi c’è stata una serie di intuizioni che hanno portato ad una forte visione innovativa che ha determinato il nostro successo. Non pensiate sia stato facile: i "visionari", quando si confrontavano con i tecnici, venivano considerati quasi dei pazzi, perché puntavano all’obiettivo incuranti delle difficoltà tecnologiche da affrontare.
E l’ostinazione a non mollare è stata la chiave del successo.

Bianchini: Visto che CAREL all’epoca aveva un unico cliente, volevamo uscire da questa situazione e cercavamo soluzioni innovative che ci permettessero di fornire più clienti senza aumentare il numero di progettisti necessari a soddisfare le esigenze dei singoli clienti.

Lombello: Il nostro principale cliente chiedeva controlli per macchine complesse progettati dagli ingegneri della CAREL, con competenze molto elevate, che lavoravano in Assembler, un linguaggio a livello codice macchina. Era necessario quindi un lavoro di molti mesi per scrivere il codice di programmazione, e succedeva spesso che, quando il programma era finito, bisognava ricominciare da capo perché nel frattempo erano cambiate le esigenze, ed erano cambiati i bisogni del cliente.
A quel punto, in CAREL, è nata l’intuizione di far programmare il controllo direttamente al cliente, il quale però inizialmente aveva competenze elettriche, meccaniche e termotecniche, ma sicuramente non informatiche. Abbiamo pensato, quindi, di fargli sviluppare il software usando un Cad che i clienti utilizzavano per progettare i quadri elettrici. Il "Cad software" che avevamo inventato permetteva di realizzare la regolazione della macchina mettendo assieme funzioni elementari che il cliente trovava in una libreria CAREL. Esattamente come era abituato a mettere insieme componenti elettromeccanici per realizzare un quadro elettrico.

Quali furono gli step operativi che hanno portato CAREL a sviluppare il primo software per controlli programmabili?

Bianchini: Abbiamo creato un ambiente di programmazione con oggetti software virtuali (anche se al tempo non sapevamo si chiamassero così) che il nostro cliente, elettrotecnico/meccanico, sapeva collegare perché già lo faceva in altri ambiti: questa è stata la base della programmazione iniziale.
Poiché le forze interne erano limitate, e a quel tempo eravamo in pochi, abbiamo iniziato a utilizzare strutture e componenti fatti da altri, come il CAD elettrico. Noi ci siamo limitati a sviluppare un programma che compilava i blocchi selezionati dal cliente e permetteva il debug. Era il 1988. Questo software si chiamava EasyTools e per alcuni anni è stato testato e utilizzato solo internamente. Poi, all’inizio degli anni ‘90, abbiamo cominciato a proporlo esternamente. Tutto ciò era davvero innovativo al tempo, ma la consapevolezza di ciò che stavamo facendo non era così chiara all'inizio, anche perché altrimenti lo avremmo brevettato.
Inoltre, ci eravamo dati un’ulteriore sfida: quella di rendere il software indipendente dall’hardware, ovvero si poteva spostare il software realizzato su controlli diversi, inseguendo l’evoluzione tecnologica; questo permette al cliente di mantenere il proprio investimento anche quando cambia il supporto hardware e questa sfida nella sfida non era una cosa banale all’epoca. Questo ha portato poi dei vantaggi notevolissimi sia a noi che ai clienti stessi.

Lombello: L'indipendenza dell'hardware, la semplicità dello sviluppo grazie al Cad che rendeva inutile le conoscenze di assembler, permettere addirittura che tutto ciò potesse essere fatto dal cliente anche se non era un programmatore: tutto questo, in quegli anni, era totalmente innovativo.

Cosa chiedeva il mercato? E cosa ha fatto CAREL per rispondere in modo efficace?

Lombello: Gli anni ‘80 sono stati anni di forte sviluppo della domanda di soluzioni elettroniche, anche nei settori nei quali lavorava CAREL, come il condizionamento per i centri di calcolo, per cui era quasi obbligatorio avere delle soluzioni che fossero non solo elettroniche ma a microprocessori. Tutte le aziende che operavano in quei settori sviluppavano un’infinità di prodotti custom e quindi ogni cliente aveva una soluzione disegnata ad hoc.
I nostri erano mercati verticali con volumi molto limitati e quindi un custom rischiava di essere implementato solo su un numero limitato di unità; c'era quindi il problema dei tempi di sviluppo, della verifica della qualità, e del ritorno di investimenti. L’Easy Tool permetteva di abbattere i tempi di sviluppo e aumentare la qualità visto che il software nasceva da elementi testati e resi disponibili in una libreria. Questo ci ha permesso anche di aumentare la capacità di fuoco, e quindi la capacità di sviluppare nuove soluzioni. Quando abbiamo iniziato a portare queste soluzioni fuori da CAREL, abbiamo dovuto aiutare e spingere il cliente a usarle sviluppando nuove competenze. Ed è stato allora, che Paolo Zama, Software Solution designer che ancora oggi si occupa di formazione, ha cominciato a fare i primi corsi ai clienti.
Abbiamo scoperto però che per i clienti avere un foglio bianco era un problema e quindi abbiamo cominciato a progettare degli standard. Il cliente, a quel punto, vedendo uno standard, capiva immediatamente cosa voleva tenere e cosa modificare.

Bianchini: Fondamentalmente la nostra strategia non è però mai stata quella di vendere i nostri software, ci siamo limitati a vendere delle licenze che in realtà erano il pagamento dei corsi di formazione.
Tornando ai controlli programmabili, bisogna sottolineare che erano la risposta alla domanda di differenziazione che arrivava dai costruttori di macchine.
I nostri clienti infatti appartenevano tutti allo stesso settore e le macchine rischiavano di essere simili: stesso compressore, stesso ventilatore e stesso controllo.

Lombello: La risposta di CAREL in merito alla differenziazione del controllo è stata quella di permettere una facile personalizzazione di quello che si vedeva: interfaccia utente e software. Tutto il resto, nascosto dentro il quadro elettrico e quindi "invisibile" al cliente finale, era standard. Questo ha permesso a CAREL di sviluppare economie di scala ed economie di scopo.
Un hardware comune permetteva di avere volumi elevati e quindi economie di scala e tutti i vantaggi che ne derivano, da standardizzare la produzione, a migliorare la qualità e ridurre l'incidenza dei costi, ecc. Poi abbiamo sviluppato anche economie di scopo, ovvero potevamo distribuire gli investimenti fatti per sviluppare nuovi hardware, sviluppare tool di programmazione, ecc., su più applicazioni grazie alla flessibilità del software.
In CAREL, siamo sempre stati esperti nella regolazione di sistemi che controllano circuiti frigoriferi e quindi potevamo spostare i nostri oggetti dalle applicazioni di refrigerazione industriale e refrigerazione commerciale, alle applicazioni di condizionamento industriale, commerciale e residenziale.

Come si è evoluta nel tempo la programmazione?

Lombello: CAREL, nel suo settore ha cambiato le dinamiche di mercato, cambiando i flussi e i ruoli dei diversi stakeholders. Ha infatti spostato la vendita dei sistemi di regolazione da un ambito tipicamente di installazione (gli installatori compravano, installavano e settavano i controlli) a quello della costruzione della macchine, ovvero agli OEM. Una volta, gli OEM erano assemblatori di componenti, soprattutto componenti elettromeccanici la cui regolazione veniva fatta poi sul campo. Avendo reso molto più semplice la programmazione della parte elettronica di controllo, gli OEM hanno potuto fare quello che si chiama integrazione a valle: hanno internalizzato la regolazione della macchina e quindi hanno potuto iniziare a fornire al mercato unità finite per cui l'installazione significava solo connettere la parte elettrica e quella idraulica. Lo sviluppo della tecnologia, con gli anni, ha dato ai controlli programmabili un altro grossissimo vantaggio. Un’unità di condizionamento degli anni ’80 era estremamente semplice ed estremamente "elettromeccanica". È vero che esisteva un controllo elettronico che la gestiva, però la componentistica era meccanica: il compressore on/off, le valvole meccaniche, i ventilatori on/off, ecc.
Poi, esattamente come è avvenuto nel settore automotive, i dispositivi sono diventati sempre più intelligenti, con prestazioni superiori, maggiore affidabilità, in grado di adattarsi a condizioni di lavoro diverse. Questo ha portato a una maggiore importanza del tool software che permette in modo semplice di installare e gestire dispositivi complessi. Un po’ come facciamo a casa quando colleghiamo una complessa stampante a colori semplicemente scaricando un driver software nel pc. La prossima evoluzione è legata al potenziamento dell’autodiagnostica e alla gestione predittiva dei guasti della macchina.
La strada è connettere sempre più unità, raccogliere dati, sviluppare algoritmi intelligenti. CAREL ha oggi circa un milione di unità in supervisione, di cui almeno 300.000 connesse al nostro cloud.

Il resto ve lo raccontiamo per i 100 anni.