Dalla sua emanazione il protocollo è stato soggetto di modifiche al fine di perfezionarlo, ma la necessità di raggiungere obbiettivi quali:
Veridicità della prova
-Garanzia che il veicolo da revisionare sia presente nell’officina;
-Garanzia che tutti i rilevamenti strumentali, previsti per il veicolo in esame, siano effettuati;
-Garanzia di un corretto utilizzo delle apparecchiature in ottemperanza a quanto previsto dalla nuova 88/95 e s.m.i.;
-Assegnazione di un esito e salvataggio dei dati parziali.
Sicurezza dei dati
-I file vengono creati solo dalle apparecchiature o dal PCStazione;
-La modifica dei file di misura viene rilevata dai nuovi applicativi di controllo;
-La creazione dei file da parte di entità non omologate viene rilevata dai nuovi applicativi di controllo.
Innovazione tecnologica
-Tempi di aggiornamento più rapidi per adeguarsi alle nuove normative;
-Automatizzazione degli aggiornamenti software atti alla semplificazione delle procedure e alla riduzione degli interventi di tecnici autorizzati;
-Istituzione di un portale presso il CSRPAD al fine di registrare tutti i soggetti abilitati ad effettuare, per ciascuna società, le verifiche primitive e periodiche delle attrezzature, ivi compresi i soggetti abilitati dall’Amministrazione;
-Obbligo di invio giornaliero dei referti elettronici delle prove;
-Codici antifalsificazione all’interno dei singoli file di prova;
-Dispositivo di acquisizione dell’immagine del veicolo (telecamera MCTCNet2) sottoposto a prova;
-Controllo via software che renda impossibile eseguire la revisione nel caso in cui le apparecchiature di revisione non siano in regola con le verifiche periodiche.

Tutte le ultime implementazioni richieste dall’amministrazione hanno richiesto non un semplice perfezionamento ma una sua più approfondita rivisitazione che ha portato alla nascita di MCTCNet2. Esso rappresenta il perfezionamento di un sistema assolutamente originale nel panorama comunitario, perseguendo l’obbiettivo di garantire una maggiore adeguatezza del controlli del parco circolante automobilistico e l’interesse legittimo dell’Amministrazione nella sua azione di vigilanza e controllo.

MCTCNet2 (versione 2.00) nasce quindi dalla necessità di migliorare i processi di revisione.
E’ errato pensare che sia stato studiato al solo fine di controllare l’operato dei centri di revisione, anzi l’obiettivo è ben più ampio. Si è trattato di analizzare l’attuale gestione dei centri al fine di introdurre dei criteri migliorativi per l’attività delle imprese. Un buon protocollo garantisce infatti la corretta esecuzione delle prove, introducendo la equità dei processi a prescindere dall’impresa o dalle attrezzature/software in uso.
MCTCNet2 è il frutto di anni di studio sulla base delle esperienze portate al tavolo di lavoro (GdL) presieduto dal Dipartimento dei Trasporti Terrestri al quale partecipano anche le Associazioni di categoria, i costruttori di attrezzatura e le software house.
La prima versione del nuovo protocollo nasce il 16 Ottobre del 2004 e trattava il solo aggiornamento dei file di scambio tra le attrezzature, il PCStazione e il PCPrenotazione.
Nel corso degli anni è diventato il documento unico in materia di informatizzazione dei centri di revisione.

Gli studi del GdL hanno prodotto MCTCNet2 i cui contenuti possono essere riassunti nei seguenti punti fondamentali:
-Perfezionamento dei protocolli di comunicazione
-Predisposizione al sincronismo dei dati con il CED
-Passaggio di responsabilità
-Garanzia delle tempistiche
-Presenza del veicolo o motoveicolo da revisionare
-Tracciabilità delle operazioni

E’ importante sottolineare che tutte le integrazioni sono state applicate nel rispetto delle attrezzature attualmente installate nel mercato (dedicate alle autovetture). Ciò significa che le attrezzature omologate MCTCNet versione 1.00 sono aggiornabili alla versione 2.00.
A seguire, cercheremo di descrive i contenuti di MCTCNet2 da un punto di vista non specificatamente tecnico, ma cercando di spiegare in modo sintetico ed esauriente i punti fondamentali.

1) Perfezionamento dei protocolli di comunicazione
Un protocollo di comunicazione è il metodo e il mezzo utilizzato per mettere in comunicazione due entità diverse. Già la prima versione di MCTCNet definiva il linguaggio di comunicazione tra differenti software presenti nella linea di revisione, tuttavia è risultato carente nella quantità di dati transitante in rete.

2) Integrazione di tutti i parametri del veicolo
Come noto, non era possibile trasmettere una serie di dati essenziali per la configurazione delle attrezzature, richiedendo un maggiore sforzo e impegno da parte dell’operatore nella ricerca e nella misura degli stessi. Si riportano alcuni esempi e gli effetti che tale mancanza ha causato:
-Giorno e mese di immatricolazione
Il responsabile tecnico aveva il compito di inserire il giorno e il mese di immatricolazione durante la prova di analisi dei gas, diversamente per i veicoli del 2002 non era possibile risalire ai limiti di riferimento corretti, in quanto prima del 01 Luglio si adottano i limiti Euro3 (0.5 al minimo e 0.3 al minimo accelerato) successivamente i limiti Euro4 (0.3 al minimo e 0.2 al minimo accelerato).
-Limite K per veicoli Diesel
A partire dalle omologazioni in ottemperanza alla legislatura comunitaria, i veicoli diesel sono dotati di una targhetta su cui è riportato il limite k massimo, oltre il quale in fase di revisione, viene assegnato un esito SOSPESO. La mancanza di questo dato nei file MCTCnet1 richiedeva, per ogni veicolo diesel, l’impegno del responsabile tecnico a ricercare la targhetta per poi inserire suddetto valore nel software di controllo dell’opacimetro
-Azionamento del freno di stazionamento
Non era nota la posizione dell’asse su cui agiva il freno di stazionamento, in particolare era impossibile identificare i casi in cui il freno di stazionamento agiva sull’albero di trasmissione (alcuni veicoli 4WD). Questo impediva al responsabile tecnico di seguire una corretta procedura di revisione, stimolando in buona sostanza una simulazione del freno di stazionamento con quello di servizio.
-Numero di giri massimi
Per i veicoli diesel, nel vecchio protocollo era richiesto erroneamente il numero di giri alla potenza massima, non utile e soprattutto non riscontrabile nei documenti del veicolo. Questo lasciava libero arbitrio all’operatore, il quale poteva si inserire un valore adeguato al tipo di veicolo, ma che poteva essere non idoneo.
Altri ancora…
-Numero di scarichi, Direttive di riferimento per le varie prove, numero dei fari (auto e moto,autorizzazione al traino, etc. etc.

In buona sostanza sono stati aggiunti tutti i parametri per poter identificare il tipo di veicolo da revisionare, permettendo il passaggio degli stessi dal PCPrenotazione alle attrezzature.
Una caratteristica di MCTCNet2 è quella di consentire le modifiche dei dati nominali del veicolo esclusivamente tramite il software del PCStazione, inibendo la possibilità di modificare i dati di prenotazione dai singoli moduli software delle attrezzature. Come nella vecchia versione di MCTCNet.

3) Integrazione dei tracciati di scambio dati per le moto
Mentre la versione 1.00 di MCTCNet integrava i tracciati per le sole categorie degli AUTOVEICOLI, la versione 2.00 introduce anche tutti i MOTOVEICOLI (2-3-4 ruote).
Il risultato è un protocollo completo che include tutti i dati delle prove strumentali previste per le categorie di veicoli autorizzate alle imprese.
Chiaramente questo comporterà per le imprese autorizzate alla revisione dei Motoveicoli un investimento maggiore di coloro che sono invece autorizzati per le sole Autovetture.

4) Integrazione tracciati per stazione barometrica
La stazione barometrica è lo strumento necessario per verificare che le prove strumentali siano espletate in condizioni atmosferiche idonee. Essa, pur essendo obbligatoria, non è soggetta ad omologazione né tanto meno richiede che venga collegata in rete al protocollo MCTCNet, come avviene invece per tutte le altre attrezzature.
MCTCNet2 prevede che tutti gli strumenti debbano obbligatoriamente acquisire i dati ambientali da un unico file comune, i cui valori dovranno essere azzerati una volta ogni ora dal PCStazione. E’ evidente che questo semplifica l’inserimento, concentrando in un unico file condiviso i dati, tuttavia non sarà più possibile inserirli una sola volta al mattino come accade oggi.

5) Integrazione dati rilevati da presa OBD
Sempre nell’ottica di velocizzare le procedure di revisione è stata prevista l’acquisizione dei giri motore e della temperatura attraverso la presa OBD.

6) Integrazione tracciati decelerometro
Come noto per i alcuni motoveicoli (quad) può essere necessario l’ausilio del decelerometro per il controllo dei freni. I presupposti che ne autorizzano l’uso sono riportati nella circ. 64/404 del 19 Gennaio 2005.
MCTCNet2 pur non integrando lo strumento decelerometro, permette l’inserimento dei dati misurati sul PCStazione. In questo modo saranno presenti nel file REV come se si fosse utilizzato il banco prova freni tradizionale (limitatamente ai valori che lo strumento misura).

7) Introduzione del LiveUpdate
Diventa un obbligo, per il costruttore e la software-house, implementare un meccanismo di aggiornamento automatico dei propri applicativi. Un eventuale aggiornamento software deve essere disponibile tramite internet e sarà facoltà dell’impresa di revisioni decidere se richiedere l’intervento di un tecnico o seguire le procedure di aggiornamento fornite dal produttore.

8) Predisposizione al sincronismo dei dati con il CED
Come noto, il CED ha migrato il sistema informativo sul portale dell’automobilista, consentendo l’accesso ai propri server tramite protocollo https (internet).
Questa importante migrazione consentirà di trasferire i file REV, generati al termine di ogni revisione, al sistema centrale del CED, permettendo così all’amministrazione di poter verificare la congruità dei dati misurati e trasmessi.

9)Passaggio di responsabilità
Tutte le attrezzature e i software presenti nel mercato sono omologati o approvati dal C.S.R.P.A.D. (Centro Superiore di Ricerca e Prove Autoveicoli e Dispositivi). Occorre precisare, quindi, che la conformità dei suddetti dispositivi è accertata tramite processi di verifica e prove molto stringenti, nel rispetto dei capitolati tecnici in vigore.
Le case costruttrici e le software house sono tenute ad implementare i diagrammi di flusso previsti dal nuovo capitolato di MCTCNet2, impedendo così un utilizzo fraudolento, o comunque non ottemperante alle disposizioni di legge, degli stessi dispositivi omologati. I diagrammi di flusso altro non sono che la sequenza dei singoli passaggi che portano alla conclusione una prova strumentale. Per meglio comprende cosa cambierà ai fini pratici si riportano due esempi:

-Analisi dei gas di scarico
La procedura prevista dalla circolare 8895 prevede una serie di obblighi:
*Verificare il test delle tenute ogni 24h
*Effettuare l’auto zero prima di ogni prova
*Verificare che gli HC residui siano al di sotto del massimo previsto per il tipo di veicolo da sottoporre a revisione
*Effettuare almeno 30 secondi di verifica per ogni condizione di regime motore richiesta per il veicolo in revisione (esempio: per i catalitici con doppia alimentazione è prevista la verifica dei gas al minimo e al minimo accelerato, sia per la prima che per la seconda alimentazione, quindi 4×30 secondi)
Non sarà facoltà, dell’ operatore, decidere se effettuare queste verifiche in quanto la responsabilità di ottemperare a queste disposizioni sarà in carico al costruttore a cui è stata riconosciuta l’omologazione dello strumento.

-Analisi opacimetrica
La prova opacimetrica prevede il raggiungimento del regime massimo di giri in un tempo non superiore ai 2 secondi. Ciò premesso dovranno essere le attrezzature a validare o meno la corretta esecuzione di un’accelerata, evitando in questo modo l’utilizzo non conforme dell’opacimetro.
Inoltre il numero dei giri massimo non potrà essere inferiore ai 3800 giri/min. Da tener presente che per i veicoli non in grado di raggiungere tale regime è sempre previsto l’inserimento manuale del valore.

In sostanza il costruttore e la software house saranno responsabili della sicurezza dei propri strumentie/o software, garantendo la conformità ai capitolati tecnici di riferimento per la determinazione dell’esito della prova.
A tutela dell’attività del responsabile tecnico e a garanzia dell’inviolabilità dei dati misurati, viene introdotto un livello di sicurezza informatico analogo a quello utilizzato dagli istituti bancari.
Ogni file prodotto da tutte le attrezzature (compreso il file prodotto dalla WebCam contenente la fotografia del veicolo) sarà firmato elettronicamente tramite criptazione RSA 1024.
La crittazione RSA è di tipo asimmetrico e prevede l’utilizzo di due chiavi, una pubblica nota a tutti e una privata nota solo al costruttore. La coppiaCertificato Prevenzione Incendi di chiavi è associata alla singola apparecchiatura e/o software e potrà essere cambiata dal produttore in un qualunque momento, se si ritiene che possa essere stata sottratta dall’azienda.
La firma posta al file permette al PCPrenotazione di verificare se esso è stato alterato, inibendo in questo caso l’importazione della prova. Le chiavi pubbliche saranno depositate in fase di omologazione e rese disponibili, on-line, ai PCPrenotazione approvati dal ministero e al CED per le verifiche di conformità dei file ricevuti.
In pratica si ottiene la certezza che i file prodotti dalle singole attrezzature siano garantiti dall’inviolabilità della crittazione RSA.
Un software non autentico avrebbe bisogno di codici noti solo al costruttore (che ne è responsabile) per creare un file ‘valido’.

10) Garanzia delle tempistiche
Sulla base di quanto chiarito al paragrafo precedente, è logico intuire che il tempo necessario per l’espletamento della fase di revisione non sarà più subordinato al singolo responsabile tecnico, né tantomeno all’attrezzatura in uso. Si riportano due esempi per comprendere meglio la precedente affermazione.
-Contagiri
Il contagiri è uno strumento accessorio dell’analizzatore dei gas, l’opacimetro e il fonometro.
Rimane inalterata la possibilità di utilizzarne uno integrato alle succitate attrezzature oppure, in alternativa o in ausilio, uno esterno. In ogni caso occorre puntualizzare che MCTCNet2 vincola i software che ne fanno uso di verificare che lo strumento sia collegato ed acceso. Non sarà infatti ammesso l’inserimento dei giri manuali, qualora lo strumento non sia collegato e non si sia tentato di rilevare i giri per almeno 20 secondi. Ciò premesso risulta evidente che l’inserimento manuale, in alternativa all’utilizzo del contagiri, comporterà un dispendio maggiore di tempo.
Inoltre sarà molto più veloce e semplice utilizzare un contagiri MCTCNet2 rispetto alla versione 1.00 in quanto è ammessa l’acquisizione tramite presa OBD.

-Centrafari
L’utilizzo corretto del centrafari richiede un’operazione ben definita che comprende lo spostamento dello stesso da un lato all’altro del veicolo, nonché il passaggio dalla posizione del proiettore da abbagliante a anabbagliante.
Queste operazioni manuali richiedono un tempo che è stato introdotto come attesa obbligatoria nel diagramma di flusso del centrafari. In pratica ai fini dell’ottenimento dell’omologazione sarà verificato che il costruttore abbia introdotto un ritardo tra la prova del faro Sx e del faro Dx di 30 secondi e tra la posizione Abbagliante e Anabbagliante di 20 secondi. Con queste premesse risulta evidente che la prova avrà una durata minima proporzionale al tempo necessario per svolgerla correttamente, a prescindere dal responsabile tecnico o dall’apparecchiatura in uso.

11) Presenza del veicolo o motoveicolo da revisionare
La necessità di introdurre un sistema informatico atto a garantire la presenza del veicolo all’interno del centro di revisioni, ha portato il GdL a definire una nuova apparecchiatura.
Con l’introduzione di un sistema in grado di riconoscere i caratteri della targa, analogo al Tutor presente sulla rete autostradale, si garantisce la presenza del veicolo, che esso sia sottoposto alla prova dei freni e che la stessa sia eseguita in conformità a quanto previsto dalla circolare 8895.
Tutte le categorie di veicoli e motoveicoli per i quali il centro di revisioni è autorizzato sono soggetti alla prova del riconoscimento targa.
Spesso è chiamato semplicemente WebCam, tuttavia occorre precisare che in questo caso l’hardware gioca un ruolo meno importante rispetto al software che elabora le immagini rilevate.
Per queste ragioni, tecnicamente è definito come sistema di Riconoscimento Targhe (RT). L’attività di RT è di sincronizzarsi al banco prova freni (a rulli o piastre è indifferente), al fine di scattare un’immagine al momento del raggiungimento di massima forza frenante, misurata sull’asse posteriore del veicolo. L’immagine sarà poi elaborata dal software che ne interpreta la targa e la confronta con quella inserita in fase di prenotazione. Il software sarà approvato dal Ministero dei Trasporti parimenti ad altri software e, come tale, dovrà produrre un file dei risultati chiamato AAnnnnnn.fot
Il succitato file conterrà, oltre ai dati nominali di RT, anche l’esito del riconoscimento e la fotografia scattata (salvata in formato Base64). Come previsto dal nuovo capitolato, anche il file FOT sarà firmato elettronicamente con le firme proprietarie del produttore.
La prova dei freni sarà sospesa (non sarà possibile portarla a termine) se il contenuto del file FOT riporta un esito IRREGOLARE. L’esito IRREGOLARE è assegnato quando 2 o più caratteri che compongono la targa non sono congrui con quella prenotata. Naturalmente, sarà possibile ripetere la prova dell’asse posteriore (freno di servizio) più volte, per poter permettere nuovamente a RT di rilevare la targa.
Il riconoscimento targa consente quindi il controllo della “validità” della targa, comportando la sostituzione della stessa nei casi in cui il livello di alterazione sia tale da renderla illeggibile.
A discrezione del centro, sarà possibile utilizzare un solo sistema RT anche in presenza di più banchi prova freni, chiaramente questo richiederà necessariamente lo spostamento e il posizionamento della stessa in corrispondenza della linea utilizzata in quel momento.

12) Tracciabilità delle operazioni
A differenza della versione 1.00, MCTCNet2 garantisce il mantenimento delle operazioni effettuate per ogni singola revisione. Il PCPrenotazione non potrà più eliminare una prenotazione avviata a revisione e diventa responsabile del mantenimento dei dati pervenuti dalle attrezzature. Una revisione interrotta per un qualsivoglia motivo rimane salvata nel computer e riportata nel registro giornale. Questo comporta necessariamente il rispetto di quanto già previsto dalla norma, che richiede la determinazione di un esito per il veicolo sottoposto a revisione entro la giornata.

Come si pùò capire, il nuovo protocollo MCTCNet2 ha portato notevoli cambiamenti soprattutto per coloro che sono abituati ad operare in modo superficiale. Importante sottolineare che, con l’avvio del nuovo sistema, non sarà possibile revisionare se anche solo una delle attrezzature non funzioni correttamente (ad es. in contagiri), questa valutazione va fatta durante la valutazione dell’aggiornamento del proprio centro revisioni al nuovo protocollo MCTCNet2, considerando magari di aggiungere alcuni strumenti per evitare dei blocchi di operatività future.