EMB_77

EMBEDDED SETTEMBRE 58 SOFTWARE | MULTI-CORE RTOS i costi per la sostenibilità e i relativi rischi diven- # À - ! À WCET per tutte le applicazioni integrate. L’approccio migliore è avere un sistema operativo À ! in base alla disponibilità di meccanismi di esecu- zione, librerie e strumenti con livello di garanzia (DAL) A che tengono conto degli obiettivi CAST- 32A. Questo approccio fornisce all’integratore di ! À Á # " À ! - ! À À eliminare il lock-in. Utilizzo efficace delle risorse multicore Per ottenere i vantaggi delle soluzioni multicore in termini di throughput e di SWaP (Size, Weight and Power), l’architettura software deve consen- tire un’elevata utilizzazione dei core disponibili. Tutte le funzionalità multicore devono essere supportate, dall’abilitazione del funzionamento simultaneo dei core (rispetto alla situazione in cui core disponibili sono costretti ad uno stato inattivo o mantenuti in reset all’avvio) alla for- nitura di un meccanismo per il bilanciamento de- # 2 ' Á - - tura multiprocessing del software, più strumenti l’architetto di sistema avrà per ottenere un’eleva- ta utilizzazione. Architetture software di multi-processing Come i sistemi multi-processore, l’architettura software sui processori multicore può essere clas- À core accedono alla memoria e in base al fatto che ciascun processore o core esegua o meno la pro- pria copia del sistema operativo. L’architettura software più semplice per un sistema multicore è il multiprocessing asimmetrico (Asymmetric Multi-Processing, AMP), in cui ogni core viene attivato in modo indipendente, ciascuno con il proprio sistema operativo o un sistema operati- vo guest come guest di un hypervisor. Ogni core esegue un’applicazione diversa con poca o nessu- ! À in termini di schedulazione. Questo disaccoppia- mento può causare una sottoutilizzazione delle risorse disponibili, a causa della mancanza di bi- À la contesa delle risorse condivise e dell’incapacità di eseguire attività coordinate tra i core, come ri- chiesto in un test integrato completo. La moderna alternativa è il Symmetric Multi- Processing (SMP), in cui un singolo sistema ope- rativo controlla tutte le risorse, inclusi i dati di quali thread applicativi vengono eseguiti e su quali core. Questa architettura è facile da pro- grammare perché tutti i core accedono alle risor- se “simmetricamente”, lasciando libero il sistema operativo di assegnare qualunque thread a qua- lunque core. Non sapere quali thread saranno in esecuzione su quali core è però un problema serio e un ri- schio per il funzionamento deterministico dei sistemi critici. Per risolvere questo problema, il CAST-32A fa riferimento all’uso del BMP (Bound Multi-Processing). BMP è una forma migliorata e ristretta di SMP che lega staticamente le attività di un’applica- ! À di sistema di controllare da vicino l’operazio- ne simultanea di più core. Il BMP segue diret- tamente il requisito multicore dell’ARINC 653 Supplemento 4 paragrafo 2.2.1, che parla di “più processi all’interno di una partizione schedulati per un’esecuzione simultanea su diversi core del # % @ À permettere ad un’applicazione multithread di es- sere eseguita su più core in parallelo. Esempio di un RTOS Multicore per la certificazione di sicurezza INTEGRITY-178 tuMP di Green Hills è un si- stema operativo in tempo reale (RTOS) multicore À ! 2 " 2 A 2# 2 8 À Multi-Processing) dell’RTOS offre la massima Á ! - zazione di applicazioni safety-critical e security- critical su un’architettura multicore. Prevede ini- zialmente che un kernel partizionato nel tempo, che ha il controllo di tutti i core, consenta a qual- siasi combinazione di applicazioni AMP, SMP e BMP di essere associata a un core o gruppi di À  # 3 # „ aggiunge una varianza temporale in modo che le À ! essere allineate tra i core.