ARINC 653

ARINC 653 (Avionics Application Software Standard Interface) är en mjukvaruspecifikation för rums- och tidsuppdelning i säkerhetskritiska avionikoperativsystem i realtid (RTOS). Det tillåter värd för flera applikationer av olika mjukvarunivåer på samma hårdvara inom ramen för en Integrated Modular Avionics- arkitektur.

Det är en del av ARINC 600-seriens standarder för digitala flygplan och flygsimulatorer.

Översikt

För att frikoppla realtidsoperativsystemplattformen från applikationsmjukvaran, definierar ARINC 653 ett API som kallas APplication EXEcutive (APEX) .

Varje applikationsprogram kallas en partition och har sitt eget minnesutrymme. Den har också en dedikerad tidslucka tilldelad av APEX API. Inom varje partition är multitasking tillåten . APEX API tillhandahåller tjänster för att hantera partitioner, processer och timing, såväl som partitions-/processkommunikation och felhantering. Partitioneringsmiljön kan implementeras genom att använda en hypervisor för att mappa partitioner till virtuella maskiner, men detta krävs inte.

Standarden övervakas av AEEC APEX Subcommittee [1] .

Historia

Första versionen

Den första versionen av ARINC 653 publicerades den 10 oktober 1996.

ARINC 653-1

Tillägg 1 publicerades i januari 1997 och introducerade begreppen APEX och Time and Space-partitionering.

ARINC 653-2

Tillägg 2 publicerades i 3 delar mellan mars 2006 och januari 2007:

Del 1 (obligatoriska tjänster): ARINC 653-partitionshantering, Kallstart och varmstartsdefinition, Programvarufelhantering, ARINC 653-kompatibilitet, Ada- och C -språkbindningar;
Del 2 (valfria tjänster): Filsystemåtkomst , Dataloggning , Serviceåtkomstpunkter, ...
Del 3 (Conformity Test Specification);

Nuvarande organisation av standard

Del 0 - Introduktion till ARINC 653 (för närvarande vid revision 3, släppt november 2021)

Del 1 - Obligatoriska tjänster (för närvarande vid revision 5, släppt december 2019)
Del 2 - Utökade tjänster (för närvarande vid revision 4, släppt december 2019)
Del 3A - Konformitetstestspecifikation för erforderliga tjänster (för närvarande vid revision 2, släppt november 2021)
Del 3B - Konformitetstestspecifikation för utökade tjänster (för närvarande vid revision c1, släppt juli 2019)
Del 4 - Delmängdstjänster (för närvarande vid revision 0, släppt juni 2012)
Del 5 - Rekommenderade funktioner för kärnprogramvara (för närvarande vid revision 1, släppt augusti 2019)

Grundläggande principer för partitionering

ARINC 653 Plattform

En ARINC 653- plattform innehåller:

En hårdvaruplattform som tillåter deterministiska beräkningstjänster i realtid .
Ett abstraktionslager som hanterar timer- och utrymmespartitioneringsbegränsningarna för plattformen ( minne , CPU , Input/output) .
En implementering för ARINC 653-tjänsterna (APEX API).
Ett gränssnitt för att kunna konfigurera plattformen och dess användningsdomän.
Olika instrumenteringsverktyg.

Initialisering

Initiering av en ARINC 653-partition skapar resurser som används av partitionen. Skapandet av resurser (PROCESS, EVENT, SEMAPHORE...) utförs genom att anropa API-tjänster med namnet CREATE_xxxx .

Felhantering

Processfelhanteraren är en förebyggande process med högsta prioritet för att hantera partitionsundantag. Den skapas av tjänsten CREATE_ERROR_HANDLER under partitionsinitiering.

API:et tillåter felhanteraren att stoppa en felaktig process ( STOP_SELF ). I så fall kommer RTOS- schemaläggaren att framkalla nästa process med högsta prioritet.

ARINC 653 specificerar inte hur schemaläggaren ska bete sig om felhanteraren inte stoppar en felaktig process. I vissa (teoretiska) fall kan detta leda till en oändlig loop mellan den felaktiga processen och felhanteraren.

Felhanteraren kan få information om källan och sammanhanget för undantaget.

Lägeshantering

Varje partition kan vara i flera aktiveringslägen:

COLD_START och WARM_START: Endast initieringsprocessen exekveras,
NORMAL: Initieringsprocessen stoppas och de andra partitionsprocesserna anropas av RTOS- schemaläggaren beroende på deras prioritet,
IDLE: Ingen process körs. En implementering skulle dock fortfarande i teorin kunna utföra en dold process med lägst prioritet, till exempel för att starta en oändlig loop.

Tjänsten SET_PARTITION_MODE tillåter att hantera dessa tillstånd. Den kan anropas av vilken process som helst i partitionen. Att gå in i IDLE-tillståndet är oåterkalleligt för partitionen. Endast en extern händelse (som en omstart av plattformen) kan ändra tillståndet till ett annat läge när partitionen är i detta tillstånd.

Partitionering och processschemaläggning

Standarden definierar ett hierarkiskt schema på två nivåer. Den första nivån schemalägger partitionerna. Detta är ett round-robin, fast schema som upprepar en större tidsram. Den stora tidsramen schemalägger varje partition i en fast tidsram med en fast förskjutning från början av den stora tidsramen.

ARINC 653 partitionsschema

Inom den mindre tidsramen använder den andra nivån processschemaläggning. Varje partition har minst en process . Processschemaläggning inom en mindre tidsram är förebyggande . Schemaläggaren anropas antingen av en timer eller av API-tjänster.

Multicore

ARINC 653 P1-5 uppdaterades för att hantera flerkärniga processorarkitekturer. Avsnitt 4.2.1 "O/S Multicore Implementation Compliance" indikerar att ett operativsystem som är designat för multi-core processing bör stödja två fall:

Användning av flera kärnor av en enda partition (vars processer spänner över flera kärnor)
Användning av flera kärnor av flera partitioner

Positionsdokumentet CAST-32A definierar en uppsättning krav och vägledning som bör uppfyllas för att certifiera och använda flerkärniga processorer inom civil luftfart av FAA och förväntas ersättas av ett rådgivande cirkulär , AC 20-193. Europeiska unionens luftfartsmyndighet, EASA, publicerade AMC 20-193 i januari 2022.

API-tjänster

ARINC 653 APEX-tjänsterna är API- anrop som hör till sex kategorier:

Partitionshantering
Processledning
Tidsplanering
Kommunikation mellan partitioner
Kommunikation inom partition
Felhantering

Inga ARINC 653-tjänster tillhandahålls för minneshantering av partitioner. Varje partition måste hantera sitt eget minne (fortfarande under begränsningarna för minnespartitionering som framtvingas av ARINC 653).

Varje tjänst returnerar ett RETURN_CODE-värde som indikerar om samtalet har lyckats:

NO_ERROR: tjänsten utförs nominellt efter en giltig begäran
NO_ACTION: systemets tillstånd har inte ändrats efter att tjänsten har körts
NOT_AVAILABLE: tjänsten är tillfälligt otillgänglig
INVALID_PARAM: minst en av tjänstens parametrar är ogiltig
INVALID_CONFIG: minst en av tjänstens parametrar är inkompatibel med den aktuella konfigurationen av systemet
INVALID_MODE: tjänsten är inkompatibel med systemets nuvarande läge
TIMED_OUT: fördröjningen för utförande av tjänsten har löpt ut

Länkar till POSIX och ASAAC

Fältet som täcks av ARINC 653 liknar ASAAC Def Stan 00-74 . Det finns dock skillnader mellan de två standarderna.

Vissa ARINC 653 (APEX)-anrop har en POSIX- motsvarighet, men skiljer sig från hur de definieras i POSIX.

Till exempel följande anrop definierat i ASAAC:

ta emot Buffert

skulle översättas i ARINC 653 av:

RECEIVE_BUFFER()

och även i POSIX av:

recv()

Se även