Il vero punto di forza dei sistemi di informazione, oggi, è la condivisione dei dati tra i vari dispositivi, macchinari e device in genere. Ognuno di questi infatti possiede sensori propri, capaci di raccogliere le varie tipologie di dati utili ad un corretto e controllato utilizzo degli stessi. La tendenza tecnologica abbraccia sempre più il concetto della condivisione dei dati misurati, calcolati e letti dai sensori dai diversi dispositivi.
Un caso particolare di cui vorrei parlarvi in questo articolo, è rappresentato dalle nostre auto. La nostra auto, come ormai tutti i macchinari meccanici e termo-fluidodinamici, è un sistema complesso controllato da sistemi elettronici di retroazione positiva e negativa che permettono di monitorare e gestire le variabili in gioco in un sistema cosi complicato.
Ma se la nostra auto raccoglie con i propri sensori dati come posizione GPS, Velocità, Giri del motore, Livello e consumo del carburante, temperatura interna ed esterna, temperatura dei gas di scarico ecc., perché non leggere questi dati ed utilizzarli per propri scopi statistici o d’informazione?
Bene, quello che vorrei mostrarvi oggi, è il modo in cui la nostra auto gestisce questi dati e come sia possibile interfacciarsi con essa leggendo questi dati e addirittura scrivendoglieli!

Ogni singolo “blocco” dell’auto ha una propria gestione dei dati che invia agli altri blocchi, e dei dati che riceve da questi. Quando apriamo la porta della nostra auto, il sistema elettronico della porta rileva l’apertura ed invia questi dati al sistema elettronico principale dell’auto che a sua volta ci segnala sul display che la porta, esattamente la destra o la sinistra, risulta essere aperta. Questo sistema di comunicazione è lo stesso che avviene per ogni singola lampadina della nostra auto che da un momento all’altro potrebbe non funzionare più e che deve quindi essere monitorata dal sistema elettronico principale che ci potrà avvisare immediatamente del malfunzionamento. Ma è lo stesso sistema di comunicazione anche della pressione delle gomme, della temperatura dell’acqua, la temperatura dell’olio, i giri del motore, la velocità ecc ecc.
Questa enorme quantità di dati, viaggia nella nostra auto in un Bus che permette appunto di collegare ed interfacciare tra loro le diverse unità di controllo. Il protocollo seriale utilizzato nelle auto prende il nome di CAN-BUS ed è in uso dagli anni 80, principalmente nell’ambiente automotive. Essendo un protocollo seriale, si potrebbe pensare che i dati viaggino su di un unico “filo”, un unico conduttore. Questo, a causa dei “rumori” elettromagnetici presenti nell’auto, non è attuabile. Il protocollo CAN (Controller Area Network) è un protocollo che utilizza due conduttori (CanH e CanL, ovvero High e Low) attraverso cui viaggia quindi un segnale differenziale immune ai vari disturbi e rumori elettromagnetici.

Lo scopo di questo articolo è quello di capire come sia possibile leggere questi dati e soprattutto come differenziarli. Questi dati viaggiano infatti in maniera continua con una frequenza che va dai 100KHz, o i più comuni 500Khz e potrebbe arrivare ai MHz.
Una board di proto-tipizzazione come Arduino, che utilizza un micro-controllore della Atmel, è sufficiente con l’aiuto di un integrato ausiliario ad intercettare i dati del CAN-BUS. Lo schema generale è questo:

L’integrato ausiliario è l’MCP2515 che, in maniera autonoma, se collegato alla linea CAN-Bus, riesce a leggere i dati della linea differenziale.
Il protocollo è di tipo Master-Slave, ed ogni messaggio, mandato da un’unità nel bus, è identificato da un ID iniziale che associa il messaggio ad un particolare sensore o “blocco”. La comunicazione SPI tra Arduino e l’integrato MCP2515 permette la stampa dei valori letti direttamente sul monitor del nostro PC. In questo modo è facilmente interpretabile la lista di codici ottenuti.

La comunicazione SPI è di facile realizzazione con le librerie di default di Arduino. Per la comunicazione master-slave tra Arduino e l’MCP2515 invece bisogna utilizzare librerie di terze parti che implementano una comunicazione e una lettura dei dati ottimali. Il segnale differenziale reale è possibile vederlo ad un oscilloscopio che abbia ovviamente almeno due sonde e quindi input:

I segnali in giallo e azzurro sopra riportati sono quelli relativi ai conduttori CanH e CanL di un automobile, ed il segnale visibile in basso è invece il risultato della differenza dei due (in realtà c’è una logica di segnali dominanti e recessivi nell’operazione di differenza tra i due segnali).

La difficoltà nella decodifica del codice sta nel fatto che ovviamente ogni casa automobilistica utilizza un proprio codice identificativo a parità di sensore e quindi di significato dell’informazione trasportata dal codice stesso.

Nell’immagine soprastante è possibile vedere la struttura dei dati che viaggiano nel Can-Bus e il significato dei vari bit presenti all’interno dei dati stessi. Nell’immagine sottostante è possibile vedere invece un esempio di lettura dei dati che viaggiano in un Can-bus in un preciso istante:

Come si può intuire molti valori sono espressi nel sistema esadecimale e vanno semplicemente convertiti nel sistema decimale qualora si voglia una lettura immediata dei valori.

Ma quali fini potrebbe avere l’intercettazione e decodifica di questi dati?
Pensate ad un’azienda di trasporti merce o trasporti pubblici, che ha la possibilità di vedere sul proprio Software Gestionale, magari Microsoft Dynamics NAV 2017, quanto consumano i propri mezzi e quanti chilometri percorrono ogni giorno, al mese e quindi all’anno. Differenziare i consumi dei mezzi implica la possibilità di utilizzare algoritmi di scelta del mezzo relativamente ai chilometri da percorrere, e questo porta una minimizzazione dei consumi e quindi dei costi totali sostenuti dall’azienda.
Tra due pullman, uno dei quali riesce a fare 1 Km in più per ogni Litro di carburante rispetto all’altro, considerando un costo medio di 1,40 €/L del carburante, ci sarebbe una differenza di ben 2000€ annui considerando una tratta di 1000 Km al giorno e la capacità di far circa 14 Km/L del pullman che consuma meno. Inoltre se si volessero raccogliere anche i dati GPS del percorso effettuato dal pullman, non si avrebbe bisogno di ulteriori dispositivi di terze parti da acquistare per ogni pullman ma si potrebbero leggere i dati GPS che viaggiano nel CAN-BUS dei pullman che hanno ormai sistemi di navigazione propri e presenti al momento dell’acquisto degli stessi.

Ancora sarebbe possibile avere su NAV 2017 la situazione tecnica di ogni singolo veicolo, potendo avere informazioni anche in tempo reali del corretto funzionamento dei fari, motore, sistema di raffreddamento motore ecc, potendo dare un segnale d’allarme non appena uno dei valori non risultasse idoneo (immagine sopra).  Si potrebbe infine pensare come sarebbe opportuno conoscere lo stato dei fumi di scarico dei mezzi in questione per poter monitorare l’inquinamento e il corretto funzionamento dei sistemi di controllo delle polveri sottili.
Insomma, questo è solo un esempio di come l’elettronica e il sistema dell’informazione si stiano evolvendo, non dal punto di vista tecnico ma dal punto di vista concettuale, puntando sempre di più ad una macro-condivisione dei dati letti dai micro-sistemi.

Ing. Davide Arpa