L’uso della simulazione per massimizzare i vantaggi dell’integrazione continua

• 
• Tweet
• Pin It
• Condividi per email

Il ruolo del software nei sistemi embedded sta diventando più importante che mai. Esso fornisce opportunità di differenziazione competitiva e può accelerare e incrementare significativamente il fatturato. Tuttavia, spesso le aziende non sono disposte ad attendere uno o due anni perché arrivino nuovi software o aggiornamenti, pertanto vi è una crescente pressione affinché i rilasci diventino più frequenti. Il modo in cui lavorano gli sviluppatori si sta rapidamente evolvendo indipendentemente dal tipo di codice o di sistema in corso di realizzazione.

Fig. 1 – Il ciclo di vita di un prodotto e i test continuativi

Un’osservazione del mercato dimostra come nuovi approcci come lo sviluppo Agile, l’integrazione continua, il deployment continuo e i team interfunzionali siano sempre più diffusi nello sviluppo di software embedded. Lo sviluppo di sistemi embedded è chiaramente molto diverso dallo sviluppo di applicazioni Web o IT, e i target hardware non sempre si prestano all’adozione di queste nuove metodologie di lavoro.

La maggior parte delle sfide si può dividere in categorie relative all’accesso, alla collaborazione o all’automazione. Affrontiamo qui la prima di queste sfide: l’accesso, o la disponibilità dell’hardware richiesto per passare a un approccio di integrazione e test continuativi. L’integrazione continua è spesso considerata uno strumento utile per raggiungere la massima velocità nello sviluppo embedded. Sebbene possa generare molti vantaggi, l’integrazione continua può anche evidenziare limitazioni hardware che ne impediscono la perfetta implementazione.

Il ciclo di vita

A causa delle esigenze del mercato, il ciclo di vita tradizionale – design, sviluppo di piattaforma, sviluppo applicativo, test e integrazione, deployment e manutenzione – sta cambiando allo scopo di consentire un accesso maggiore. I test e l’integrazione sono ora attività svolte su base continuativa lungo tutto il ciclo di vita del prodotto, sia durante lo sviluppo sia successivamente al deployment quando il prodotto si trova nella fase di manutenzione (Fig. 1).

Fig. 2 – Tempistiche tipiche degli approcci continuativi

Nei prodotti installati sul campo viene aggiornato spesso anche il software, che viene pertanto collaudato e integrato costantemente con la conseguenza che la tradizionale fase di test e integrazione post-sviluppo sta cambiando e in alcuni casi persino scomparendo del tutto. Non è stata eliminata totalmente ma è stata in gran parte assorbita dalla QA (Quality Assurance), fase nella quale si tratta forse meno di effettuare test di base e integrazione quanto piuttosto accertarsi che i test appropriati vengano svolti prima di consegnare il prodotto.

In quest’area vi sono due punti di vista opposti: la qualità della produzione è parte del sistema di test e integrazione continua, processo di cui costituisce l’ultima fase con la conseguenza che l’obiettivo dell’integrazione continua è la qualità della produzione; in alternativa, esiste una fase QA dedicata che costituisce un’attività specifica basata su attrezzature specifiche e che avviene in modo separato e successivo rispetto al sistema di test e integrazione continua.

Il concetto

L’idea di base dell’approccio continuativo alle attività di test e integrazione comprende la possibilità di fornire un feedback più rapido agli sviluppatori, creare e collaudare un sistema un pezzo per volta evitando integrazioni massicce con conseguenti possibili malfunzionamenti di vasta portata, valutare la maggior parte dei cambiamenti, ridurre le attese prima di poter collaudare un sistema, scoprire gli errori nel contesto più piccolo possibile, e scoprire errori specifici a ciascun livello.

Fig. 3 – Il laboratorio di test hardware

Tutto questo è spesso difficile da raggiungere perché c’è un accesso limitato ai target hardware, spesso fragili e quasi sempre disponibili in quantità limitate, con la conseguenza di creare lunghe attese prima di poter condurre i test e, quindi, di aumentare i costi dei bugfix. Più tempo occorre per completare i test, più tempo occorre per ottenere feedback e tenere sotto controllo le regressioni, mentre utilizzare solo due livelli di test incrementa la possibilità che i bug presenti nei livelli intermedi passino inosservati (Fig. 2).

Ottenere una quantità sufficiente di target hardware può essere troppo costoso o poco pratico. Gli sviluppatori possono dover aspettare prima di accedere a un laboratorio di test o a un’apparecchiatura specifica, o magari devono attendere un risultato fornito da un laboratorio o perdere tempo a definire o modificare configurazioni una volta arrivati in laboratorio: tutto ciò provoca perdite di velocità, concentrazione e impulso. Il collo di bottiglia rappresentato dall’accesso causa anche l’impossibilità di scalare le attività di test e integrazione, e potrebbe creare problemi di qualità qualora la mancanza di accesso all’hardware obblighi gli sviluppatori a ridurre le matrici di test secondo quanto è possibile collaudare anziché secondo quanto dovrebbe essere collaudato. Questo può portare a successivi problemi di integrazione che potrebbero essere evitati mediante l’integrazione continua.

I laboratori hardware e software

Un tipico laboratorio hardware (mostrato in Fig. 3) comporta: un sistema da collaudare; un PC di provisioning che preleva il codice da un build server per programmare e pilotare il sistema; e un generatore di dati o un modello reale (un PC standard o hardware specializzato), il tutto coordinato da un server che svolge la funzione di test manager.

Il laboratorio di test hardware è essenziale per la QA finale: viene usato per collaudare quel che viene consegnato, e un simulatore non può sostituire questo hardware. Tuttavia vi sono alcune controindicazioni: difficile e costoso da mantenere, rappresenta una risorsa limitata per cui i test di integrazione vengono eseguiti meno frequentemente del dovuto; inoltre è molto difficile raggiungere un’automazione completa, vi sono poche configurazioni intermedie dal momento che l’hardware è tipicamente predisposto per test a livello di sistema o di unità e non per fasi intermedie, e infine richiede vari setup a livello di sottosistema che sono difficili da perfezionare. Per non parlare del fatto che i test sono definiti dall’hardware disponibile e non necessariamente da quel che gli sviluppatori vorrebbero idealmente collaudare.

Fig. 4 – Il laboratorio di test basato su simulazione

Durante una simulazione (Fig. 4), il sistema sotto test e il modello reale sono sostituiti da una simulazione mentre la parte di provisioning e servizio è rimpiazzata da funzioni di simulazione. Ciò trasforma l’intero laboratorio di test in un programma software che può essere eseguito su qualunque PC, incapsulato e condiviso; di fatto, trasforma un problema di gestione hardware in un problema di gestione software senza modificare i test.

La simulazione fornisce flessibilità: con un laboratorio simulato,qualsiasi PC può diventare un target a piacere, mentre il setup è semplicemente software. Questo significa che i test possono essere lanciati non appena disponibili; i target possono essere spostati immediatamente; i setup possono essere scalati facilmente verso l’alto e verso il basso come richiesto da ciascun passaggio di integrazione; è più facile mantenere i vecchi setup proprio perché adesso sono solamente software; ed è possibile gestire picchi su un particolare sistema evitando di dover disporre di risorse normalmente inutilizzate. Infine, aggiungere un setup è facile tanto quanto aggiungere un nuovo server.

La simulazione dell’ambiente circostante

Una simulazione che tenga conto dell’ambiente circostante con cui il sistema interagisce è particolarmente importante per i sistemi di controllo embedded e può essere ottenuta simulando il computer di controllo facendoci girare sopra l’intero stack software adottando il medesimo software del sistema reale (Fig. 5). Il software dialoga con dispositivi I/O simulati attraverso i normali driver, e i dispositivi I/O simulati dialogano a loro volta con una simulazione del sistema controllato. Questo è il sistema di cui il computer di controllo fa parte, e contiene simulatori degli attuatori e dei sensori necessari. Infine, questa simulazione del sistema si interfaccia con un modello dell’ambiente nel quale il sistema opera.

Fig. 5 – Costruzione di un sistema di simulazione integrato

Infatti possono esistere decine di sistemi e di modelli ambientali che interagiscono l’un l’altro e con il sistema simulato. In un tipico sistema meccanico, le simulazioni del sistema e dell’ambiente esistono già come parte di un workflow basato su un modello o su una simulazione. In un sistema di rete, il modello dell’ambiente tende a essere l’unico modello dal momento che non vi sono sistemi meccanici coinvolti.

Certamente la simulazione della scheda del computer di controllo è l’elemento più problematico per l’accesso, dal momento che tra le altre funzioni è necessario simulare componenti come il processore, i dispositivi di I/O, lo storage e le reti. Ma è facile aggiungere più schede nello stesso setup di simulazione, il che è una soluzione ideale per sistemi in rete, montati su rack e distribuiti. Il simulatore fornisce le funzioni di automazione necessarie per creare il laboratorio virtuale, che è ben più che solo hardware: è hardware sotto il controllo di una simulazione.

Eliminare le limitazioni

In generale la simulazione fornisce una soluzione più stabile, affidabile e flessibile. Arricchendo l’hardware fisico con un laboratorio di test basato su simulazione, è facile fornire agli sviluppatori i sistemi di cui hanno bisogno sia per test spontanei sia per test basati sull’integrazione continua. Si risparmia tempo perché non bisogna aspettare di poter accedere all’hardware, e le configurazioni e i setup disponibili sono accessibili immediatamente. Non vi sono limitazioni in termini di configurazioni di laboratorio, il che significa che gli sviluppatori possono fare i collaudi che realmente servono loro ottenendo un feedback più rapido. È anche possibile incrementare la qualità e la scala dei test senza obbligatoriamente aumentare anche i costi. Si riducono le emergenze e i bug dell’ultimo minuto, e progetti e prodotti possono essere consegnati puntualmente e nei budget.

Se l’accesso all’hardware fisico ha tradizionalmente avuto effetti sull’efficacia delle attività di test e integrazione svolte in via continuativa, una tecnologia come Simics può consentire nuovi approcci software fornendo accesso illimitato ai target e alti livelli di flessibilità quando si collauda e si integra il software dei sistemi embedded in modo continuo.

Jakob Engblom, product line manager for Simics; Eva Skoglund, senior marketing manager for Simics - Wind River

• 
• Tweet
• Pin It
• Condividi per email