CANaerospace

CANaerospace är ett högre lager protokoll baserat på Controller Area Network (CAN) som har utvecklats av Stock Flight Systems 1998 för aeronautiska applikationer.

CANaerospace Logo.jpg

Bakgrund

CANaerospace stöder luftburna system som använder konceptet Line-replaceable unit (LRU) för att dela data över CAN och säkerställer interoperabilitet mellan CAN LRU:er genom att definiera CAN:s fysiska lageregenskaper, nätverkslager, kommunikationsmekanismer, datatyper och aeronautiska axelsystem. CANaerospace är ett med öppen källkod , initierades för att standardisera gränssnittet mellan CAN LRUs på systemnivå. CANaerospace utvecklas ständigt ytterligare och har också publicerats av NASA som Advanced General Aviation Transport Experiments Databus Standard 2001. Den fick utbredd användning inom flygforskning världen över. Ett stort forskningsflygplan som använder flera CANaerospace-nätverk för sammankoppling av datorer i realtid är Stratospheric Observatory for Infrared Astronomy (SOFIA), en Boeing 747SP med ett 2,5 m astronomiskt teleskop. CANaerospace används också flitigt i flygsimulering och kopplar samman hela flygplanscockpits (dvs i Eurofighter Typhoon- simulatorer) till simuleringsvärddatorerna. I Italien används CANaerospace som UAV- databussteknik. Dessutom fungerar CANaerospace som kommunikationsnätverk i flera allmänna flygelektroniksystem.

CANaerospace-gränssnittsdefinitionen stänger gapet mellan ISO/OSI lager 1 och 2 CAN-protokoll (som är implementerat i själva CAN-styrenheten) och de specifika kraven för distribuerade system i flygplan. Det kan användas som ett primärt eller underordnat flygelektroniknätverk och designades för att uppfylla följande krav:

  • Demokratiskt nätverk: CANaerospace kräver inga master/slav-relationer mellan LRU:er eller en "buscontroller", vilket undviker en potentiell enskild källa till fel. Varje nod i nätet har samma rättigheter för deltagande i busstrafiken.
  • Självidentifierande meddelandeformat: Varje CANaerospace-meddelande innehåller information om typen av data och den sändande noden. Detta gör att data entydigt kan kännas igen vid varje mottagande nod.
  • Kontinuerlig meddelandenumrering: Varje CANaerospace-meddelande innehåller ett kontinuerligt inkrementerat nummer som möjliggör en sammanhängande behandling av meddelanden i de mottagande stationerna.
  • Meddelandestatuskod: Varje CANaerospace-meddelande innehåller information om integriteten hos de data som förmedlas. Detta tillåter mottagande stationer att utvärdera kvaliteten på mottagna data och att reagera därefter.
  • Emergency Event Signaling: CANaerospace definierar en mekanism som gör att varje nod kan överföra information om undantags- eller felsituationer. Denna information kan användas av andra stationer för att fastställa nätverkshälsan.
  • Nodtjänstgränssnitt: Som en förbättring av CAN tillhandahåller CANaerospace ett sätt för enskilda stationer i nätverket att kommunicera med varandra med hjälp av anslutningsorienterade och anslutningslösa tjänster.
  • Fördefinierad CAN Identifier Assignment: CANaerospace erbjuder en fördefinierad identifieringslista för normal driftdata. Förutom den fördefinierade listan kan användardefinierade identifieringslistor användas.
  • Enkelt att implementera: Mängden kod för att implementera CANaerospace är mycket liten genom design för att minimera ansträngningen för testning och certifiering av flygsäkerhetskritiska system.
  • Öppenhet för tillägg: Alla CANaerospace-definitioner kan utökas för att ge flexibilitet för framtida förbättringar och för att möjliggöra anpassningar till specifika applikationers krav.
  • Gratis tillgänglighet: Ingen kostnad alls gäller för användningen av CANaerospace. Specifikationen kan laddas ner från Internet

Fysiskt gränssnitt

För att säkerställa interoperabilitet och tillförlitlig kommunikation specificerar CANaerospace de elektriska egenskaperna, busstransceiverkraven och datahastigheterna med motsvarande toleranser baserat på ISO 11898 . Bittimingsberäkningen (noggrannhet för överföringshastighet, samplingspunktsdefinition) och robusthet mot elektromagnetiska störningar läggs särskild vikt vid. Också behandlade är CAN-kontakt, kabeldragningsöverväganden och designriktlinjer för att maximera elektromagnetisk kompatibilitet.

Kommunikationslager

Bosch CAN-specifikationen i sig tillåter att meddelanden sänds både periodiskt och oregelbundet men täcker inte frågor som datarepresentation , nodadressering eller anslutningsorienterade protokoll. CAN är helt baserat på Anyone-to-Many (ATM) kommunikation vilket innebär att CAN-meddelanden alltid tas emot av alla stationer i nätverket. Fördelen med CAN-konceptet är inneboende datakonsistens mellan alla stationer, nackdelen är att det inte tillåter nodadressering vilket är grunden för Peer-to-Peer (PTP) kommunikation. Att använda CAN-nät i flygtillämpningar kräver dock en standard anpassad till de specifika kraven för luftburna system vilket innebär att kommunikation mellan enskilda stationer i nätverket måste vara möjlig för att möjliggöra erforderlig grad av systemövervakning. Följaktligen definierar CANaerospace ytterligare ISO/OSI lager 3, 4 och 6 funktioner för att stödja nodadressering och enhetliga ATM/PTP-kommunikationsmekanismer. PTP-kommunikation gör det möjligt att ställa in klient/server-interaktioner mellan enskilda stationer i nätverket antingen tillfälligt eller permanent. Mer än en av dessa interaktioner kan vara verksamma vid varje given tidpunkt och varje nod kan vara klient för en operation och server för en annan samtidigt. Denna CANaerospace-mekanism kallas "Node Service Concept" och tillåter t.ex. att fördela systemfunktioner över flera stationer i nätverket eller att styra dynamisk systemomkonfiguration vid fel. Node Service-konceptet stöder både anslutningsorienterade och anslutningslösa interaktioner som med TCP/IP och UDP/IP för Ethernet .

Att aktivera både ATM- och PTP-kommunikation för CAN kräver införandet av oberoende nätverkslager för att isolera de olika typerna av kommunikation. Detta förverkligas för CANaerospace genom att bilda CAN-identifieringsgrupper som visas i figur 1. Den resulterande strukturen skapar logiska kommunikationskanaler (LCC) och tilldelar en specifik kommunikationstyp (ATM, PTP) till var och en av LCC:erna. Användardefinierade LCC:er ger den nödvändiga friheten för designers och tillåter implementering av CANaerospace enligt behoven hos specifika applikationer.

CANaerospace 1.jpg Figur 1: Logiska kommunikationskanaler för CANaerospace

Som en bieffekt påverkar CAN-identifierargrupperna i figur 1 prioriteten för meddelandeöverföringen i händelse av bussarbitrering. Kommunikationskanalerna är därför ordnade efter deras relativa betydelse:

  • Emergency Event Data Channel (EED): Denna kommunikationskanal används för meddelanden som kräver omedelbar åtgärd (dvs. systemförsämring eller omkonfigurering) och som måste sändas med mycket hög prioritet. Emergency Event Data använder uteslutande ATM-kommunikation.
  • Hög/låg prioritet Node Service Data Channel (NSH/NSL): Dessa kommunikationskanaler används för klient/server-interaktioner med PTP-kommunikation. Motsvarande tjänster kan vara av såväl anslutningsorienterad som anslutningslös typ. NSH/NSL kan också användas för att stödja test- och underhållsfunktioner.
  • Normal Operation Data Channel (NOD): Denna kommunikationskanal används för överföring av data som genereras under normal systemdrift och beskrivs i CANaerospace-identifieringslistan. Dessa meddelanden kan sändas periodiskt eller operiodiskt såväl som synkront eller asynkront. Alla meddelanden som inte kan tilldelas andra kommunikationskanaler ska använda denna kanal.
  • Hög/låg prioritet användardefinierad datakanal (UDH/UDL): Denna kanal är dedikerad till kommunikation som på grund av sina specifika egenskaper inte kan tilldelas andra kanaler utan att bryta mot CANaerospace-specifikationen. Så länge som det definierade identifierarintervallet används kan meddelandeinnehållet och kommunikationstypen (ATM, PTP) för dessa kanaler specificeras av systemdesignern. För att säkerställa interoperabilitet rekommenderas starkt att användningen av dessa kanaler minimeras.
  • Debug Service Data Channel (DSD): Denna kanal är tillägnad meddelanden som endast används tillfälligt för utvecklings- och teständamål och som inte sänds under normal drift. Så länge som det definierade identifierarintervallet används kan meddelandeinnehållet och kommunikationstypen (ATM, PTP) för dessa kanaler specificeras av systemdesignern.

Datarepresentation

Majoriteten av realtidskontrollsystemen som används inom flygteknik använder " big endian " processorarkitekturer. [ citat behövs ] Denna datarepresentation specificerades därför för CANaerospace också. Med big endian-datarepresentation arrangeras den mest signifikanta biten av varje datum längst till vänster och sänds först på CANaerospace som visas i figur 2.

CANaerospace 2.jpg Figur 2: "Big Endian" Datarepresentation för CANaerospace

CANaerospace använder ett självidentifierande meddelandeformat som realiseras genom att strukturera meddelandenyttolasten som visas i figur 3. Denna struktur definierar en 4-byte meddelandehuvud och en 4-byte parametersektion.

CANaerospace 3.jpg Figur 3: CANaerospace självidentifierande meddelandeformat

Vid första anblicken kan användningen av 50 % av CAN-meddelandens nyttolast för andra ändamål än att överföra driftsdata verka som ett slöseri med bandbredd. Men CANaerospace-meddelandehuvudet levererar värdefull information som skulle kräva användning av meddelandenyttolastbytes även när det realiseras på annat sätt: Headern tillåter mottagande stationer att analysera mottagna meddelanden omedelbart med avseende på ursprung, datatyp, integritet och skapelsetid. För att åstadkomma detta behövs ingen ytterligare information förutom kunskapen om CAN-identifieringstilldelningen för det speciella systemet. Meddelandehuvudets bytes har följande betydelse:

  • Nod-ID: För ATM-kommunikation (EED, NOD) anger nodidentifieraren den sändande noden. För PTP-kommunikation (NSH, NSL) anger den den adresserade noden (klient, server). För PTP-kommunikation används Node_ID "0" för att adressera alla stationer i nätverket (multicast).
  • Datatyp: Datatypen anger hur nyttolasten för meddelandet ska tolkas med avseende på dess datatyp (dvs flyttalsdata eller antal byte i händelse av heltalsdata). Motsvarande datatypskod hämtas från CANaerospace-datatyplistan som även tillåter användardefinierade datatypdefinitioner.
  • Servicekod: För normal driftdata (NOD) levererar servicekoden information om integriteten hos parametern som sänds med meddelandet. Detta kan vara resultatet av ett kontinuerligt inbyggt sensortest, den aktuella giltighetsflaggan för en navigeringssignal eller annan parameterspecifik information. Vid PTP-kommunikation anger servicekoden tjänsten för motsvarande klient/server-interaktion.
  • Meddelandekod: För normal driftdata (NOD) ökas meddelandekoden med en för varje meddelande med en speciell CAN-identifierare av den sändande noden. Efter att ha nått värdet 255 rullar meddelandekoden över till noll. Detta tillåter mottagande stationer att fastställa saknade eller försenade meddelanden och att reagera därefter. När det gäller PTP-kommunikation (NSH, NSL) används meddelandekoden tillsammans med tjänstekoden för att specificera tjänsten för motsvarande klient/server-interaktion mer i detalj.

Ovanstående information i CANaerospace-meddelandehuvudet innehåller viktig information för att fastställa integriteten hos parametrarna för användning i flygsäkerhetskritiska system och stödjer systemredundans. Dessutom förbättrar det avsevärt interoperabiliteten mellan LRU:er från olika leverantörer och tillåter övervakning av CANaerospace-nätverk angående statusen för LRU:er som är kopplade till den. För ytterligare interoperabilitet definierar CANaerospace flygspecifika axelsystem med motsvarande teckenkonventioner och fysiska enheter. Tillsammans med den fördefinierade identifierartilldelningslistan beskriver dessa definitioner trafiken i ett CANaerospace-nätverk entydigt. CANaerospace Standard Identifier Assignment List reserverar CAN-identifierarna mellan 300 och 1799 och tilldelar parametrar till dem som visas i utdraget av denna lista (Figur 4).

CANaerospace 4.jpg Figur 4: Utdrag från Standard Identifier Assignment List för CANaerospace V 1.7

Systemdesigners kan använda självdefinierade identifieringslistor. Den obligatoriska "Node Identification Service" som varje CANaerospace LRU måste svara på gör det möjligt att skanna nätverket efter anslutna LRU:er och deras identifieringslistakod för att undvika inkonsekvenser. CANaerospace Standard Identifier Assignment List samt listorna för datatyper och enheter tillhandahåller användardefinierade sektioner som kan användas av systemdesigners för att utöka dessa listor enligt deras behov.

Bandbreddshantering

En väsentlig egenskap hos alla flygsäkerhetskritiska system är att deras beteende måste definieras exakt, analyseras och testas för att uppfylla formella certifieringskrav. Denna egenskap misstolkas ofta som tidsdeterminism men är i själva verket förutsägbarhet. Graden av precision som krävs för timing är specifik för varje applikation och måste kvantifieras genom systemanalys. Det slutliga målet som ska uppnås är dock att det kan visas för certifieringsmyndigheter (dvs. FAA , EASA ) att ett säkerhetskritiskt system beter sig förutsägbart under förutsebara omständigheter. Med CANaerospace kan denna förutsägbarhet uppnås.

CANaerospace presenterar ett koncept för att hantera den tillgängliga bandbredden för ett multi-drop CAN-nätverk för att säkerställa förutsägbart beteende för ATM- och PTP-kommunikation, vilket kallas Time Triggered Bus Scheduling. Time Triggered Bus Scheduling baseras på en begränsning av antalet CAN-meddelanden som någon nod i nätverket kan sända inom en mindre tidsram. Den mindre tidsramen definieras under initial systemdesign. Det maximala antalet meddelanden som sänds inom en mindre tidsram kan skilja sig från nod till nod och innehålla tillväxtpotential om det beviljas av systemdesign. Det är avgörande för Time Triggered Bus Scheduling-konceptet att varje nod i nätverket alltid följer sitt överföringsschema när nätverkstrafik genereras. Det är dock varken obligatoriskt eller förbjudet att noder i nätet synkroniserar med andra noder vad gäller deras meddelandeöverföringsordning eller överföringstider.

CAN-felramar kan leda till oförutsägbart beteende om bandbredden förbrukas av felramar som är ett resultat av fel i nätverket eller de noder som är kopplade till det. Därför rekommenderar CANaerospace att man begränsar bandbreddsanvändningen till 50 % av den maximala bandbredden så att oförutsägbarheten minskas. Medan Time Triggered Bus Scheduling kräver marginaler och inte optimerar nätverksbandbreddsanvändningen, ger det ett säkert och enkelt tillvägagångssätt för att bygga certifierbara (förutsägbara) system. För att säkerställa detta under felförhållanden måste systemdesignern definiera beteendet under dessa förhållanden (felramar och undvikande av prioritetsinvertering) . Genom att tillämpa konceptet Time Triggered Bus Scheduling kan det visas att ett CANaerospace-nätverk beter sig förutsägbart. I figur 5 visas överföringsschemat för ett CANaerospace-nätverk med två noder som sänder sina meddelanden asynkront, i alternerande ordning och vid slumpmässiga tidpunkter inom sina mindre tidsramar (värsta tänkbara scenario). Det här exemplet använder 50 % av den maximala bandbredden.

CANaerospace 5.jpg Figur 5: Förenklat CANaerospace-överföringsschema

Med Time Triggered Bus Scheduling har inget meddelande i detta överföringsschema en latens som överstiger 50 % av en mindre tidsram plus varaktigheten för det längsta meddelandet. Time Triggered Bus Scheduling reducerar effekten av meddelandeprioritet på grund av det faktum att noderna på nätverket måste mäta sina meddelandeöverföringar.

Lokaloscillatortoleranser och brist på tidssynkronisering mellan noderna kommer att resultera i att mindre tidsramar glider bort från varandra. Detta påverkar inte meddelandeslatenserna negativt så länge som varaktigheten av den mindre tidsramen i alla noder stämmer överens. För att säkerställa förutsägbarhet måste alla aperiodiska meddelanden inkluderas i bandbreddshanteringsberäkningarna.

Time Triggered Bus Scheduling säkerställer tillräcklig flexibilitet för att öka nätverkstrafiken under systemets livstid om tillväxtpotential är planerad. Som ett exempel kommer systemdesign att tillåta att noder integreras i nätverket utan att de befintliga noderna påverkas. Dessutom tillåter det förutsägbara beteendet som framtvingas av Time Triggered Bus Scheduling system med olika kritikalitetsnivåer att samexistera på samma nätverk.

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=CANaerospace&oldid=1074214949 "