EMB_85

EMBEDDED 85 • SETTEMBRE • 2022 64 SOFTWARE | HW DEBUG tori in una repository condivisa con il team a caden- ze temporali molto strette. Esistono parecchi server per CI adatti allo scopo tra cui Jenkins, GitLab, Te- amCity, CircleCI o GitHub Actions. Grazie a questa integrazione, è possibile attivare in modo rapido e automatizzato tutta una serie di passi – denominata pipeline – attraverso il software CI ospitato in house o sul cloud. Tale pipeline di solito include e abbina la compilazione (build), l’analisi statica e i test dell’unità e del sistema (Fig. 5). Il tradizionale debugger si trasforma quindi in un tool di test per i collaudi sull’hardware reale. Generalmente, anche il software può essere soggetto a test esaustivi su una piattaforma PC, indipendente- mente dall’hardware target. Nonostante ciò, non tutti i potenziali errori vengono rilevati negli ambienti simu- lati: a esempio le periferiche hardware richieste spesso non sono disponibili, oppure l’applicazione non si com- porta come sull’hardware reale, il comportamento delle temporizzazioni è differente, oppure il cross-compila- tore genera un codice oggetto specifico per il target che quindi non è lo stesso codice del compilatore utilizzato per l’ambiente di test. Da qui l’importanza di eseguire il test “il più vicino possibile“ all’hardware reale fin dalle fasi iniziali per assicurare il corretto funzionamento dei prodotti finali e l’esatto comportamento delle temporiz- zazioni dell’applicazione. Gli standard di sicurezza come ISO26262 e DO-178C hanno un’influenza sulle funzionalità dei tool e sulla fornitura di prove relative alla correttezza di queste funzioni agli utenti. In campo avionico, in particola- re, ai produttori di tool è stata richiesta da parecchio tempo la cooperazione per quanto riguarda la quali- ficazione dei tool, e lo stesso è avvenuto in tempi più recenti anche nell’industria automotive con l’introdu- zione dello standard ISO26262. A tal proposito, i pro- duttori di tool devono creare opzioni di verifica per la correttezza funzionale dei tool utilizzati in relazione a specifici casi d’uso. Queste possono essere misure di tipo organizzativo, come a esempio controlli da parte di Enti esterni dei processi di sviluppo o certificazio- ne dei tool da terze parti indipendenti, oppure tool di riferimento adeguati in grado di supportare l’utente nell’esecuzione delle prove di correttezza. I metodi appena sopra descritti per l’automazione delle pro- cedure di collaudo utilizzando i debugger si prestano particolarmente bene all‘implementazione di questi processi di qualificazione dei tool. Sempre più il debugger si sta trasformando in un tool di processo. Le funzioni base di un debugger vengono utilizzate per le normali applicazioni e sono completate da funzioni di analisi particolarmente ef- ficaci. La crescente complessità del software, il gran numero di tool software e hardware utilizzati per lo sviluppo del software stesso e le loro interdipendenze richiedono un trasferimento di conoscenze e servizi di consulenza tra produttori di tool, fornitori di chip e clienti. La chiave del successo è una comunicazio- ne continua e aperta tra tutte le parti coinvolte in questo proces- so di sviluppo. Già oggi gli utenti non vogliono più acquistare tool, ma utilizzarli quando e dove è necessario. Si stanno prepoten- temente affacciando alla ribalta nuovi modelli di business per lo sviluppo di software embedded e per il collaudo del software dove tool, trasferimento di conoscenze e servizi di consulenza si posso- no considerare come un prodotto condiviso, o in ultima analisi, un servizio. Come già accade nell’in- dustria del software, il modello basato sull’abbonamento è senza dubbio il più appropriato per lo sviluppo e il collaudo del softwa- re embedded. Fig. 5 – Schema della pipeline di un’infrastruttura CI (Continuous Integration) che evidenzia i vari step: build (compilazione), analisi statiche, test dell’unità, test del sistema e realizzazione di un prodotto pronto per l’introduzione sul mercato