INDUSTRIELL EMBEDDED
Forts nästa sida
IEEE1588
för realtidssynkronisering över
Ethernet
I embeddedsystem finns
allt oftare krav på exakt
tidssynkronisering.
Jonas Svennebring från
Freescale Semiconductor beskriver här hur
synkroniseringen kan
hanteras via Ethernet.
Distribuerade
realtidssystem,
där enheter är utplacerade men
kopplade i nätverk, är idag vanliga inom industri och telekommunikation. Det kan handla om
sensorer och auktuatorer i ett
produktionssystem eller ett flertal
basstationer kopplade till en BSC/
RNC. Kommunikationen mellan
dessa enheter ställer höga krav
på att enheterna med exakthet är
synkroniserade i tid så att de kan
agera när en händelse har inträffat
eller ska inträffa.
Lösningen har hittills varit
att använda dyra klockor med
hög precision eller att använda
ett nätverk som är speciellt anpassat för ändamålet. Ethernets
explosionsartade tillväxt, vilket
leder till låga kostnader, kan nu
kompletteras med protokoll för
att med hög precision kunna
synkronisera tiden på varje enhet. Därigenom kan varje enhet
ha en billig och enkel klocka och
endast en huvudenhet har en
klocka med högre noggrannhet.
I denna artikel beskriver vi IEEE1588 samt hur hårdvarustödet för
detta i Freescales PowerQUICC
processorer kan användas för att
nå en noggranhet på under en
mikrosekund.
synkroniserin g f  r
realtidsapplik at i o n e r
Standarden IEEE-1588 PTP (Precision Time Protocol), har sitt ursprung i behovet att synkronisera
mätsystem med hög precision.
När ett instrument detekterar
en viss händelse är det vitalt att
i efterhand kunna se vad andra
instrument detekterade vid exakt
samma tidpunkt. På samma sätt
är det viktigt att inom telekommunikation eller industrin kunna
synkronisera händelser. Noggrannare koordinering av förlopp inom
industrin leder till bättre processnoggrannhet vilket i sig förbättrar
utfall och spar pengar.
Etablerade protokoll som
NTP/SNTP är inte designade att
ge samma höga precision eller låga
konvergenstid. En direkt omställning av klockan kan även ställa
till med problem om tidpunkten
för en viss händelse hoppas förbi.
IEEE-1588 som kan hantera detta, har en typisk konvergenstid på
under en minut och kan nå tidsdifferenser på storleksordningen
10 till 100 nanosekunder. Därtill
ställs låga krav på bandbredd och
CPU, vilket lämpar sig väl för inbyggda system.
IEEE-1588 baseras på antagandet att latensen, tiden det tar
för ett datapaket att gå från dator
A till dator B, är i snitt samma i
båda riktningarna. I nätverket
utses en enhet till att ha ”Grandmaster Clock” genom ”Best Mas-
Fig 1. Principen för synkronisering mellan master och slave.
ter Clock” algoritmen, mer om
det längre ner i artikeln. Målet är
att varje enhet sedan ska vara så
exakt som möjligt synkroniserad
mot denna klocka. Synkroniseringen mellan enheterna görs
genom att Master- och Slave-enheterna utbyter sina tider med
varandra. Med konstant latens
i överföringen, genom statistisk
behandling, kan latens beräknas
samt att slaven kan kompensera
för tidsskillnaden.
IEEE-1588 baseras på IP-paket via ”broadcast” UDP, vilket
dels är ett sätt att slippa hantera
IP-adresser till mottagarna och
dels på enklaste vis skickar till alla
mottagare samtidigt, vilket också
minimerar trafiken i nätverket.
Eftersom protokollet baseras på
IP-paket fungerar det även utanför Ethernetnätverk, så länge som
broadcast-funktionaliteten stöds.
s y n k ro n i s e r i n g m e d
ieee-1588
Med en approximativ, eller i vart
fall statistisk hanterbar, statisk latens mellan enheterna i nätverket
samt att datatrafiken i vardera
riktning mellan två enheter är
identisk kan vi nu synkronisera
klockorna. I fig 1 beskrivs hur två
enheter synkroniseras. Urspunglig
tidsdifferens är -3 tidsenheter. Vid
tiden Ta skickar Master-enheten
ut ett Sync-paket vilket anländer
vid tiden Tb. Sync-paketet i sig
innehåller en uppskattad tid Ta,
det exakta värdet kommer därefter i ett FollowUp-paket. I exemplet ser vi att en nätverkslatens på
5 tidsenheter ger en sammantagen
skillnad på 2 tidsenheter.
För att kunna beräkna latensen och differensen krävs ytterligare en överföring. Slavenheten
skickar ett DelayRequest-paket
till mästaren vilket ekar tillbaks
tiden det anlände via ett DelayRespons. I figuren skickas paketet vid tiden Tc och anländer
vid Td. Observera att endast
Sync- samt DelayRequest-paketen är kritiska att hantera
inom kort tid, FollowUp samt
DelayRespons innehåller endast
information om tiden men de
paketen kan i sig skickas med
fördröjning.
Givet information om Ta till
Td kan överföringshastighet samt
differens nu enkelt beräknas:
Nätverkslatens = [(Tb - Ta) + (Td
- Tc)] / 2
Differens = [(Tb - Ta) - (Td - Tc)]
/2
För exemplet i fig 1 får vi en
överföringstid på 5 tidsenheter
och en tidsdifferens mellan enheterna på 3 tidsenheter.
Master-enheten skickar normalt
ut Sync-paket varannan sekund,
DelayRequest paketen från slavenheterna kommer slumpmässigt mellan var 4:e och var 60:e
sekund. Från slavsidan finns ett
intresse i att minimera risken för
regelbundna kollisioner eller paket-kö till Master-enheten från
andra slavar.
Jitter i systemet utgörs i huvudsak av två delar, nätverket själv på
grund switchar och andra icke-deterministiska delar, men latensen
kan även komma internt i protokollstacken på en given enhet.
Eftersom protokollet är implementerat som IP-paket hanteras
det högt upp i protokollstacken,
se fig 2. En mjukvaruimplementering (till vänster i bilden) blir
därför dels operativsystemsberoende men även beroende av enhetens last. Lösningen, som beskrivs
nedan med en implementering
på Freescales Power-processorer,
är att lägga de tidskritiska delarna
i hårdvaran mellan MAC- och
PHY-lager. I den högra delen av
fig 2 ser vi hur PTP paketet hämtar och lämnar sitt klockvärde vid
MAC/PHY-lagret och på så sätt
får betydligt lägre jitter från protokollstacken.
s y n k ro n i s e r i n g
ver systemet
Som nämndes ovan är även nätverket själv en orsak till jitter. Direktkoppling mellan enheterna är
naturligtvis att föredra. Hubbar,
som endast arbetar på nivå-1, har
minimal påverkan. Switchar och
routrar på nivå-2 och uppåt kommer även vid en låg belastning att
kunna skapa stora slumpmässiga
skillnader i överföringstid. Eftersom switchar arbetar med köer
till interface kan ett enskilt paket
framför ge en fördröjning på över
100 mikrosekunder. Vid hög belastning är det inte ovanligt med
ett antal paket i kö. Även med
prioriterade paket finns problemet kvar eftersom ett paket på väg
att skickas ut inte kan prioriteras
ner. Lösningen är att använda en
gränsklocka, ”Boundary clock”.
Som fig 3 visar så har gränsklockan
en Master- och en Slave-del. Paket
skickas inte genom gränsklockan
utan slavdelen synkroniserar den
gemensamma klockan mot sin
Master. Gränsklockans Masterdel skickar i sin tur ut Sync-paket
och låter sina underliggande slavenheter synkronisera mot sig.
Baserat på ”Best Master Clock”, BMC-algoritmen utses alltid
den enhet med bäst klocka till
”Grandmaster”. Skulle enheten
falla av eller om en enhet med
bättre klocka kopplas på, kommer
en ny ”Grandmaster” att uses. Valet av grandmaster baseras på tolerans vilket är en sammantagen
bedömning av drift, varians och
klockans precision vilket indelas i
ett antal klasser. Atomur finns exempelvis i klass 1 med högst precision. För optimal precision på
samtliga enheter är det viktigt att
placera ”Grand Master” enheten
centralt i nätverket.
i m p l e m e n tat i o n p 
mpc8313 och mpc8360
Den andra komponenten av jitter i systemet är protokollstacken.
Eftersom IEEE-1588 baseras på
Fig 2. Mjukvaru- kontra hårdvaruimplementation.
precision genom
ntverket
Systemet påverkas naturligtvis
negativt av brus i överföringstider
även om statistiska metoder kan
användas för att minimera denna
påverkan. Kopplingen mellan
tidsdifferens och att exakt kunna
mäta överföringstiden är viktig.
ELEKTRONIK I NORDEN 12//2007
41
INDUSTRIELL EMBEDDED
Konstruktion/Systemkomponenter
IEEE 1588...
forts från föregående sida
antagandet att paket transporteras men liknande överföringstid
och tiden genom nätverksstacken
i sig kan skilja på hundratals mikrosekunder är den i en mjukvaruimplementation en begränsning
för precisionen. Lösningen är att
separera de realtidskritiska delarna från protokollhanteringen
så att klockan läggs på respektive
extraheras ut ur paketen direkt i
hårdvaran.
I ett exempel nedan har vi kopplat två kort med Freescales PowerQUICC, ett med MPC8313 där
implementationen sker i eTSEC
(enhanced Tripple Speed Ethernet Controller) och i det andra
fallet ett MPC8360 där implementationen sker med mikrokod
i QUICCEngine.
Funktionaliteten är motsvarande men implementationen
skiljer sig pga att de två kretsarna
riktar sig mot olika marknader.
MPC8313, se fig 4, är en krets
riktad främst till industiella applikationer och enklare tele- och
datakommunikationssystem. En
333 MHz Power processor (tidigare PowerPC) med MMU, FPU
och 16k data/instruktionscache i
kombination med två inbyggda
Gigabit Ethernet interface, USB,
PCI, DDR2 kontroller, fyra DMA
kanaler, SPI, I2C och UARTs med
mera. Kort sagt det mesta som behövs för ett komplett system finns
inbyggt i kretsen.
MPC8360 är en avancerad
krets, se fig 5, förutom en Powerprocessor som går upp till 667
MHz så har den även en QUICC
Engine-enhet vilket är en kommunikationsmodul som i sig har
två stycken RISC-kärnor som
klockas till 500 MHz. MPC8360
är främst riktad till avancerade
kommunikationsapplikationer
inom tele- och datakommunikation såsom trådlösa bassationer,
BSC/RNC, routrar, DSLAM osv.
Betoningen ligger på interface, två
Gigabit Ethernet allternativt åtta
stycken Fast Ethernet, PCI, åtta
TDM med 256 kanaler var, ATM
via två UTOPIA interface, USB
samt de vanliga SPI, I2C, UART
och naturligtvis minneskontroller. Till kärnan finns de vanliga
funktionerna som MMU, FPU
men även en större 32k data- och
instruktionscache.
Interfacen på MPC8360 är
främst kopplade via QUICC Engine-enheten vilken just är avsedd
att behandla inkommande data.
Terminering eller direkt omvandling mellan protokoll och portar
sköts utan att huvudkärnan behöver störas. Även förbehandling av
Fig 3. Gränsklockning mellan nätverk.
Fig 4. Blockdiagram över MPC8313.
Fig 6. IEEE-1588 - Hårdvaruimplementation.
Fig 7. Testuppställning,
MPC8360 till vänster och
MPC8313 till höger.
Fig 5. Blockdiagram över MPC8360.
paket som ska hanteras av kärnan
kan göras, exempelvis beräkning
av checksumma. Det är också
med hjälp av QUICC Enginefunktionen som IEEE-1588 är
implementerad på MPC8360.
stack och p r e s ta n d a
En typisk implementation i hårdvara med Freescales kretsar kan vi
se i fig 6. Klockdata till och från
kretsen hanteras direkt mellan
det externa PHY lagret och det
interna MAC lagret. Klockan tas
omhand av ”Time Stamp Unit”,
som i sin tur kan beräkna differenser via sin kontakt med den
interna klockan.
Inkommande data går därefter
upp till protokollstacken och en
applikation. Data till IEEE-1588
når ett ”Port Interface” som ansvarar för den övergripande meddelandehanteringen. Den tidskritiska datan kommer däremot in
via ”Time Stamp Interface” som
står i direktkontakt med hårdvarans ”Time Stamp Unit”. Det är
här den exakta Sync och DelayRequest informationen kommuniceras. Klockinterfacet ansvarar dels
för att ställa den interna klockan
men behandlar även statistisk information såsom klockans nog-
granhet och stabilitet. Via ett API
kan applikationer konfigurera och
läsa ut diagnostik. Protokollet
kräver även högre funktionalitet i
form av ”Best Master Clock” algoritmen samt specifik hantering
beroende på om enheten agerar
Master eller Slave. Här ingår att
vid jämna mellanrum generera
Sync- respektive DelayRequestmeddelanden.
För att underlätta utveckling
och användning av hårdvaran
tillhandahåller Freescale dels kort
för såväl MSC8360, se fig 7 till
vänster, som MSC8313 till höger.
Mjukvara i form av Linux BSP,
”Board Support Package”, kan
laddas ner direkt från Freescales
websida. Därtill finns ett brett stöd
med utvecklingsverktyg, operativsystem och drivrutiner från såväl
Freescale som samarbetspartners.
I ett test med direkt koppling,
dvs med minimalt nätverksjitter,
mellan två enheter under flera timmars körning, kan vi typiskt se en
maximal differens på under 100
ns. Standardavvikelsen är under
10 ns. Mätningen är naturligtvis
startad efter det att enheterna haft
en initial synkronisering.
jonas svennebring,
freescale semiconductor
42
ELEKTRONIK I NORDEN 12/2007