SOFTWARE/OS FreeRTOS af threads viser igen en inverteret prioritering af opgaverne. Bedre tests af multithreaded software For at forbedre kvaliteten af multithreaded software skal der mere til end bare at forøge mængden af test. For det første skal man sikre sig, at softwaren i det hele taget kan testes, altså om det samme input altid leve- rer det samme resultat på sy- stemniveau uanset software- timingen. Den bedste måde at opnå disse testresultater på er at følge best-practices for mul- tithreadede softwaredesigns. Det er et omfattende emne, men nogle af de eksempler, som først dukker op er: • I periodiske threads bør man bruge en sund metode til as- signment af RTOS scheduling prioriteterne, som rate-mono- tonisk scheduling, hvor den hyppigste task bliver assigned til den højeste scheduling prio- ritet. • Hold interrupt-handlers så korte og deterministiske som muligt. I stedet for at køre al event-håndteringskode inden for interrupt-handleren, så delegér i stedet disse jobs til threads med lavere prioritet. • Kode med lange eksekve- ringstider – eller med store variationer i eksekveringstiden – bør køres med så lav schedu- ling prioritet som muligt, ideelt med den allerlaveste schedu- ling prioritet. • Delte ressourcer skal tilgås på en sikker måde uden risici for race conditions, prioriterings- inversion eller deadlocks. Det anbefales typisk at beskytte kritiske sektioner med brug af mutex-objekter, der supporte- rer nedarvede prioriteringer. Ved at sikre et solidt software- design i forhold til multithrea- ding vil man opnå en mere stabil, deterministisk system- behaviour, der forbedrer test- dækningen på systemniveau uden at føre til flere testforløb. Det minimerer risici for skjulte bugs, der måtte have gemt sig i produktionskoden. Verificering af real-time krav Embedded software er ofte real-time systemer med mere eller mindre eksplicitte krav til software-timingen. Et sty- ringssystem kan for eksempel stille krav om at give output- styringssignaler til en motor- controller hver fem millisekun- der, og enhver yderligere delay bliver anset som en fejl. Disse krav bliver ikke kun på- virket af eksekveringstiden for en specifik thread, men er også afhængige af andre threads. For eksempel kan en thread med højere prioritet eller et interrupt forsinke ek- sekveringen mere end forven- tet. Hvis en thread er baseret på delte ressourcer (som en mutex) kan resultatet af en adgang afhænge af den rela- tive timing i forhold til andre threads, der igen afhænger af helt tredje faktorer. Verificering af real-time kra- vene handler derfor ikke kun om målbare timing-forhold, men også om at identificere potentielle risici fra thread-in- teraktioner, der måtte påvirke timing-kravene. Analyse af multithreaded software Men hvordan verificerer man så et softwaresystem på den måde? Hvordan ved man, om et design er godt nok set ud fra et multithreading perspektiv? Og hvordan måler man soft- ware-timingen for at verificere real-time kravene? De facto-løsningen er run- time-observationer med brug af software-tracing. Det kan Percepios Tracealyzer netop levere med sit store sæt af vi- suelle analysefunktioner. Det bruges hyppigt til debugging af RTOS- og Linux-systemer på, ja, systemniveau, men giver også en masse funktionalitet i software-designanalyse og til verificering af real-time krav- specifikationer. Ved at anvende system-tracing med Tracealyzer kan desig- nere: • Opsamle detaljerede run- time-data om thread-eksekve- ring, thread-interaktioner og timing over lange testforløb uden behov for specialiseret hardware til formålet. • Finde anormaliteter i sy- stemets real-time behaviour med forskelligt overblik på højniveau som en graf for CPU- belastning eller en statistikrap- port, hvorefter man bare kan klikke på en anomal datapoin- ter og se detaljerne i eksekve- ringens trace-view. • Analysere variationer i soft- ware-timingen ved eksempel- vis at anvende Actor Instance Graph, der viser et plot over forskellige timing-forhold for hver thread over tid. • Få overblik over de indbyrdes thread-afhængigheder som eksempelvis en Communicati- on Flow-graf, som giver et visu- elt overblik over thread-inter- aktioner gennem IPC-objekter. Tracealyzer kræver ikke spe- cial hardware-support, men afhænger af en effektiv software-instrumentering i target-softwaren. Det trækker eksisterende trace-points ind i kernen, så man ikke behøver at tilføje instrumentering til ap- plikationskoden. Man kan dog udvide tracingen ved at tilføje eksplicitte tracing-calls i egen applikationskode. Trace-data kan overføres til en værtscomputer på forskellige måder, for eksempel gennem real-time streaming over en Ethernet-forbindelse eller med support fra en debug-probe. Man kan få mere information om – og afprøve/evaluere – Tracealyzer på: https://perce- pio.com. Percepios Tracealyzer giver et fantastisk grafisk overblik over real-time multithreadede systemer. Omnetics specializes in application-specific connector to cable systems. Our expert designers have experience designing harnesses for complex and harsh environment applications. Omnetics designers have the necessary experience needed to meet the Quality and Performance specifications required by the US Military, NASA and ESA. We design and manufacture a wide range of custom cable solutions to support all of our various product lines, while allowing your team to guide the design. Omnetics Connector Corporation follows IPC/WHMA-A-620 for all cable assembly, test and inspection practices. www.omnetics.com | sales@omnetics.com - nr. 1 | januar 2024 21
Download PDF fil
Se arkivet med udgivelser af Aktuel Elektronik her
TechMedias mange andre fagblade kan læses her