Hvad er Time Sensitive Networking (TSN)?

Hvad er Time Sensitive Networking (TSN)?

TSN er den nyeste udbygning af Ethernet-standarden, men hvad består den af, og hvordan kan den bruges til synkronisering af enheder på et netværk? 

Introduktion til TSN

Ethernet er en vidt anvendt kommunikationsstandard, der udgør rygraden i internettet. Den er standardiseret i IEEE 802.3 og bruges til at kommunikere et væld af data med. Den har dog den ulempe, at den ikke er deterministisk. Det vil sige, at der ikke er en garanteret svartid på forespørgsler over Ethernet. For almindelig internettrafik er determinisme ikke et krav, men for højtydende software og reguleringsprocesser er det afgørende, at data når frem til tiden.

Der er lavet forskellige løsninger for at indføre determinisme, blandt andet EtherCAT, der er et lukket netværk med en fast dataramme, som transmitteres ved en høj repetitionsrate. EtherCAT kan dog ikke udvides til et åbent netværk, og tillader ikke anden data end det, der på forhånd er defineret.

TSN er en generel løsning, der tillader deterministisk kommunikation på åbne ethernet-netværk. Den forudsætter hardware, der understøtter TSN, men er bagud-kompatibel, så almindelig ethernetdata kan transmitteres over TSN-aktiverede netværk.

Synkronisering

For at kunne levere deterministisk kommunikation kræves der et fælles tidskoncept, hvilket er fraværende i standard Ethernet. Dette involverer, at man kan synkronisere forskellige enheder over TSN, hvilket er kernen i dette indlæg. Synkronisering er standardiseret i TSN under IEEE 802.1AS, som er en udvidelse af en tidligere standard, IEEE 1588, der også er kendt som Precision Time Protocol (PTP). Derfor er TSN kompatibel med PTP – men hvor PTP arbejder på niveau 3 i OSI-modellen, så er TSN en niveau 2 teknologi, hvilket betyder, at den er upåvirket af netværkstrafik.

Synkroniseringen i TSN tager udgangspunkt i et master-ur, som alle de andre enheder refererer til. Master-uret vælges automatisk på det lokale netværk ud fra, hvilke der er tilgængelige og deres specifikationer. Hvis master-uret bliver utilgængeligt, bliver der automatisk valgt en ny master, som de andre enheder refererer til.

Ud fra master-uret bliver der nu sendt synkroniseringspakker til de andre enheder på netværket. Disse pakker måler afstanden fra masteren til alle slaver, og denne information bliver brugt til at korrigere slavernes ure, når de skal synkroniseres til master-uret. På denne måde kan TSN tage højde for forskellig kabellængde, forskellige svartider og andre imperfektioner i netværket for at få et synkront netværk.

Hvorfor TSN?

Kvaliteten af synkronisering i TSN er mindre end 1 µs som standard, men den kan ofte blive bedre, hvis man optimerer netværket. Det betyder, at TSN er en ideel teknik til distribuerede dataopsamlingssystemer med høj samplingsrate, hvor der transporteres stores datamængder over netværket. Det gør TSN egnet til for eksempel strukturelle tests, hvor store emner måles med mange strain gauges ved samplingsrater, der kan passere 100 kHz.

Deterministisk kommunikation via TSN åbner op for at bruge Ethernet i systemer, der styres af realtids-operativsystemer (RT-OS), så som maskinkontrol og hardware-in-the-loop (HIL). Her kræves der streng determinisme, hvilket gør almindelig ethernet uegnet. For at læse mere om dette, og hvordan NI’s produkter understøtter TSN, se her.

Hvad er hardware-abstraktion?

Hvad er hardware-abstraktion?

Hvad er hardware-abstraktion, og hvilke fordele giver det dig, når du optager eller genererer signaler til for eksempel testudstyr, dataindsamling eller kontrolsystemer?

Hardware-abstraktion: Hvorfor og hvornår?

Når et computerprogram skal kommunikere med et stykke hardware, er der brug for en driver, som giver programmet et interface til hardwaren. Driveren er typisk specifik til et givent stykke hardware, hvilket vil sige, at når man benytter driveren i et program, låser man sig i høj grad fast til dette instrument. Oftest vil man ikke kunne udskifte hardwaren uden at bygge en ny driver ind i programmet, og der er derfor kun en meget begrænset fleksibilitet i hardwaren.

Løsningen er at indlægge et hardware abstraction layer (HAL), så programmet er adskilt fra driveren. Programmet kommunikerer kun med hardwaren gennem et HAL, hvilket gør, at programmet ikke behøver at vide, hvilken konkret hardware det skal arbejde med. Programmet kender kun til hardwaren gennem et alias, som HAL oversætter til den faktiske hardware. Man siger, at hardwaren er abstraheret, da alle de konkrete detaljer er skjult for programmet.

HAL gør det nemt at udskifte et instrument med et andet, da man kun behøver at lade programmets alias pege på et andet instrument. Det kræver altså ikke nogen ændring i selve softwaren, men kun i dens konfiguration.

Læs mere om vores branchekendskab

Hardware-abstraktion hos GPower

Typisk bliver hardware-abstraktion implementeret ud fra typen af instrument, så man kan inddele instrumenterne i grupper. Hertil er udfordringen dog, at et instrument af type A ikke kan erstattes af et type B instrument – også selvom begge to har den påkrævede funktionalitet for en given måling. Som eksempel kan både et multimeter og et oscilloskop måle en DC-spænding på trods af, at de er vidt forskellige.

Hos GPower løser vi denne udfordring ved at basere vores hardware-abstraktion på funktionalitet i stedet for instrumenttype, hvilket giver større fleksibilitet i brugen af hardware og derfor lettere dataindsamling. Alle instrumenter, der implementerer den samme funktionalitet, kan derfor let udskiftes, og det kræver kun ændring i softwarens konfiguration.

Hvilke hardware-platforme bruger vi, når vi bygger systemer?

Hvilke hardware-platforme bruger vi, når vi bygger systemer?

I forhold til software-platforme bygger vi systemer ved hjælp af LabVIEW, som er et programmeringssprog, og TestStand, som er et framework til testmanagement. Men hvordan ser det ud i forhold til hardware-platforme?

Hvem er vores foretrukne hardware-leverandør?

Ud over at vores primære værktøjer er LabVIEW og TestStand, som begge er software fra National Instruments (NI), er vores foretrukne hardware-leverandør også NI. Men hvorfor?

Det skyldes blandt andet, at vi har mange års erfaring med, at de løsninger, som man kan udvikle med NI’s software og hardware, er de løsninger med den højeste kvalitet i forhold til at udvikle specialiserede systemer til projekter inden for test, måling og styring.

Men hvad mener vi mere konkret, når vi siger løsninger af den højeste kvalitet? Helt kort så har vi mange års erfaring med, at hvis man investerer i et system af høj kvalitet, at man så også i sidste ende sparer både tid og penge. Det skyldes, at man for eksempel undgår at have et system, som fejler, som er svært at vedligeholde, eller som ikke performer efter hensigten.

Eksempler på hardware

Da vi i de fleste af vores projekter beskæftiger os med test, måling og styring, er det primært PXI, CompactRIO, CompactDAQ og PC, som vi gør brug af, hvilket du kan læse mere om her:

16 Xeon Kerner for Embedded Real Time [PXI Controllers]

16 Xeon Kerner for Embedded Real Time [PXI Controllers]

Endnu en dag her på GPower-kontoret. Et par af National Instruments’ hurtigste PXI-controllere landede netop på kontoret her til morgen! NDA’er forhindrer os desværre i at fortælle præcist, hvad de skal bruges til, men vi kan sige så meget, at det er spændende som altid at arbejde her hos GPower!

Et par af NI's hurtigste PXI-controllere landede på kontoret her til morgen!

Endnu en dag her på GPower-kontoret. LabVIEW Real Time på Intel Xeon-baserede PXI controllers: 16 Xeon kerner / 32 tråde. Tilføj et par store Xilinx Kintex-7 FPGA’er og nogle infrarøde 26 megapixel-kameraer, og vi har et yderst potent system til et af vores kundeprojekter.

Se et udsnit af hardware fra National Instruments

Hvad skal vi bruge PXI Controllers til?

NDA’er forhindrer os desværre i at fortælle præcist, hvad disse PXI-controllere skal bruges til, men det drejer sig om målinger på nogle af de største maskiner, vi mennesker kan bygge i dag. Opgaven presser endnu en gang vores fysikere og ingeniører helt derud, hvor det er sjovt! Har du lyst til at være med?

Besøg vores karriereside

Få kvalitets-controllere til helt andre priser end tidligere! [CompactRIO]

Få kvalitets-controllere til helt andre priser end tidligere! [CompactRIO]

Hvor prisen for en controller af høj kvalitet hurtigt har nærmet sig 30-40.000 kr., behøver det ikke længere at være tilfældet! National Instruments har nemlig udgivet en ny serie af cRIO-modeller til helt andre priser, end vi har set tidligere – priser, som gør det lettere at igangsætte nye projekter og færdiggøre eksisterende.

Få kvalitets-controllere til den halve pris!

Kan jeres projekt realiseres med én ethernetport i stedet for to og en mere prisbevidst FPGA? Det er spørgsmål som disse, I kan stille jer selv, hvis I er interesseret i at få kvalitets-controllere til den halve pris, som de nye cRIO-modeller muliggør!

GPower er leverandør af hardware fra National Instruments 

Tag for eksempel cRIO-9056: Med undtagelse af antallet af netværksporte og en anden FPGA kan den præcist det samme som cRIO-3035. Forskellen er bare, at mens cRIO-9035 koster 26.680 kr., koster cRIO-9056 kun 14.010 kr.

Det vil sige, at med et par kompromisser kan I få den samme controller, men til cirka den halve pris. Og i dette tilfælde får ovenikøbet en controller, som understøtter brug af NI-DAQmx direkte fra c-moduler uden at bruge FPGA, hvilket ikke er tilfældet ved den dyrere model. 

Få et overblik over cRIO-controllerne her

Igangsæt nye projekter og færdiggør eksisterende

Mens mange tidligere har undgået at gå i gang med projekter, fordi alene hardware-prisen har virket uoverskuelig og skræmmende, så tror vi på, at nyheder som denne kan være med til at ændre tendensen. Således at det både bliver overskueligt at gå i gang med nye projekter, men også at udskifte gammelt hardware i eksisterende systemer for at optimere og sikre processer. 

Hvordan kan vi hjælpe?

Hos GPower binder vi National Instruments’ hardware sammen med vores egenudviklet software, når vi eksempelvis udvikler løsninger til at opsamle målinger, generere signaler og gemme dataset. 

Derudover vurderer vi også, hvilken løsning der passer bedst i forhold til jeres projekt. Og for at blive ved cRIO-modellerne så støder vi for eksempel ofte på, at det kan være mere end rigeligt at have en controller til at måle temperatur og synkronisere enheder, mens størrelsen på RAM og hukommelse kan have mindre betydning. Når vurderinger som disse er afgørende, skyldes det, at de kan have særlig betydning i forhold til hardware-prisen. 

Kontakt os her for at høre mere

NIDays Steen Schmidt

CompactRIO – når instrumenter tilpasses

“Building High PrecisionInstruments with CompactRIO”. Sådan lød overskriften til en af præsentationerne ved NIDdays, som blev holdt af vores grundlægger, Steen Secher Schmidt. I præsentationen gjorde han blandt andet publikum klogere på, hvad det vil sige at bygge instrumenter ved hjælp af CompactRIO.

En kort opsummering af præsentationen

Gik I glip af Steens præsentation til NIDays i København? Nedenfor har vi skitseret hovedtrækkene fra præsentationen:

    • Hvad gør instrumenter brugerdefinerede?
    • Hvordan sikrer vi, at brugerdefinerede instrumenter kan vedligeholdes og udvides med minimal risiko og arbejde?
    • Hvad går typisk galt i denne type projekter, og hvordan undgår vi disse fejl?
    • Er succesfulde projekter altid lig med brugerdefinerede instrumenter?
    • Hvorfor bruger vi GPower Actor Framework i stedet for NI Actor Framework?
    • Hvordan kombinerer vi CompactRIO og LabVIEW?

Hvorfor CompactRIO?

Når vi bruger CompactRIO, så sker det blandt andet med henblik på at forbedre avancerede kontrol- og overvågningssystemer i forbindelse med alt fra sensorer og kameraer til motorer og aktuatorer. Derudover bruger vi også CompactRIO til at simplificere komplekse applikationer, når vi fx samler en række delsystemer til ét samlet system, hvor mange forskellige komponenter forbindes direkte til instrumentet.

GPower er leverandør af hardware fra National Instruments 

Når vi har muligheden for at gøre dette, skyldes det i særdeleshed, at vi selv definerer softwaren i instrumentet. Det gør nemlig, at vi kan tilpasse instrumenterne, som vi vil – selv efter implementeringen.