Un RTOS richiede una progettazione esplicita delle responsabilità, non soltanto la creazione di task. Si analizzano eventi, periodicità, priorità e sezioni critiche per evitare che comunicazione, interfaccia e acquisizione si blocchino a vicenda. Le scelte vengono verificate sul carico e sulla piattaforma effettivi.
Attività e verifiche
Definizione di task, code, notifiche, mutex e proprietà dei dati condivisi.
Analisi di stack, heap, watchdog, inversione di priorità e percorsi di errore.
Prove di latenza, jitter e carico durante traffico intenso, timeout e guasti delle periferiche.
Scelte iniziali e integrazione
Raccolgo deadline, frequenze degli eventi, priorità funzionali e carichi concorrenti. La scelta del kernel segue hardware, codice esistente e processi del team. Verifico anche come interrupt, driver e librerie condividono dati e risorse: il timing dipende dall’intera catena.
Un esempio di verifica
Uno scenario utile combina acquisizione periodica, traffico di comunicazione e una periferica lenta. Si osservano ritardi, utilizzo dello stack, blocchi e watchdog nelle condizioni definite. Le misure sul banco aiutano la verifica, ma non dimostrano da sole il comportamento in ogni possibile stato.
Consegne e criteri di accettazione
Architettura dei task, configurazione del kernel, sorgenti e report delle misure. Deadline e carichi di prova vengono concordati: l’uso di un RTOS da solo non dimostra il rispetto del requisito real-time.
Da cosa partire
Servono piattaforma hardware, toolchain, frequenze degli eventi e tempi massimi accettabili per le funzioni critiche.
Avere un RTOS rende automaticamente il sistema real-time?
Le deadline richiedono architettura, priorità e percorsi di esecuzione coerenti, oltre a verifiche sul carico previsto. Il kernel è uno dei componenti del sistema.
SLX OrbitLab integra F Prime, Basilisk, un core C++ proprietario e una console Qt per pianificare missioni satellitari, gestire energia e dati e sviluppare firmware embedded con RTEMS e Renode.