Test del sistema operativo in tempo reale per durezza

Question

Ho un dispositivo incorporato (Technologic TS-7800) che pubblicizza funzionalità in tempo reale, ma non dice nulla su "duro" o "soft". Mentre aspetto una risposta dal produttore, ho pensato che non sarebbe stato male testare il sistema da solo.

Quali sono alcune procedure stabilite per determinare la 'durezza' di un particolare dispositivo rispetto al comportamento in tempo reale/deterministico (latenza e jitter)?

Essendo al college, ho accesso ad alcuni hardware piuttosto accurati (buoni oscilloscopi e generatori di segnale), quindi non credo che mi imbatterò in alcun problema in termini di apparecchiature di prova, solo per esperienza.

Answer 1

ho la stessa scheda di qui al lavoro. È un kernel 2.6 leggermente modificato, credo ... non la versione in tempo reale.

Non so di aver letto qualcosa nei documenti ancora che indica che è inteso per il lavoro RTOS rigoroso.

Answer 2

Con questo tipo di apparecchiatura, dovrebbe essere abbastanza facile sincronizzare l'o-scope a un clock costante, produrre un picco ogni volta che il sistema in tempo reale produce un'uscita, e vedere quanto tale picco varia dal centro . Minore è la variazione, maggiore è la durezza.

Answer 3

Per chiarire la risposta di Bob forse:

utilizzare il generatore di segnale per generare un impulso ad un certo frequenza variabile. La distribuzione casuale su un determinato intervallo sarebbe la migliore.

utilizzare il generatore di segnale (segnale di attivazione) per avviare l'oscilloscopio.

RTOS deve rispondere, fare qualcosa e inviare un impulso di uscita.

immettere l'uscita RTOS nell'ingresso 2 dell'oscilloscopio.

porta l'ambito in modalità persistente/raccolta. ottenere l'ambito per iniziare su A, fermarsi su B. se è possibile.

in un lavoro ideale, prendilo per misurare la distribuzione per te. Lo farebbe una LeCroy. Inizia con una traccia molto più lenta di quanto ti aspetteresti. Devi essere in grado di vedere i valori anomali lenti. Sarai in grado di vedere la distribuzione.
Assumendo una distribuzione normale, la SD della variazione del tempo di risposta è la SOFTNESS. (Questo non accadrà nella pratica, ma se non si ottengono valori anomali è ragionevolmente utile.) Se ci sono valori anomali di latenza grande, RTOS NON è molto difficile. Non soddisfa bene le scadenze. Non adatto quindi per il duro lavoro in tempo reale. Molte cose simili a RTOS hanno un buon margine sinistro sulla curva, inclinate verso il basso come una curva 1/f. Questo è indicativo di agitazione combinata. La cosa a cui prestare attenzione è il picco di risposta lenta all'estremità destra dell'oscilloscopio. Continua a ripetere l'esperimento con tracce più veloci se non ci sono valori anomali per ottenere una buona immagine della pendenza. Dovrebbe andare bene per alcune conclusioni speculative nel tuo articolo.

Se per la vostra applicazione, dire che un delta di 1uS è ok, e misurate 0,5us, è tutto a posto.

In ogni caso, è possibile pubblicare i risultati (e probabilmente nel pubblicare senso, ma certamente sul web.)

link da questa domanda per la carta quando hai scritto.

Answer 4

Capisco di essere geek, ma usando l'oscilloscopio per testare un computer con porte digitali ethernet/usb/other e lo stato interno ENORME (RAM) è sia inefficace che inaffidabile.

Invece di guardare le forme d'onda, è possibile collegare qualsiasi PC alla porta di uscita ed eseguire un'analisi statistica adeguata.

La procedura stabilita (se il segnale di ingresso è analogico per natura) è quello di testare il sistema contro diversi ingressi caratteristici - spikes tradizionalmente, funzioni a gradino e onde sinusoidali di frequenze diverse - e misurare sfasamento e varianza per ciascun tipo di ingresso. Il peggior caso viene quindi utilizzato nelle specifiche del sistema.

Anche in questo caso, se si utilizzano porte standard, è possibile generare facilmente quelle sul PC. Se l'input è veramente analogico, sarebbe necessario un DAC separato o semplicemente una buona scheda audio.

Ora, questo non dirà nulla sul fatto che il sistema operativo sia in tempo reale - potrebbe essere in esecuzione Linux vanilla o anche Win CE e comunque produrre risultati buoni e stabili in quei test se l'hardware è abbastanza veloce.

Quindi, è necessario simulare carichi pesanti e variabili su processore, memoria e tutte le porte, lasciarlo riscaldare e mangiare memoria per alcune ore, quindi ripetere i test. Se la latenza rimane costante, è difficile in tempo reale. Se non lo fa, sotto qualsiasi tipo di segnale di carico e ingresso, aumenta oltre il limite accettabile, è morbido. Altrimenti, è pubblicità.

P.S .: L'implicazione è che anche per i sistemi critici non è effettivamente necessario un tempo reale in tempo reale se si dispone di hardware.

Answer 5

Il tempo reale in tempo reale ha più a che fare con il funzionamento del software rispetto all'hardware. Quando si chiede se qualcosa è difficile in tempo reale, deve essere applicato al sistema completo (Hardware, RTOS e applicazione). Ciò significa che i problemi di progettazione del sistema in tempo reale sono complessi o complessi.

Sotto carico che supera la specifica anche un sistema in tempo reale non funzionerà (si spera con un'indicazione di guasto corretta) mentre un sistema in tempo reale morbido con carico basso darebbe risultati duri in tempo reale. Quanta elaborazione deve avvenire nel tempo e quanta pre/post elaborazione può essere eseguita è la vera chiave per hard/soft in tempo reale.

In alcune applicazioni in tempo reale la perdita di alcuni dati non è un fallimento, dovrebbe essere solo al di sotto di un certo livello, di nuovo un criterio di sistema.

È possibile generare input sulla scheda e fare in modo che una piccola applicazione li contenga e verificare a quale livello i dati andranno persi. Ma questo ti dà una valutazione specifica per quel sistema che esegue quell'applicazione. Non appena inizi a fare più elaborazioni, il tuo carico di calcolo aumenta e ora hai un diverso limite in tempo reale.

Questa scheda eseguirà un programma di pianificazione bare bone offrirà grandi prestazioni prevedibili in tempo reale per la maggior parte delle attività. Eseguendo un RTOS completo con un carico di calcolo pesante probabilmente si ottiene solo un soft in tempo reale.

Edit after comment
Il modo più efficace e più semplice che ho usato per misurare le prestazioni del mio software (a patto di utilizzare una cedolare) è quello di utilizzare un timer hardware corsa libera sulla tavola e in tanto timbrare il mio inizio e la fine del mio ciclo . Oppure se si esegue un timestamp pieno di RTOS l'acquisizione e la transizione. Salva il tuo tempo massimo ed esegui una media sui valori più di un secondo. Se la tua media è intorno al 50% e il tuo massimo è del 20% rispetto alla media, sei OK. Altrimenti è tempo di refactoring della tua applicazione. Man mano che la tua applicazione cresce, il tempo ciclo crescerà. È possibile monitorare l'effetto di tutte le modifiche apportate al software durante il ciclo.

Un altro modo è utilizzare un timer hardware per generare un interrupt ciclico. Se si è in tempo, resettare l'interruzione. Se si perde la scadenza, il gestore di interrupt segnala un errore.Questo tuttavia ti darà un avvertimento solo quando la tua applicazione impiegherà molto tempo, ma si baserà su hardware e interrupt per non lasciarti sfuggire.

Queste soluzioni eliminano anche il requisito di collegare un oscilloscopio per monitorare l'uscita poiché le informazioni sull'ora possono essere visualizzate in qualsiasi tipo di terminale da un'attività in background. Se è facile da monitorare, lo monitorerai regolarmente evitando di risolvere i problemi di temporizzazione alla fine ma non appena vengono introdotti.

Spero che questo aiuti

Answer 6

Penso che questo non sia un dispositivo in tempo reale, poiché non esegue RTOS.