Il nostro processo di sviluppo del firmware si basa su un approccio in cinque fasi

Negli ultimi anni, abbiamo condotto ampie consulenze e attività di formazione con i team di sviluppo software, sviluppando firmware per prodotti e famiglie di prodotti di successo e duraturi. Sebbene la creazione di un'architettura firmware robusta e la riprogettazione del software legacy possano essere un processo complesso, che può richiedere mesi, abbiamo identificato cinque passaggi chiave che costituiscono un approccio graduale, consentendo al nostro team di partire con il piede giusto.

Fase 1: definire i requisiti

Prima di poter progettare un sistema embedded o il suo firmware, è essenziale avere requisiti chiari. Requisiti ben definiti specificano cosa farà il prodotto per l'utente, senza specificare in dettaglio come verranno raggiunti questi obiettivi. È essenziale che ogni dichiarazione di requisito sia univoca e testabile. Una dichiarazione univoca è chiara e concisa e non richiede ulteriori spiegazioni.

La testabilità è un fattore chiave; un requisito ben scritto dovrebbe consentire la creazione di test semplici per verificarne il soddisfacimento. Un set di requisiti adeguato è costituito da affermazioni che iniziano con "il [prodotto] dovrebbe...", focalizzandosi su ciò che è necessario piuttosto che su come viene ottenuto, e garantendo chiarezza e testabilità. Di conseguenza, un'architettura efficace si basa su requisiti ben definiti.

Fase 2: distinguere tra architettura e design

La nostra esperienza ci ha insegnato che molti ingegneri e i loro manager hanno difficoltà a distinguere tra i vari aspetti dell'ingegneria del firmware. L'architettura di sistema rappresenta il livello più alto di "COME", definendo le caratteristiche durature del prodotto e rendendo difficile modificarlo una volta definito. Richiede un'attenta valutazione degli usi previsti e consentiti del prodotto per garantirne la corretta esecuzione.

La progettazione di un sistema rappresenta il livello intermedio del "come". Sebbene l'architettura ne descriva le caratteristiche generali, non specifica i nomi delle funzioni o delle variabili. Un documento di progettazione del firmware fornisce questi dettagli, inclusi i nomi delle attività e le responsabilità all'interno di specifici sottosistemi o driver di dispositivo, l'RTOS utilizzato (se presente) e le specifiche delle interfacce tra i sottosistemi.

La fase di implementazione rappresenta il livello più basso della gerarchia di gestione del progetto. Una volta definite chiaramente le interfacce in fase di progettazione, gli ingegneri possono iniziare a implementare i vari componenti in parallelo. Sebbene le sfide possano variare a seconda del settore, in genere rientrano in tre categorie principali: rispetto delle scadenze in tempo reale, test e gestione della diversità. Questi problemi vengono affrontati nelle tre fasi finali.

Fase 3: Gestione del tempo

Alcuni requisiti di prodotto specificano vincoli temporali espliciti. In genere, i prodotti includono una combinazione di requisiti non-real-time, soft-real-time e hard-real-time. Tra questi, le scadenze soft sono spesso le più difficili da definire, testare e implementare in modo chiaro. Una volta identificate le scadenze, il primo passo del processo architetturale consiste nello scaricare il maggior numero possibile di requisiti urgenti dal software all'hardware.

La separazione delle funzionalità in tempo reale dal software principale offre due vantaggi chiave. In primo luogo, semplifica la progettazione e l'implementazione del software non in tempo reale. Eliminando i vincoli temporali dalla maggior parte del codice, anche gli sviluppatori alle prime armi possono contribuire senza compromettere la sicurezza degli utenti. In secondo luogo, il consolidamento delle funzionalità in tempo reale semplifica l'analisi e garantisce il rispetto coerente di tutte le scadenze.

Fase 4: Progettare tenendo a mente i test

È essenziale testare ogni sistema embedded a più livelli. In molti casi, testare a più livelli non è solo utile, ma anche obbligatorio.

I livelli di test più comuni includono

1. I test di sistema hanno confermato che il prodotto nel suo complesso soddisfa o supera i requisiti specificati. Si raccomanda che questi test siano sviluppati al di fuori del reparto di ingegneria, sebbene possano essere integrati in un'attrezzatura di prova progettata dagli ingegneri.

2. I test di integrazione vengono condotti per garantire che i sottoinsiemi dei sottosistemi, come delineato nei diagrammi di architettura, interagiscano correttamente e producano i risultati attesi. Questi test sono in genere sviluppati da un team di test o da un singolo individuo all'interno del reparto di ingegneria del software.

3. I test unitari garantiscono che i singoli componenti software, definiti nella fase di progettazione intermedia, funzionino come previsto. Questi test si concentrano sull'API (Application Programming Interface) pubblica che il componente mette a disposizione degli altri componenti. In genere, i test unitari sono sviluppati dalle stesse persone che scrivono il codice sottoposto a test.

Dei tre tipi di test, i test di sistema sono i più semplici da sviluppare. Un test harness potrebbe essere necessario per i test di ingegneria e di accettazione in fabbrica, ma questo processo è generalmente più semplice rispetto ai test di integrazione e unitari, che richiedono una maggiore visibilità interna sul funzionamento del dispositivo. Per semplificare lo sviluppo, l'utilizzo e la manutenzione dei test di integrazione e unitari, è consigliabile progettare il firmware in modo che sia allineato a un framework di test software. L'approccio più efficace consiste nel strutturare le interazioni tra tutti i componenti software ai livelli che si intende testare.

Fase 5: Prepararsi al cambiamento

Durante la fase di progettazione dell'architettura del firmware, è essenziale dare priorità alla gestione della diversità delle funzionalità e alle personalizzazioni del prodotto. Per pianificare efficacemente il cambiamento, è fondamentale identificare innanzitutto i tipi di modifiche che potrebbero verificarsi nel prodotto. Successivamente, il firmware dovrebbe essere progettato per adattarsi a queste modifiche nel modo più efficiente possibile. Un'architettura ben progettata consente la gestione della diversità delle funzionalità tramite un'unica build con switch in fase di compilazione e/o in fase di esecuzione, consentendo al contempo l'aggiunta di nuove funzionalità senza interruzioni rispetto a quelle esistenti.