Många flygelektroniksystem har med framgång tagits fram med hjälp av specialutvecklad hård- och mjukvara. På senare år har dock de totala livscykelkostnaderna för specialsystem tvingat tillverkare att beakta användningen av Cots-(Commercial off-the-shelf)-baserade system. Samtidigt har det blivit allmer uppenbart att en övergång sker från bundna arkitekturer, där individuella subsystem utför en specifik funktion, mot generiska beräkningsplattformar som kan användas för flera typer av tillämpningar och, i vissa fall, köra flera tillämpningar samtidigt.

Detta tillvägagångssätt, som går under beteckningen integrerad modulär flygelektronik (IMA, Integrated Modular Avionics), resulterar i färre subsystem, minskad vikt och mindre plattformsredundans. Flera civila och militära forskningsprogram har syftat till att definiera IMA-arkitekturer med ett antal gemensamma högnivåmål:

Gemensamma subsystem för bearbetning: Ska möjliggöra för flera tillämpningar att dela och återanvända gemensamma beräkningsresurser. Detta resulterar i att ett minskat antal subsystem behöver tas fram och mer effektiv användning av systemresurser, vilket lämnar utrymme för framtida expansion.

Programvaruabstraktion: Ska isolera tillämpningen, inte bara från den underliggande bussarkitekturen, utan även från den underliggande hårdvaruarkitekturen. Det ger förbättrade möjligheter till portering av tillämpningar mellan olika plattformar och möjliggör även introduktionen av ny hårdvara för att ersätta föråldrade eller obsoleta arkitekturer.

Kostnader för förändringar: En IMA-arkitektur ska minska förändringskostnaderna då den underlättar återanvändning och minskar kostnaden för omtestning eftersom plattformens beståndsdelar kan testas mer oberoende av varandra. IMA underlättar även stöd för tillämpningar med ständigt ökande antal funktioner, inklusive samspelet mellan komplexa tillämpningar, såsom ”head-up”-skärmar, kartskärmsystem och väderradarskärmar.

Även om ett antal IMA-arkitekturer har tagits fram tycks ACR-specifikationen och ARINC-specifikation 653 ha anammats på bredast front inom flygelektronik. ACR-specifikationen beaktar arkitekturbaserade överväganden, medan ARINC 653 definierar, på hög nivå, fall av programvaruimplementering för en IMA-arkitektur. Dessa och andra IMA-standarder ställer nya krav på programvarans arkitektur, särskilt RTOS-implementeringen från Cots-leverantören.

Wind River har beaktat dessa behov genom att utveckla en plattform för flyg, rymd och försvar (Platform for Aerospace & Defense), Vxworks 653, ursprungligen framtagen för Smiths Industries Aerospace och Boeing.

ACR-specifikationen definierar två viktiga koncept inom IMA: spatial och temporal partitionering. Spatial partitionering definierar isoleringskraven för flera tillämpningar som körs samtidigt på samma beräkningsplattform, som även benämns ”modul.” I denna modell får inte tillämpningar som körs i en IMA-partition kunna ta ifrån varandra gemensamma tillämpningsresurser eller de som tillhandahålls av RTOS-kärnan. Detta åstadkoms oftast genom användning av olika virtuella minnesramar framtvingade av processorns minneshanteringsenhet (MMU). Dessa ramar kallas partitioner i ARINC 653. Varje partition innehåller en tillämpning med sin egen minneshög för dynamisk minnesallokering och ett stackminne för tillämpningens ”processer” (ARINC 653s beteckning för en exekveringsram). Dessa krav påverkar konstruktionen och implementeringen av RTOS-kärnan och -språkets körtidssystem. Vxworks 5.5 utnyttjar exempelvis ett gemensamt virtuellt adressutrymme för tillämpningar och tillhandahåller grundläggande stöd via MMUn för att förhindra oavsiktlig eller uppsåtlig tillgång till programkod av felande tillämpningar – utan att åstadkomma en fullständig processmodells overhead. I Vxworks 6.x och Vxworks 653 finns miljöer som använder MMUn för att framtvinga separata ramar.

I en IMA-miljö kan dock inte minnesskydd allena förhindra en felande tillämpning, som körs i en partition, från att förbruka systemresurser, vilket kan ha negativ inverkan på en tillämpning som körs i en annan partition. Detta kan få allvarliga konsekvenser när flera tillämpningar med olika prioriteringar körs på samma processor. Detta problem kan inte lösas endast genom användning av en fullständig processmodell; istället krävs utveckling av ett RTOS som specifikt beaktar IMAs behov.

Det modulära operativsystemet samverkar direkt med beräkningsplattformen (kärnmodulen) och tillhandahåller heltäckande resurshantering, tidsplanering och hälsoövervakning för samtliga partitioner. Den använder även ett kortstödpaket (BSP, board support package), den hårdvaruspecifika konfiguration som krävs för att köra på olika processorer och hårdvarukonfigurationer.

Partitionens operativsystem implementeras med hjälp av Vxworks mikrokärna och tillhandahåller tidsplanering och resurshantering inom en partition. Kommunikation med moduloperativsystemet sker genom ett särskilt gränssnitt för överföring av meddelanden för att säkert vara robust. Partitionsoperativsystemet tillhandahåller även ARINC 653 APEX-gränssnitt för tillämpningarna.

Temporal partitionering definierar isoleringskraven för flera tillämpningar som körs samtidigt på samma beräkningsplattform. Denna tillser att en tillämpning inte kan utnyttja processorn längre än avsett till nackdel för övriga tillämpningar. ARINC 653 hanterar detta problem genom att definiera en implementering som utnyttjar partitionsbaserad tidsplanering. En partition tidsplaneras för en tidslucka av bestämd längd, och andra partitioner kan allokeras tidsluckor av liknande eller olika längd. Inom en tidslucka kan en partition använda sin egen policy för tidsplanering, men vid tidsluckans slut framtvingar ARINC-tidsplaneraren en ramswitch till nästa partition i tidsplanen. Modellen är tillräckligt flexibel för att möjliggöra för existerande förbundna tillämpningar, eller nya IMA-tillämpningar som tagits fram särskilt för att inlemmas på en kärnmodul. Processen för partitionernas tidsplanering, verifiering av att gränser och tidsplaner inte överträds, samt vidtagande av lämpliga korrigerande åtgärder, ger dock oundvikligen upphov till ytterligare komplexitet.

ARINC 653 ger en högdeteministisk metod för tidsplanering som inte passar för alla tillämpningar, eftersom den kan leda till att partitionerna är overksamma under för lång tid, eller att klockan tickar snabbt för högfrekvent sampling av data. För dessa typer att tillämpningar finns i Vxworks 653 möjlighet till prioritetsförebyggande tidsplanering (PPS, priority preemptive scheduling) av partitioner. Denna metod tillåter ”dödtidsstöld” genom att möjliggöra för vissa partitioner att använda det som annars skulle ha varit overksam tid i den fastställda ARINC-tidsplanen.

ARINC 653 APEX (Application/Executive), ibland kallad ARINC 653 API, innehåller ett universalgränssnitt mellan operativsystemet och tillämpningsprogramvaran. APIn tillhandahåller även ett abstraktionslager som gömmer implementeringsuppgifter för ett visst RTOS, som uppfyller ARINC 653, från tillämpningen och kärnmodulens underliggande arkitektur. Detta underlättar portering av tillämpningen till andra ARINC 653-plattformar, ett viktigt övervägande för säkerhetskritiska IMA-system såsom flygdatorn, som kräver dubbel-redundanta eller till och med-i Boeing 777s fall-trippel-redundanta system.

ARINC 653 APEX tillhandahåller även en modell av statisk systemkonfiguration och -initialisering. Här är antalet ARINC-processer känt i förväg, och de skapas i partitionen via en startkod med hjälp av sekvensen för säkerhetskritiska tillämpningar och deterministiskt, fast utnyttjande av resurser.
Även om många IMA-tillämpningar kommer att utvecklas från grunden finns en mängd existerande tillämpningar av förbundna system. Dessa kan ha utvecklats i olika programmeringsspråk och kan använda olika modeller för tidsplanering, men de kan fortfarande behöva kommunicera med varandra i en IMA-miljö.

ARINC 653-arkitekturen garanterar tillgång på resurser genom användning av system- och partitionskonfigurationsposter (kallade ”system blueprints” i IMA-sammanhang). Syftet med dessa är att möjliggöra konfiguration av IMA-tillämpningar utvecklade av en eller flera OEMer på en gemensam IMA-plattform som är konfigurerad av en systemintegratören. Partitionskonfigurationsposterna definierar kännetecknen för varje OEM-tillämpning i fråga om minnesbehov, processorbehov och ARINC-portanvändning. Systemkonfigurationsposten definierar IMA-plattformens möjligheter och kapacitet och hänvisar till och validerar individuella partitionskonfigurationsposter. Denna metod gör det möjligt för systemintegratören att tillse att behovet av tillämpningarna överensstämmer med plattformens prestanda, och att individuella tillämpningar inte överskrider de resurser de tilldelats.

Den nuvarande versionen av ARINC-specifikation 653 innehåller endast en högnivådefinition av strukturen för och innehållet av konfigurationsposter, och överlåter implementeringen till RTOS-implementeraren, trots att ett XML-baserat konfigurationsprov presenteras. Vxworks 653 utnyttjar följande process:

Steg 1. Vid systemstarten laddar boot-koden moduloperativsystemet samt konfigurationsposter för system och partitioner.

Steg 2. Moduloperativsystemet startar sig självt, och startar sina egna subsystem.

Steg 3. Moduloperativsystemet laddar sedan tillämpningspartitionerna och deras tillämpningar.

Denna process kopplar bort konfigurationen av den binära avbildningen av modul-operativsystemet och den binära avbildningen av system- och partitionskonfigurationsposterna från partitionstillämpningarna. På detta vis kan individuella tillämpningar och subsystem utvecklas separat, sedan lätt integreras på målets filsystem. Individuella partitionstillämpningar kan även uppgraderas på enkelt sätt utan att förändringar behöver göras i modul-operativsystemets konfiguration.

ARINC 653 definierar konceptet ”hälsoövervakare” (HM, Health Monitor) inom ett IMA-system. HM ansvarar för ”övervakning av hårdvara, tillämpning och operativsystemfel och -misslyckande” och det är HMs roll att hjälpa till att ”isolera fel och förebygga att misslyckanden fortplantas”. Koncept kan verka enkelt, men det är faktiskt komplicerat och en sofistikerad systemtäckande HM krävs för att spåra fel och utföra omkonfigurering och återhämtning. Svaret på ett individuellt fel beror på felets natur, hur allvarligt det är och den felhanteringspolicy som fastställts av systemintegratören.

Hälsoövervakningsssystemet i Vxworks 653 är ett ramverk som fungerar som en inneboende del av arkitekturen. Den uppfyller samtliga krav enligt ARINC 653 och tillhandahåller utökningar som är relevanta för systemintegratörer som tänker använda dynamisk omkonfigurering.

En diskussion om utveckling av IMA-tillämpningar vore ofullständig utan att nämna utvecklings- och avlusningsverktyg. Verktyg konstruerade för utveckling av förbundna tillämpningar passar inte alltid för IMA-utveckling, eftersom de måste kunna stöda IMAs modeller och tidsplaneringsmetoder.
Vxworks 653-plattformen för flyg, rymd och försvar har nyligen förbättrats för att ersätta den Tornado 3-baserade utvecklingsmiljön med den Eclipse-baserade utvecklingssviten Wind River Workbench. Denna miljö inkluderar projektkonfigurering, kodbläddring och kodbyggande, Vxworks 653-simulator och avlusning, samt Wind Rivers systemanalysator. Skärmavbildningen här intill visar hur Workbench avlusar en tillämpning som körs i en ARINC-partition. Förutom de möjligheter som tillhandahålls av Wind River kan Eclipse-baserade tillbehör för verktyg med öppen källkod och från samarbetspartners ytterligare utöka och specialanpassa miljön.

De dynamiska visualiseringsmöjligheterna är en fördel för utvecklare av tillämningar, eftersom de erbjuder grafisk återkoppling av beteendet hos ARINC-, POSIX- och Vxworks-tillämpningarna samt samspelet mellan partitioner och hälsoövervakningssystemets arbete.

Det är viktigt för utvecklare av ARINC-tillämpningar att inte bara visualisera beteendet inom en individuell ARINC-partition, utan även syna kommunikationen mellan partitionerna via ARINC-portar och -kanaler. Detta åstadkoms genom att använda portmonitorerande verktyg inbyggda i RTOS och certifierade som en del av Vxworks 653. Portmonitorn ger insyn i systemets arbete från utvecklingsmiljö till slutlig certifierad flygkonfiguration; och den kan tillhandahålla detaljer på meddelandenivå för varje last eller endast informationen i ett ARINC-portmeddelandes huvud.

Säkerhet blir allt viktigare inom flygelektronik. På flygplansnivå kan säkerhet åstadkommas med hjälp av brandväggar som begränsar samverkan mellan olika typer av subsystem och separata flygsystem från OEM-system och flygbolagssystem. Tillkomsten av IMA innebär dock att satsningar görs för att öka-på ett certifierbart sätt-nätverkskopplingen inom dessa domäner. Målsättningen ger en del intressanta konstruktionsutmaningar.
TCP/IP och liknande nätverksprotokoll kräver betydande ansträngningar för att certifiera, och systemkonstruktörer måste åstadkomma en balans mellan funktionalitet och lämplighet för certifiering. Framför allt kan certifiering av en hel TCP/IP-stapel enligt DO-178B nivå A bli betungande. Somliga har förespråkat användning av egenutvecklade implementeringar som utnyttjar en slavprocessor för att implementera nätverksstapeln för masterprocessorn. Denna specialkonfiguration utnyttjar dock ytterligare hårdvara och begränsar möjligheterna att överföra programvaran. Wind River föredrar ett mer generellt tillvägagångssätt: att placera en certifierbar nätverksstack i en minnesskyddad I/O-partition för att isolera den från RTOS-kärnan och tillämpningspartitionerna.

Flygelektronikindustrin befinner sig mitt i ett avgörande skifte mot IMA. Utvecklingen av IMA-arkitekturer och -standarder introducerar utmaningar för såväl standardiseringsorganisationer som militära och civila utrustningstillverkare, men Wind River tillhandahåller en integrerad programvaruplattform för flyg, rymd och försvar. I Vxworks 653 förenas ett standarduppfyllande Cots-baserat RTOS med alla de verktyg som behövs för att framgångsrikt utveckla säkerhetskritiska IMA-tillämpningar.