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

Negli ultimi anni, abbiamo condotto ampie consultazioni e formazione con team di sviluppo software durante lo sviluppo di firmware per prodotti e famiglie di prodotti di successo e duraturi. Mentre la creazione di un'architettura firmware robusta e la riprogettazione di software legacy possono essere un processo complesso, che dura mesi, abbiamo identificato cinque passaggi chiave che formano un approccio passo dopo passo, consentendo al nostro team di iniziare sulla strada giusta.

Fase 1: definire i requisiti

Prima che un sistema embedded o il suo firmware possano essere progettati, sono essenziali requisiti chiari. Requisiti ben definiti specificano cosa farà il prodotto per l'utente senza specificare in che modo saranno 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 l'adempimento. Un set di requisiti appropriato consiste in dichiarazioni che iniziano con "il [prodotto] dovrebbe...", concentrandosi 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

Abbiamo scoperto 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 stabilito. Richiede un'attenta considerazione degli usi previsti e consentiti del prodotto per garantire che venga eseguito correttamente.

La progettazione di un sistema rappresenta lo strato intermedio del come. Mentre l'architettura delinea le caratteristiche generali, non specifica i nomi delle funzioni o delle variabili. Un documento di progettazione del firmware riempie 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. Quando le interfacce sono chiaramente definite nella 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 negli ultimi tre passaggi.

Fase 3: Gestione del tempo

Alcuni requisiti di prodotto specificheranno vincoli di tempo espliciti. In genere, i prodotti includono una combinazione di requisiti non in tempo reale, soft-real-time e hard-real-time. Tra questi, le scadenze soft sono spesso le più difficili da definire chiaramente, testare e implementare. Una volta identificate le scadenze, il primo passo nel processo architettonico è scaricare quanti più requisiti sensibili al tempo possibile dal software all'hardware.

La separazione della 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. Rimuovendo i vincoli di tempo dalla maggior parte del codice, anche gli sviluppatori alle prime armi possono contribuire senza compromettere la sicurezza dell'utente. In secondo luogo, il consolidamento della funzionalità in tempo reale semplifica l'analisi e garantisce che tutte le scadenze siano costantemente rispettate.

Fase 4: Progettare tenendo a mente i test

È essenziale testare ogni sistema embedded a più livelli. In molti casi, testare a vari livelli non è solo prezioso, 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 incorporati in un cablaggio di prova progettato 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 individuo all'interno del dipartimento di ingegneria del software.

3. I test unitari garantiscono che i singoli componenti software, come definiti nella fase di progettazione intermedia, funzionino come previsto. Questi test si concentrano sull'API (Application Programming Interface) pubblica che il componente offre ad altri componenti. In genere, i test unitari sono sviluppati dagli stessi individui che scrivono il codice in fase di 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 dei test di integrazione e unitari, che richiedono una maggiore visibilità interna sul funzionamento del dispositivo. Per semplificare lo sviluppo, l'uso e la manutenzione dei test di integrazione e unitari, è consigliabile progettare il firmware in modo che sia allineato con un framework di test software. L'approccio più efficace è strutturare le interazioni tra tutti i componenti software ai livelli che si intende testare.

Fase 5: Prepararsi al cambiamento

Durante la fase di architettura del firmware, è essenziale dare priorità alla gestione della diversità delle funzionalità e alle personalizzazioni del prodotto. Per pianificare efficacemente il cambiamento, è fondamentale identificare prima i tipi di modifiche che probabilmente si verificheranno nel tuo prodotto. Quindi, il firmware dovrebbe essere progettato per accogliere queste modifiche nel modo più efficiente possibile. Un'architettura ben progettata consente la gestione della diversità delle funzionalità tramite una singola build con switch in fase di compilazione e/o in fase di esecuzione, consentendo anche l'aggiunta senza soluzione di continuità di nuove funzionalità senza interrompere le funzionalità esistenti.