IL “JUKE BOX” DEI PROTOCOLLI.

EmuXP è stato progettato per essere un simulatore di protocolli di comunicazione, modulare e scalabile, in grado di gestire, come in un Juke Box, un insieme di librerie (anche già sviluppate) ognuna specifica per il particolare protocollo. L’integrazione di una nuova libreria di protocollo prevede modifiche minime al codice di EmuXP, a patto che la libreria stessa esponga le minime e necessarie API_[1] di interfaccia.

ARCHITETTURA DELL’EMULATORE EmuXP.

EmuXP è composto da due entità software: un Front-End (FE) ed un Back-End (BE) che rappresentano, rispettivamente, il cockpit di comando e il suo motore di esecuzione. Il primo, FE, implementa l’interfaccia grafica di comando (GUI_[2]) attraverso cui l’utente può controllare ogni dettaglio della simulazione, dalla gestione dei parametri di simulazione fino ad arrivare alla fase di post processing dei risultati raccolti). In Figura 1 è rappresentata la GUI di avvio principale di EmuXP.

[1] Application Protocol Interface

[2] Graphical User Interface

Il secondo, BE, integra le librerie di protocollo, gestisce la logica di funzionamento, la iniezione dei fault sui Layer di protocollo e implementa l’interfaccia verso il mezzo trasmissivo ovvero il protocollo di trasporto.

Il FE è stato sviluppato con le più consolidate tecnologie Web Oriented che conciliano velocità ed efficienza nel rendering grafico durante l’utilizzo a runtime anche in casi di workload (traffico) elevato.

Il BE è stato sviluppato con tecnologie, come descriveremo in dettaglio dopo, che garantiscono efficienza computazionale e tipicamente utilizzate anche in ambito embedded.

La soluzione ottenuta si propone come strumento scalabile e decentralizzato: più utenti possono collegarsi al medesimo BE, superando le limitazioni caratteristiche delle più vecchie soluzioni stand alone.

Il FrontEnd e il BackEnd comunicano tramite un protocollo che consente la comunicazione client (FE) / server (BE) in modo trasparente alla piattaforma cosicché l’applicativo può funzionare indipendentemente dalla piattaforma su cui è installato.

TECNOLOGIE.

Il FrontEnd è stato sviluppato attingendo a differenti tecnologie Web Oriented:

• Flask: framework leggero che fornisce gli strumenti per creare applicazioni web in python. I suoi vantaggi sono leggerezza, flessibilità, estensibilità, scalabilità caratteristiche ritenute imprescindibili per la tipologia di servizi che EmuXP è chiamato a soddisfare.

• Vue.js: framework progressivo utilizzato per la creazione di interfacce utente (UI). Le sue doti principali, sfruttate in EmuXP, sono: semplicità, User Interface reattiva, scalabilità dei componenti (riutilizzabilità), flessibilità e rendering ad alte performance anche in caso di mole di dati elevata da processare.

Il core del BackEnd è stato sviluppato in Python, che però si appoggia ad una tecnologia di supporto che offre non solo un boost significativo nelle prestazioni, fondamentale per EmuXP, ma al contempo permette l’integrazione di qualsiasi libreria di protocollo preesistente già sviluppata in C/C++ (in formato di libreria binario), col vincolo già citato di esporre le API per ciascuno dei Layer applicativi previsti.

ALCUNE FUNZIONALITÀ.

Vediamo di seguito una carrellata delle caratteristiche che contraddistinguono EmuXP dagli altri strumenti classici di simulazione.

SNIFFER CONTESTUALE

Che cosa significa Sniffer Contestuale?

Ogni test necessita di evidenze per potere determinare se è un test Fallito o Passato. Le evidenze sono tipicamente degli insiemi di LOG raccolti durante la simulazione, nella fattispecie messaggi in formato pcap_[3]. Questo di norma avviene utilizzando software come il noto Wireshark che permette di salvare il traffico di rete in diverse applicazioni. Questo Software di “sniffing” deve essere installato nella macchina (PC) di cui si devono possedere i diritti amministrativi.

EmuXP offre un approccio innovativo che si propone di rendere più agile il setting di test bench (ovvero un “banco da lavoro” per eseguire simulazioni/Test). Infatti, permette di catturare “contestualmente” tutto il traffico generato e ricevuto dall’emulatore EmuXP, che può anche essere visionato a runtime e opportunamente salvato per successive analisi di post processing.

La caratteristica disruptive dello sniffer contestuale di EmuXP è la possibilità di ritagliare, per ciascun protocollo simulato, i cosiddetti dissector (identificatori dei campi di protocollo) che, oltre a facilitare l’individuazione di porzioni specifiche all’interno dei messaggi, permettono di estrapolare dalla moltitudine di messaggi solamente quelli che soddisfano specifici requisiti che possono essere definiti dall’utente tramite l’impostazione di filtri con una classica sintassi ad operatori logici e binari (and, or, not etc etc) e qualche keyword. I Dissector, a differenza di altre soluzioni, possono essere definiti tramite GUI senza la necessità di procedere per via programmatica. Il vincolo, di nuovo, è avere la libreria di protocollo con esposizione di API.

In Figura 3 si veda a titolo di esempio un dissector creato per il protocollo PVS_[4] che permette di evidenziare, anche in funzionamento realtime, i campi Packet Type (Layer ALE), Msg Type (Layer SAI), Sequence Number ed Execution Cycle (Layer SAI), MTI (Layer SL) a ciascuno dei quali è associato un colore.

[3] Abbreviazione di Packet Capture. È l’estensione dei file ottenuti dalla cattura del traffico di rete, ovvero insieme di pacchetti dati scambiati tra i nodi che comunicano in rete

[4] Protocollo Vitale Standard, protocollo di comunicazione tra sistemi ideato da Rete Ferroviaria Italiana (RFI) basato sul Subset098 emesso da UNISIG per la comunicazione RBC-RBC in ERTMS.

I campi (insiemi di Byte o Bit) che rispondono ai criteri definiti dal dissector (Figura 4) vengono evidenziati, all’interno del messaggio, per corrispondenza di colore; nell’esempio il campo MsgType è definito di rosso, il campo EC in blu, e così via.

EmuXP consente la visualizzazione dei messaggi sia in byte che in bit agevolando la visualizzazione per l’utente che può così evitare azioni manuali inevitabilmente prone all’errore umano. In Figura 5 è rappresentato un esempio, sempre per il protocollo PVS, di campi valorizzati a Bit (esempio campo MTI, in viola, del Layer SL).

EmuXP permette, inoltre, l’export ed import dei dissector creati dall’utente che possono essere condivisi e resi fruibili ad altri utenti, per altre simulazioni: è possibile creare una propria libreria di dissector.

ERROR INJECTION

L’ Error Injection (EI) è una tecnica utilizzata per testare la robustezza e l’affidabilità di protocolli di comunicazione. Consiste nell’introdurre intenzionalmente degli errori, delle anomalie o delle condizioni avverse nelle simulazioni al fine di osservare come i protocolli di rete reagiscono.

Due tipologie di EI possono essere:

1. Introduzione di un ritardo nella trasmissione di un messaggio sulla rete (EI dinamico)
2. Corruzione di uno specifico campo di un messaggio (EI statico)

Per il caso 1 è possibile impostare un ritardo (Delay) in millisecondi dalla maschera utente (Figura 6), che consente, tramite un menu a tendina, di selezionare la tipologia di messaggio su cui applicare l’EI dinamico ed il numero di messaggi che si vogliono ritardare. Una volta applicato l’errore se ne può verificare l’effetto tramite lo Sniffer: il messaggio #94, evidenziato in Figura 7, ha subito il ritardo di 1s rispetto alla dinamica basale.

Per il caso 2 “estendiamo” il payload_[5] applicativo del messaggio aggiungendo 30 Bytes al valore definito con la maschera di caratterizzazione del EI, ovvero tutti al valore 0xFF. Si può osservare nella schermata dello Sniffer Contestuale che il messaggio #800 contiene 30 Bytes in più rispetto al messaggio #754, privo di error injection (evidenziati in Figura 8, si veda il campo ‘Actual Len’ dei messaggi). Tutti i bytes del payload sono impostati al valore 0xFF, come definito nel setting del EI. Questa è una scelta arbitraria del caso specifico, infatti l’emulatore EmuXP permette di definire capillarmente il valore per ogni singolo byte corrotto o aggiunto.

[5] Parte dati del messaggio.

LINGUAGGIO DI SCRIPTING

Nell’ottica di poter automatizzare e rendere ripetibili task o intere sessioni di test, sono state create due librerie di scripting che consentono all’utente di poter eseguire, programmaticamente, le medesime azioni eseguibili via GUI del FrontEnd.

Le due librerie sviluppate si posizionano su due livelli distinti nel flusso di esecuzione dell’utilizzo dell’emulatore: la prima coadiuva l’utente nel setup della simulazione (allestimento nodi, caricamento della configurazione) e nella esecuzione dei necessari error injection nonché nel contestuale salvataggio dei messaggi.

La seconda libreria, invece, permette il post processing dei log archiviati e di poter quindi eseguire le verifiche che determineranno se il test è Fallito o meno.

In Figura 9 si riporta un estratto per ciascuna delle due librerie: a sinistra l’esempio di utilizzo della libreria per l’esecuzione dei passi di test; a destra l’esempio di utilizzo della libreria per la verifica dei risultati attesi.

In sintesi, avere a disposizione una interfaccia programmatica permette all’utente di creare una completa sessione di test per uno specifico protocollo. I vantaggi in termini di risparmio di tempo sono immediati: la sessione di test, una volta creata, può essere esportata e riutilizzata as-is nel momento in cui mi trovo a dover ri-testare il medesimo protocollo di comunicazione.

Le competenze necessarie per poter utilizzare il linguaggio di scripting si limitano a conoscenze base della programmazione come l’utilizzo dei cicli e delle istruzioni condizionali rendendo tale strumento alla portata di tutti.

CONFIGURAZIONE DELL’EMULATORE EmuXP.

EmuXP, ovviamente, necessita di essere opportunamente configurato. Per poter spiegare in che cosa consiste la configurazione è necessario introdurre il concetto di “nodo di simulazione”.

Un nodo di simulazione è l’astrazione logica di un apparato di comunicazione che comunica con altri apparati utilizzando uno o più protocolli di comunicazione associando un flusso dati a ciascuno dei canali di comunicazione.

La configurazione dell’emulatore EmuXP prevede la definizione di:

• Nodi di comunicazione
• Canali di comunicazione
• Periodicità dei messaggi per ciascun canale
• Dimensione dei payload
• Tipologia dei protocolli applicativi

Per ciascun canale di comunicazione sono poi definiti i parametri caratteristici dello specifico protocollo quali, ad esempio:

• Parametri di connessione fisica (indirizzi IP, porte di rete ecc),
• Parametri della connessione applicativa (tolleranze di sicurezza, chiavi di cifratura ecc).

La configurazione viene generata attraverso il WizardXP, strumento dedicato ad EmuXP, che consente di progettare la rete di comunicazione da simulare.

Una volta progettata la rete di simulazione è possibile generare i file di configurazione che saranno poi utilizzati allo startup di EmuXP.

INSTALLAZIONE e LICENZE.

Abbiamo già accennato al vantaggio dell’accessibilità fornito dagli emulatori basati sul Web resi fruibili agli utenti direttamente da Browser del PC connesso all’interno della rete locale. Questo chiaramente implica che non è necessario installare sw specifico sulle macchine Front End degli utenti.

Come avviene quindi l’installazione dell’emulatore EmuXP? A fronte di una nuova release viene installato il SW di BackEnd di EmuXP sull’HW prescelto. L’attivazione della licenza di EmuXP richiede necessariamente che la macchina ospite sia connessa alla rete Internet.