Capitolo 2 La Software Communications Architecture (SCA) e il framework OSSIE

La Software Communications

Architecture (SCA) e il framework

OSSIE

La Software Defined Radio è una tecnologia senza nessun vincolo o specifica di progetto. E’ caratterizzata da una significativa componente software che ha il compito di fornire flessibilità al livello fisico. L’utilizzo di questa tecnologia in campo sia militare che civile è praticabile solo se viene definita un’architettura SDR comune e viene standardizzato un modello di progettazione.

L’architettura attualmente più completa e disponibile per la SDR è la Software Communications Architecture (SCA).

2.1 Caratteristiche generali di SCA

The Software Communication Architecture (SCA) è un'architettura aperta, non proprietaria, accettata a livello internazionale, sviluppata dal Joint Tactical Radio System (JTRS), un programma del Dipartimento della Difesa statunitense, a partire dagli anni ’90, per standardizzare e definire una Software Defined Radio [7].

Nasce proprio dall'esigenza di dover standardizzare un sistema SDR in quanto, quest’ultimo, essendo una tecnologia senza specifiche di progetto, porta

all'inconveniente di avere diverse architetture Software Defined Radio, sviluppate da produttori diversi che non risultano poi compatibili tra loro.

L'architettura SCA indica come gli elementi hardware e software devono operare all'interno di un sistema SDR e consiste in un insieme di vincoli progettuali che rimane indipendente dalla specifica implementazione ed è utile quindi come guida ai progettisti di Software Defined Radio.

Per cui, se uno sviluppatore progetta un sistema in base a queste regole, il sistema sarà compatibile con altre implementazioni SCA-SDR, indipendentemente da quale sistema operativo o hardware sia stato utilizzato.

Lo scopo dell’architettura SCA è quello di definire un operational environment (OE) o ambiente operativo che è composto da vari blocchi software, due dei quali fondamentali per l’intera architettura: il CORBA e il Core Framework (CF) che verrano analizzati nel dettaglio nei sottocapitoli successivi.

Gli obiettivi del programma JTRS quando iniziò a sviluppare l'architettura SCA furono:

• aumentare la flessibilità operativa e l’interoperabilità a livello globale dei sistemi implementati;

• possibilità di aggiornare in modo molto semplice i sistemi implementati; • riduzione dei costi di funzionamento.

Al fine di raggiungere tali obiettivi, SCA fu definita per:

• prevedere la compatibilità delle applicazioni software tra le diverse implementazioni SCA;

• introdurre norme a livello commerciale per ridurre i costi di sviluppo;

• ridurre i tempi di sviluppo di nuove waveform attraverso la possibilità di riutilizzare i moduli sviluppati a livello software.

Nell’ambiente SCA ogni applicazione radio viene denominata waveform. Una generica waveform è formata da un certo numero di componenti che sono entità

software che eseguono sul segnale una specifica funzione di signal processing o alcune funzionalità di controllo che sono richieste dalla waveform stessa.

Quest’ultima viene eseguita su una piattaforma hardware che in genere è costituita da un qualsiasi dispositivo d’elaborazione riprogrammabile, come ad esempio un processore general purpose, un DSP, una FPGA, un ASIC o un insieme di essi. Queste piattaforme possono essere modulari, ovvero possono essere aggiunti o tolti nuovi elementi di elaborazione.

Data l’eterogenea natura delle piattaforme SDR, è necessario un modello che definisca le funzioni del componente, tutte le interfacce previste da esso e i protocolli che utilizza per realizzare e gestire lo scambio di informazioni con gli altri componenti. Questo modello prende il nome di component model.

La waveform, e quindi tutti i suoi componenti, risiedono in una certa locazione della memoria di massa e il file system manager si occupa dell’organizzazione e dell’accesso a questa area di memoria.

Il meccanismo di comunicazione per lo scambio di informazioni, dati e controllo tra i componenti che compongono la waveform è svolto da un livello software detto middleware level. Questo livello è necessario anche per consentire ad ogni waveform di poter essere dislocata, senza cambiamenti sostanziali di logica, su un’altra piattaforma SCA.

L’elemento che tiene conto delle risorse disponibili e delle richieste delle piattaforme è il capacity model che permette anche alle diverse waveform di essere riconfigurate.

2.2 Il concetto base di “porta” di un componente SCA

Ogni componente di una waveform ha un insieme di porte ben definito. Quando viene configurata una porta è necessario specificare due importanti proprietà: ingresso o uscita e il tipo di porta. Una porta di ingresso può ricevere delle chiamate da remoto mentre una porta di uscita può inviare una richiesta, con procedura remota,

ai componenti alla quale è collegata. Una connessione può essere fatta solo tra una porta di ingresso e una di uscita dello stesso tipo, non è possibile connettere due porte di uscita o due porte di ingresso o porte di tipo diverso. La porta di ingresso rappresenta il lato server, che aspetta passivamente una chiamata remota dal lato client che la effettuerà attraverso una porta di uscita.

Un componente SCA può essere sia un client che un server o anche entrambi, dipenderà se quel componente deve inviare dati, riceverli o fare entrambe le operazioni.

Per il tipo della porta può essere usato un tipo standard come integer, floating point ecc… o anche crearne uno nuovo. Per far questo è necessario definire un nome per il nuovo tipo creato e le funzioni che questo rende disponibili.

Il tipo è definito in base al tipo di oggetto che deve essere passato attraverso quel collegamento. Tutto ciò viene fatto tramite l'Interface Description Language (IDL).

I principali vantaggi di utilizzare un insieme di interfacce standard sono:

• la possibilità di riutilizzare lo stesso componente su diverse piattaforme SCA;

• tutti i componenti comunicano attraverso il CORBA, ma possono essere implementati utilizzando linguaggi diversi, ad esempio Java, Pyton, C++ ecc…

Esistono anche altre due definizioni con le quali possono essere indicate le porte in SCA: use port e provide port. La porta use viene usata da un componente per richiedere dati o servizi ad un altro componente, mentre l'altra viene usata per trasmettere i dati o l'esecuzione del servizio richiesto da un certo componente. Secondo questo modello, un componente SCA assume il ruolo di un client CORBA quando effettua una chiamata attraverso una porta use e il ruolo di un server CORBA quando risponde attraverso una porta provide. Pertanto provide port è un sinonimo di porta di ingresso e use port è un sinonimo di porta di uscita [3].

2.3. La struttura base di SCA

La struttura base di una SDR basata su SCA è concettualmente composta di tre segmenti: Waveform Development, Core Framework e Domain Profile, come mostrato in Fig. 2.1.

Fig. 2.1 – Struttura base di SCA [3]

Waveform Development

Da un punto di vista fisico (Radio HW), una waveform utilizza alcune risorse hardware come il front-end RF disponibile su una daughterboard dell’USRP, il processore di un PC, un convertitore A/D ecc…

Nello sviluppo di una waveform, invece, tutto ciò viene nascosto al programmatore che implementa soltanto il livello logico (Components e Applications), generando e collegando fra loro i vari componenti che costituiranno la

waveform e che, essendo delle entità software, risultano indipendenti dalla piattaforma hardware specifica e quindi potranno essere riutilizzati anche su altri sistemi SDR.

In generale, grazie al livello di astrazione offerto dalla SCA, durante lo sviluppo di una waveform, il programmatore risulta poco influenzato dai dettagli tecnici della piattaforma hardware sottostante.

Core Framework

Il segmento Core Framework comprende tutto il software necessario per la gestione dell’intero sistema radio e lo sviluppo delle varie applicazioni.

Per quanto riguarda il livello fisico (Device Manager), fornisce una gestione di alto livello dei dispositivi fisici del sistema radio mentre la singola waveform “vede” soltanto il livello logico (Resouces + Domain Manager) che è un insieme di risorse e di servizi.

Nelle risorse ci sono i componenti disponibili per creare le varie waveform che possono essere indirizzati attraverso il Namig Service e gestiti dal File Manager.

Domain Profile

Il Domain Profile è costituito da un insieme di file scritti in Extensible Markup Language (XML) che descrivono, per quanto riguarda il livello fisico, le risorse hardware all’interno del sistema radio e per quanto riguarda, invece, il livello logico, le interfacce, i modelli di capacità, le proprietà, le interdipendenze, le interconnessioni e la posizione logica di ogni singolo componente che costituisce la waveform.

Il linguaggio XML1 è molto utilizzato in SCA, infatti le waveform sono generate tramite dei tool grafici e per far questo è necessario conoscere le proprietà

1 _{L'eXtensible Markup Language (XML) è un linguaggio di markup simile a HTML, basato su testo,}

del componente, l'insieme delle sue porte disponibili, configurarlo (per esempio impostando il guadagno di un amplificatore), e produrre il grafico di flusso corrispondente alla waveform stessa, in un formato standard che l'infrastruttura SCA può capire: tutto questo è fatto grazie all’ XML.

Tutti questi file XML vengono divisi in base alle loro funzionalità nel seguente elenco:

• Software Package Descriptor (SPD);

• Software Component Descriptor (SCD);

• Software Assembly Descriptor (SAD);

• Properties Descriptor (PRF);

• Device Package Descriptor (DPD);

• Device Configuration Descriptor (DCD).

I file SPD descrivono i componenti software e le loro implementazioni, mentre le interfacce fornite ed utilizzate da ogni componente sono descritte nei file SCD e un riferimento di questo file è incluso nel file SPD.

I file SAD descrivono completamente le waveform e includono una lista di tutti i componenti, le loro configurazioni e le connessioni tra di loro. Inoltre, per ogni componente della waveform, nel file SAD è contenuto un riferimento al file SPD.

I file PRF contengono le proprietà di ogni componente della waveform. Una proprietà è la rappresentazione di una caratteristica fisica o logica del componente. Esempi di proprietà fisiche sono il numero di serie, il tipo di processore e la capacità di allocazione.

Le caratteristiche della piattaforma sono contenute nei file DPD e DCD. Questi sono anche definiti come il Device Profile. I file DPD contengono anche dei

descrivere documenti e altre strutture di dati. E' estendibile perché non è un formato fisso come l'HTML che è un unico codice predefinito.

riferimenti ai file PRF, mentre i file DCD contengono una lista dei dispositivi allocati all’avvio del DeviceManager e l’informazione necessaria per localizzare il DomainManager.

Quindi ogni componente hardware viene descritto con un file DPD che ne rappresenta la parte hardware e un file SPD che ne rappresenta quella software.

La relazione tra i file che compongono il Domain Profile è rappresentata in Fig. 2.2.

Fig. 2.2 – Relazione tra i file del Domain Profile [7]

2.4 L’ambiente operativo (OE) di SCA

SCA definisce un ambiente operativo comune, operational environment, (OE) costituito principalmente dal Core Framework, il CORBA-ORB e il sistema operativo sottostante. L’OE garantisce che le waveform siano indipendenti da una successiva dislocazione sulla piattaforma e fornisce dei meccanismi comuni per l’implementazione delle applicazioni su più piattaforme con differenti componenti hardware, drivers di periferiche o meccanismi di trasporto.

L’OE, più precisamente il CF, definisce delle interfacce per la gestione e il controllo delle applicazioni e dei loro componenti, indipendentemente dalle particolari implementazioni. Tutto ciò sarà spiegato nel dettaglio nei sottocapitoli seguenti.

2.4.1 Il core di SCA: CORBA

The Common Object Request Broker Architecture (CORBA) è la dorsale di comunicazione all'interno della struttura software di SCA e fornisce uno scambio di informazioni trasparente attraverso le varie entità software. Fu scelto per la sua semplicità e perchè risulta indipendente dall'hardware sottostante; infatti una data applicazione può essere sviluppata su processori diversi, schede diverse o anche computer diversi facendo credere all'applicazione di essere eseguita su uno stesso hardware.

E' chiaro che CORBA aggiunge un livello di complessità in più all'intero sistema e, se non usato efficacemente, può diventare un peso per il sistema SDR, ma i benefici che apporta in termini di flessibilità e interoperabilità delle applicazioni distribuite superano di gran lunga questo inconveniente.

Il protocollo di trasporto che viene utilizzato dal CORBA è l'IIOP ( Internet Inter-ORB Protocol) che si affida al TCP/IP causando quindi dei ritardi che non sono deterministici e potrebbero essere anche non trascurabili. Per questo i progettisti ottimizzano il meccanismo del livello di trasporto inserendo delle modifiche alla versione di base, ottenendo come risultato che, se il CORBA viene usato efficacemente, causa solo dei piccoli ritardi rispetto al ritardo totale introdotto da tutta la SDR e quindi può essere tranquillamente tollerato.

CORBA permette ai progettisti di descrivere le interfacce tramite il linguaggio Interface Description Language (IDL), il quale permette di specificare le interfacce tra due componenti. Quindi un compilatore IDL genera il codice necessario per supportare le comunicazioni tra i componenti e lo fa generando degli “scheletri” per i

server e degli stub per i client, che vanno in esecuzione sopra un Object Request Broker (ORB) che fa da proxy sia per il server che per il client.

Utilizzando i compilatori IDL, è possibile generare gli stub e gli scheletri in diversi linguaggi: C, Java, Python ecc…, quindi ogni client e ogni server può essere scritto in un linguaggio diverso, ma possono comunicare comunque tra di loro attraverso delle chiamate di procedure remote che vengono effettuate attraverso l'ORB. Queste chiamate possono essere tra processi sullo stesso computer o anche tra processi su computer diversi.

La Fig. 2.3, mostra l’esempio di un client che effettua una richiesta ad un server tramite una chiamata di procedura remota.

Fig. 2.3 – Chiamata di procedura remota [3]

Una chiamata remota viene effettuata sempre dal client verso il server. Per effettuare tale chiamata il client ha bisogno di conoscere l'identificativo del server che

vuole chiamare. Ci sono diversi modi per farlo, uno di questi è utilizzare un servizio di denominazione, il Naming Service, che, come già detto precedentemente, fa parte del Domain Manager.

Il Naming Service permette ad un potenziale client di recuperare il riferimento dell’oggetto del server. La sua funzione base è quella di fornire una mappatura tra nomi e riferimenti agli oggetti. Per essere richiamabile, ogni oggetto server crea un associazione tra un nome e il suo oggetto di riferimento e registra queste informazioni con il Naming Service. Di conseguenza un client che conosce il nome di un oggetto del server può facilmente recuperarne il riferimento interrogando la Naming Service.

Per fare la richiesta al server, il client utilizza lo stub generato dal compilatore IDL attraverso lo scheletro di quel server. Tutte le comunicazioni necessarie per inoltrare la richiesta dallo stub del client allo scheletro del server, vengono gestite dall'ORB. Non è necessario che il client e il server siano connessi allo stesso ORB, può essere usato il General Inter-ORB Protocol (GIOP) per inoltrare la richiesta da un dominio all'altro.

La comunicazione attraverso i domini ORB rimane trasparente al client e al server, infatti per il client è sufficente conoscere l'identificativo del server, perchè tutto il resto è gestito appunto da GIOP.

A primo impatto sembrerebbe che l’overhead introdotto dal CORBA per le chiamate remote causi un ritardo di grandi dimensioni, come già annunciato ad inizio sottocapitolo.

Questo non è vero grazie alla progettazione di varie ottimizzazioni, in primo luogo quella sulle chiamate locali. Infatti i componenti di una waveform spesso vengono eseguiti sulla stessa piattaforma hardware in modo che sia possibile per l’ORB del CORBA gestire lo scambio delle richieste attraverso la memoria condivisa, piuttosto che attraverso la comunicazione tra i vari processi. Questo permette di poter effettuare delle ottimizzazioni sulle chiamate remote e quindi di eliminare gran parte dell’overhead che altrimenti sarebbe necessario.

2.4.2 Le interfacce del CF

SCA definisce nel CF un insieme di interfacce che gestiscono e regolano la distribuzione delle waveform e dei loro componenti. Ogni interfaccia definisce i metodi utilizzati dal Domain Profile per installare e controllare il componente [7].

Queste interfacce definiscono l’architettura e anche dei dettagli di basso livello del sistema, permettendo agli sviluppatori di concentrarsi solo sulle applicazioni.

Le interfacce incluse nel CF sono:

• Base Application Interfaces;

• Base Device Interfaces;

• Framework Control Interfaces;

• Framework Services Interfaces. Base Application Interfaces

In SCA, a tutti i componenti della waveform è richiesto di implementare le interfacce di base per le applicazioni.

L’elenco delle Base Application Interfaces è il seguente:

• Port; • PortSupplier; • LifeCycle; • PropertySet; • TestableObject; • Resource; • ResourceFactory. Port interface

Una waveform SCA è composta da vari componenti che comunicano tra loro attraverso le loro porte di ingresso e di uscita. Questi componenti ereditano le loro

porte grazie proprio all’interfaccia Port che fornisce due operazioni per impostare la comunicazione: connectPort() e disconnectPort().

Quando una waveform viene installata, tutti i collegamenti tra i componenti che la formano devono essere settati.

Per esempio, se si vuole stabilire una connessione tra la use port di un componente A e la provide port di un componente B, durante l’installazione della waveform, viene chiamata la funzione connectPort() sulla use port di A e la connessione con la provide port di B viene stabilita.

Questo viene fatto contattando il Naming Service fornito dal Domain Manager per recuperare il riferimento di B. Tutto questo viene fatto automaticamente dal framework SCA.

PortSupplier interface

Ogni componente ottiene le sue porte, di ingresso e di uscita, attraverso l’interfaccia PortSupplier che definisce l’operazione di getPort().

Questo è usato, per esempio, dalla funzione connectPort() per ottenere una porta specifica da un componente.

LifeCycle interface

L’interfaccia LifeCycle definisce due operazioni: initialize() e releaseObject(). La prima operazione viene utilizzata per impostare un componente ad uno stato iniziale noto, mentre releaseObject() disinstalla un componente quando quest’ultimo non è più necessario.

PropertySet interface

L’interfaccia PropertySet viene utilizzata per accedere alle proprietà e agli attributi dei componenti. Questa definisce due operazioni: configure() che rende possibile la configurazione del componente in runtime e query() che serve per leggere i valori delle proprietà del componente.

TestableObject interface

L’interfaccia TestableObject viene utilizzata dal programmatore per testare il funzionamento del componente, per esempio per ricercare gli eventuali errori presenti nel codice C del componente stesso.

Resource interface

L’interfaccia Resource è al livello più alto fra tutte le interfacce base per le applicazioni. Essa fornisce un’interfaccia comune per il controllo e la configurazione dei componenti software. Ogni componente software della waveform eredita l’interfaccia Resource, che a sua volta, eredita le funzioni necessarie delle altre interfacce come mostrato in Fig. 2.4.

L’interfaccia Resource, inoltre, fornisce due operazioni: start() e stop() che servono per avviare e interrompere un componente. Questi due metodi sono molto utili, per esempio, per avviare e interrompere il componente che genera il segnale.

ResourceFactory

L’interfaccia ResourceFactory è un’interfaccia opzionale che viene usata per creare ed abbattere l’interfaccia Resource.

Base Device Interfaces

Le interfacce di base relative ai dispositivi consentono l’interazione con il dispositivo hardware fornendo un proxy al resto del Framework SCA. Questa astrazione permette agli elementi che non sono CORBA-compliant di interagire con tutti gli altri componenti e con il resto del framework.

Le interfacce Base Device sono:

• Device;

• LoadableDevice;

• ExecutableDevice;

• AggregateDevice. Device interface

L’interfaccia Device fornisce una rappresentazione logica dei dispositivi hardware. Essa eredita le funzionalità dall’interfaccia Resource ma le estende per fornire la gestione dello stato e della capacità (allocazione e deallocazione della capacità).

Un ASIC o un pezzo di hardware dedicato è un tipico esempio di hardware fisico rappresentato da questa interfaccia.

LoadableDevice interface

L’interfaccia LoadableDevice estende le funzionalità dell’interfaccia Device. Essa serve, in runtime, per aumentare o diminuire la capacità del dispositivo fisico, modificandone quindi il comportamento. FPGA e DSP sono tipici esempi di componenti hardware rappresentati con questa interfaccia.

ExecutableDevice interface

L’interfaccia ExecutableDevice estende le funzionalità dell’interfaccia LoadableDevice consentendogli di eseguire e terminare le risorse.

Un tipico esempio di un dispositivo rappresentato da questa interfaccia è il GPP, anche se qualsiasi processore con funzionalità multithread può essere rappresentato da questa interfaccia.

AggregateDevice interface

L’interfaccia AggregateDevice viene utilizzata per rappresentare dispositivi compositi, cioè formati da più dispositivi logici, che vengono però presentati al dominio come una singola interfaccia.

Framework Control Interfaces

Le interfacce Framework Control forniscono al CF le funzionalità di gestione e di controllo su tutto il dominio. Le interfacce Framework Control sono:

• Application;

• ApplicationFactory;

• DeviceManager;

• DomainManager.

Queste interfacce permettono la distribuzione coerente, la configurazione e la gestione delle waveform e delle piattaforme.

Application interface

L’interfaccia Application fornisce un contenitore per tutte le risorse di una waveform permettendo la sua configurazione e le indagini di stato di ogni singola interfaccia. Questa interfaccia ha anche il compito di terminare l’applicazione rilasciando tutte le risorse utilizzate e restituendo le capacità allocate per ospitare dei dispositivi.

ApplicationFactory interface

L’interfaccia ApplicationFactory è utilizzata per creare le istanze di una specifica waveform. Essa ottiene le istruzioni di assemblaggio dal Domain Profile. Queste istruzioni includono l’elenco dei componenti che costituiscono la waveform, la loro locazione e le loro rispettive connessioni.

Questa interfaccia trova i Devices idonei basandosi sulla capacità disponibile, lancia i componenti, stabilisce le rispettive connessioni e ne esegue la configurazione iniziale e l’inizializzazione.

Dopo aver creato un’applicazione, l’ApplicationFactory ritorna con l’istanza dell’interfaccia Application.

La Fig. 2.5 fornisce una descrizione grafica semplificata del funzionamento dell’ApplicationFactory interface.

DeviceManager interface

L’interfaccia DeviceManager viene utilizzata per gestire un insieme di dispositivi logici e di servizi. Solitamente questa interfaccia rappresenta una board CORBA-compliant.

Quando viene istanziata, l’interfaccia DeviceManager crea un file system per la board che rappresenta e lancia tutti i dispositivi logici sotto il suo controllo. DeviceManager ottiene anche la locazione del DomainManager e si registra come parte del suo dominio.

DomainManager interface

L’interfaccia DomainManager gestisce e controlla lo stato generale di tutto il sistema radio. Questa crea un FileManager che contiene tutti i file system di ogni DeviceManager che è registrato sotto il suo dominio.

Quando instanziata, l’interfaccia DomainManager setta l’insieme dei nomi nel Naming Service del CORBA per tutto il sistema radio.

Domain Manager, inoltre, fornisce un’interfaccia di registrazione per tutte le interfacce del Framework Control e del Framework Services e gestisce l’accesso ai DeviceManager registrati e alla applicazioni installate. Fornisce infine anche un’interfaccia per l’utente.

Framework Services Interfaces

Le interfacce Framework Services vengono utilizzate per eseguire tutte le operazioni relative ai file.

Queste permettono di accedere ai file attraverso le piattaforme SCA e sono le seguenti:

• File;

• FileSystem;

File interface

L’interfaccia File consente l’accesso ai singoli file e alle operazioni di base che si possono effettuare su di essi come read, write, open, close ecc.. all’interno del dominio.

FileSystem interface

L’interfaccia FileSystem permette l’accesso remoto ai file system del livello fisico e le operazioni come creazione, cancellazione, copia ecc… di file. Tipicamente l’interfaccia FileSystem è limitata ad una parte di hardware o ad un singolo sistema operativo.

FileManager interface

L’interfaccia FileManager permette la gestione di varie interfacce FileSystem distribuite. Questa può essere vista come un file system di radice che monta e smonta gli altri file system.

Uno schema semplificato delle relazioni tra alcune interfacce descritte in questo capitolo è illustrato nella Fig. 2.6.

2.5 L’applicazione di SCA nel mondo accademico e commerciale

Una waveform SCA rappresenta un’applicazione radio distribuita, modulare, formata da vari componenti che costituiscono le risorse disponibili di SCA. L’ottimale granularità dipende dalle caratteristiche dell’applicazione e della piattaforma hardware dove la waveform viene implementata e dal trade-off tra la riutilizzabilità e l’overhead di cui l’architettura SCA necessita.

Grazie a SCA, i vari sviluppatori sono in grado di costruire dei sistemi SDR compatibili tra loro e possono utilizzare tutti i servizi forniti dall’operational environment, ma devono anche implementare in modo corretto le interfacce del Core Framework per garantire che tutti i componenti riescano a comunicare tra loro e a scambiarsi le informazioni necessarie. Per il corretto sviluppo di una waveform SCA, i programmatori devono costruire un modello di analisi della waveform (UML models and simulations), definire le interfacce IDL, gli stub e gli scheletri, sviluppare il processing che ogni componente deve effettuare e assemblare ogni componente tramite i file XML del Domain Profile. Anche se non è strettamente necessario seguire rigorosamente tutti questi passaggi, il procedimento esposto sopra facilita lo sviluppo, l’integrazione, il test e la documentazione della waveform da costruire.

Lo sviluppo di una waveform secondo l’architettura SCA presenta alcune difficoltà, per questo richiede tempo e un’accurata conoscenza del Core Framework. Fortunatamente sono disponibili, qualcuno a pagamento altri open source, dei tool di sviluppo che facilitano enormemente la costruzione di una waveform e dei suoi componenti come OSSIE, Spectra, Component Enabler ecc… OSSIE sarà descritto nel dettaglio nel sottocapitolo seguente.

L’ingresso di SCA nel mondo commerciale è un processo molto lento. Questo, in parte, è dovuto alla differenza dei requisiti generali e delle priorità dei due mondi. Infatti SCA è stata sviluppata per soddisfare dei requisiti specifici del Dipartimento della Difesa americano, offrendo particolare attenzione alla flessibilità, alla portabilità e all’interoperabilità, almeno a livello di waveform.

Quindi, sebbene molti dei principi di progettazione offrono caratteristiche interessanti anche in ambito commerciale, quest’ultime non ne rispecchiano però le priorità.

Per esempio, alla possibilità offerta da SCA di costruire una waveform distribuita su diverse piattaforme hardware non le viene assegnata la stessa importanza che viene data ai costi del sistema e al consumo di potenza nell’ambito commerciale. Infatti al momento, le società commerciali non sono disposte a scendere ad un compromesso tra le prestazioni, i costi del sistema e della potenza a favore di una maggiore flessibilità e portabilità offerte da SCA.

Questo però non vuol dire che gli enti commerciali non traggono vantaggio dal seguire un approccio di tipo SCA: ci sono molte caratteristiche dell’architettura SCA che gli enti commerciali sono in grado di implementare, di fatto sono attuate e che portano benifici tangibili per i loro modelli di business. La progettazione a moduli, l’uso di un framework locale, la distribuzione delle applicazioni basandosi su informazioni esterne ed un uso molto sostenuto del middleware, anche se non necessariamente il CORBA, sono procedure comuni di progettazione anche in ambito commerciale. Queste riducono molto i costi di sviluppo e agevolano molto la portabilità del test, la validazione e le attività di verifica.

Quindi, dato il fatto che SCA è un’architettura che continuamente si sviluppa, grazie ad una comunità di ingegneri del software che facilitano lo sviluppo delle SDR e migliorano continuamente due proprietà fondamentali di SCA come il riuso del software e la portabilità, è molto probabile che questa architettura, o un suo simile, abbia un forte impatto, in futuro, sul mondo commerciale.

Infatti, l’architettura SCA ha già fornito la base iniziale per la realizzazione di una Software Radio Specification (SRS) da parte della OMG, il cui obiettivo principale era quello di evolvere SCA in uno standard commerciale. Anche se quest’ultimo poi si è evoluto con delle significative differenze da SCA ne mantiene ancora gli stessi principi di base.

2.6 Open Source SCA Implementation Embedded (OSSIE)

La comunità di ricerca che ha sviluppato sistemi SDR, negli ultimi anni, ha avuto l’esigenza di implementare un’architettura SCA, open source, aperta ad eventuali modifiche, semplice da utilizzare e sviluppata in C++. Infatti SCA risulta essere un’architettura molto complessa che ha bisogno di una sua implementazione molto più semplice per poter essere utilizzata dalla maggior parte dei programmatori di SDR. Inoltre era altrettanto importante che questa implementazione fosse sviluppata in C++, il linguaggio più comune fra tutti gli ingegneri sia elettronici che delle telecomunicazioni [8].

I fatti sopra esposti hanno spinto i ricercatori del Virginia Tech a sviluppare un software per la prototipazione rapida delle SDR compatibile con l’architettura SCA: OSSIE (Open Source SCA Implementation Embedded).

OSSIE include un core framework, dei tool con interfaccia grafica per l’utente che sono molto semplici da imparare ed utilizzare e una libreria di componenti già creati che può essere continuamente ampliata. Questi tool permettono di costruire una waveform generando i componenti che la costituiscono, il codice di sorgente e i file di supporto di cui ogni componente ha bisogno, in modo automatico, secondo le specifiche di SCA, lasciando al programmatore il compito di specificare soltanto le caratteristiche basilari del componente e le funzionalità di elaborazione che deve effettuare sul segnale. Quindi diminuendo di molto la programmazione manuale riduce anche la possibilità di errori da parte del programmatore. Inoltre i tool permettono anche di verificare il funzionamento della waveform variando, in real time, il valore di certe proprietà dei componenti.

Il software sviluppato nel progetto OSSIE ha lo scopo di lavorare su piattaforme tipo personal computer o anche di tipo embedded ed essendo open source è liberamente disponibile via Internet. E’ possibile infatti scaricare sia l’infrastruttura software completa che gli strumenti di sviluppo e la libreria dei componenti già creati. Inoltre offre un buon supporto all’utente grazie alla guida e alla chat degli

utenti. Tutto questo fa parte dello scopo principale del progetto OSSIE: consentire la progettazione di sistemi SDR SCA-compliant per una vasta gamma di utenti.

2.6.1 I tool di sviluppo offerti da OSSIE

Il Waveform Workshop di OSSIE comprende un insieme di tool disponibili gratuitamente per lo sviluppo rapido, il testing e la configurazione in real time delle waveform SDR e dei suoi componenti [9].

Il primo tool, sviluppato da Virginia Tech, prende il nome di Waveform Developer (OWD) che è stato progettato per semplificare lo sviluppo di una waveform.

Questo tool fornisce un’interfaccia grafica per l’utente, graphical user interface (GUI), che permette ai programmatori di creare nuovi componenti software, grazie ad un editor con la creazione guidata e di effettuare graficamente le connessioni tra i componenti per sviluppare l’applicazione voluta. OWD genera gran parte del codice automaticamente e produce tutti quei file XML necessari per il corretto funzionamento della waveform e dei componenti.

Infatti, durante la creazione guidata di un generico componente, OWD genera automaticamente, in C++ e in Pyton, il codice sorgente che si occupa delle interazioni con il Core Framerwork e il CORBA di SCA. Al progettista rimane soltanto il compito di aggiungere, nel file ‘nome del componente.cpp’ le funzionalità di elaborazione che devono essere eseguite sul segnale d’ingresso e qualche modifica al file ‘nome del componente.h’. Il tool OWD è riportato in Fig. 2.7.

Gli sviluppatori di Science Applications International Corporation (SAIC) hanno contribuito, insieme a Virginia Tech, allo sviluppo del secondo tool, che prende il nome di ALF2, riportato in Fig. 2.8 e che viene utilizzato per la visualizzazione della waveform e come strumento di debugging.

Questo tool permette al programmatore di installare la waveform desiderata, di visualizzarla come schema a blocchi e fornisce all’utente la possibilità di monitorare il segnale, mediante degli strumenti che possono essere applicati alle porte di ogni componente, in un qualsiasi punto della waveform. Questi forniscono la costellazione dei simboli e lo spettro del segnale a quella data porta e sono stati sviluppati in Pyton. ALF contiene, inoltre, uno strumento che permette la connessione tra più applicazioni che sono in esecuzione contemporaneamente. Questo permette anche di sviluppare ulteriormente una waveform mentre i suoi componenti sono già in esecuzione, fornendo quindi un approccio ad un livello più alto per quanto riguarda la gestione delle applicazioni. Questo strumento si serve dei file XML per definire le connessioni tra le diverse applicazioni.

2

Fig. 2.8 – L’ALF di OSSIE

Con il supporto della U.S. Army Communications Electronics Research Development (CERDEC) questi due tool sono stati integrati dentro Eclipse. Eclipse è un ambiente di sviluppo open source che fornisce un’interfaccia utente con molte caratteristiche desiderabili agli sviluppatori software. Queste caratteristiche includono l’editing e il debugging del codice. Utilizzando OSSIE Eclipse Feature (OEF) è possibile creare componenti, sviluppare waveform, lanciare il Domain Manager, il Device Manager e l’ALF, tutto ciò all’interno dell’interfaccia grafica di Eclipse.

Con la sua creazione è stato anche sviluppato un tool aggiuntivo, che prende il nome di Waveform Dashboard (WaveDash), che sfrutta le funzionalità di SCA per fornire un’interfaccia grafica con la quale l’utente può controllare molto facilmente la waveform che è in esecuzione, configurando le proprietà dei componenti in real time.

Questo tool permette anche all’utente di scegliere quali proprietà far visualizzare e quali no e il tipo di controllo da utilizzare per ogni proprietà visualizzata. Questo permette all’utente di concentrarsi sullo sviluppo della waveform, sui componenti e le proprietà che richiedono la sua attenzione.

Il tool WaveDash è riportato in Fig. 2.9.

Fig. 2.9 – Waveform Dashboard (WaveDash)