Sissejuhatus
Elektrienergiatööstuses “Digitaalse alajaama” ehitamise kontseptsioon nõuab sünkroniseerimist 1 μs täpsusega. Ka finantstehingud nõuavad mikrosekundilist täpsust. Nendes rakendustes ei piisa enam NTP aja täpsusest.
PTPv2 sünkroonimisprotokoll, mida kirjeldab IEEE 1588v2 standard, võimaldab sünkroonimise täpsust mitmekümne nanosekundi ulatuses. PTPv2 võimaldab saata sünkroonimispakette L2 ja L3 võrkude kaudu.
Peamised valdkonnad, kus PTPv2 kasutatakse, on järgmised:
- energia;
- juhtimis- ja mõõteseadmed;
- sõjatööstuskompleks;
- telekommunikatsioon;
- finantssektoris.
See postitus selgitab, kuidas PTPv2 sünkroonimisprotokoll töötab.
Meil on tööstuses rohkem kogemusi ja sageli näeme seda protokolli energiarakendustes. Seetõttu teeme ülevaatuse ettevaatlikult .
Miks see vajalik on?
Hetkel sisaldavad PJSC Rosseti STO 34.01-21-004-2019 ja PJSC FGC UES STO 56947007-29.240.10.302-2020 nõudeid protsessisiini korraldamiseks aja sünkroniseerimisega PTPv2 kaudu.
See on tingitud asjaolust, et protsessisiiniga on ühendatud releekaitse klemmid ja mõõteseadmed, mis edastavad protsessi siini kaudu voolu ja pinge hetkeväärtusi, kasutades nn SV-vooge (multicast vooge).
Releekaitseklemmid kasutavad neid väärtusi lahtri kaitse rakendamiseks. Kui aja mõõtmise täpsus on väike, võivad mõned kaitsed valesti töötada.
Näiteks võivad absoluutse selektiivsuse kaitsed langeda "nõrga" aja sünkroniseerimise ohvriks. Sageli põhineb selliste kaitsemehhanismide loogika kahe suuruse võrdlusel. Kui väärtused erinevad piisavalt suure väärtuse võrra, käivitub kaitse. Kui neid väärtusi mõõdetakse aja täpsusega 1 ms, siis on võimalik saada suur erinevus, kus väärtused on tegelikult normaalsed, kui mõõta 1 μs täpsusega.
PTP versioonid
PTP-protokolli kirjeldati algselt 2002. aastal standardis IEEE 1588-2002 ja selle nimi oli "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". 2008. aastal anti välja uuendatud IEEE 1588-2008 standard, mis kirjeldab PTP versiooni 2. See protokolli versioon parandas täpsust ja stabiilsust, kuid ei säilitanud tagasiühilduvust protokolli esimese versiooniga. Samuti anti 2019. aastal välja IEEE 1588-2019 standardi versioon, mis kirjeldab PTP v2.1. See versioon lisab PTPv2-le väiksemaid täiustusi ja on PTPv2-ga tagasiühilduv.
Teisisõnu on meil järgmine pilt koos versioonidega:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Sobimatu
Sobimatu
PTPv2 (IEEE 1588-2008)
Sobimatu
-
Ühilduv
PTPv2.1 (IEEE 1588-2019)
Sobimatu
Ühilduv
-
Kuid nagu alati, on nüansse.
PTPv1 ja PTPv2 vaheline ühildumatus tähendab, et PTPv1 toega seade ei saa sünkroonida PTPv2-s töötava täpse kellaga. Nad kasutavad sünkroonimiseks erinevaid sõnumivorminguid.
Kuid samas võrgus on siiski võimalik ühendada PTPv1-ga seadmeid ja PTPv2-ga seadmeid. Selle saavutamiseks lubavad mõned tootjad valida protokolli versiooni servakella portides. See tähendab, et piirikell saab sünkroonida PTPv2 abil ja siiski sünkroonida teisi sellega ühendatud kellasid, kasutades nii PTPv1 kui ka PTPv2.
PTP-seadmed. Mis need on ja kuidas need erinevad?
IEEE 1588v2 standard kirjeldab mitut tüüpi seadmeid. Kõik need on näidatud tabelis.
Seadmed suhtlevad üksteisega LAN-i kaudu, kasutades PTP-d.
PTP-seadmeid nimetatakse kelladeks. Kõik kellad võtavad vanameistri kellalt täpse aja.
Kellasid on 5 tüüpi:
Vanameistri kell
Täpse aja peamine allikas. Sageli varustatud liidesega GPS-i ühendamiseks.
Tavaline kell
Ühe pordiga seade, mis võib olla ülem (ülemine kell) või alam (alamkell)
Ülemkell (meister)
Need on täpse aja allikaks, mille järgi teised kellad sünkroonitakse
Orjakell
Põhikellaga sünkroonitud lõppseade
Piirikell
Mitme pordiga seade, mis võib olla ülem- või alamseade.
See tähendab, et need kellad saavad sünkroonida kõrgema peamise kellaga ja sünkroonida madalamaid alamkellasid.
Otsast lõpuni läbipaistev kell
Mitme pordiga seade, mis ei ole ülemkell ega alamkell. See edastab PTP-andmeid kahe kella vahel.
Andmete edastamisel korrigeerib läbipaistev kell kõiki PTP teateid.
Parandus toimub, lisades selle seadme viiteaja edastatud sõnumi päises olevale parandusväljale.
Peer-to-Peer läbipaistev kell
Mitme pordiga seade, mis ei ole ülemkell ega alamkell.
See edastab PTP-andmeid kahe kella vahel.
Andmete edastamisel korrigeerib läbipaistev kell kõik PTP sõnumid Sync ja Follow_Up (nende kohta lähemalt allpool).
Parandus saavutatakse, lisades edastatava paketi parandusväljale edastusseadme viivituse ja andmeedastuskanali viivituse.
Juhtimissõlm
Seade, mis konfigureerib ja diagnoosib teisi kellasid
Ülem- ja alamkellad sünkroonitakse PTP-sõnumite ajatemplite abil. PTP-protokollis on kahte tüüpi sõnumeid:
- Sündmusteated on sünkroonitud sõnumid, mis hõlmavad ajatempli genereerimist sõnumi saatmise ja vastuvõtmise ajal.
- Üldteated – need sõnumid ei vaja ajatempleid, kuid võivad sisaldada seotud sõnumite ajatempleid
Sündmuse sõnumid
Üldised sõnumid
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Teatama
Järeltegevus
Delay_Resp
Pdelay_Resp_Follow_Up
juhtimine
Signaliseerimine
Kõiki sõnumitüüpe käsitletakse üksikasjalikumalt allpool.
Põhilised sünkroonimisprobleemid
Kui sünkroonimispakett edastatakse kohaliku võrgu kaudu, hilineb see kommutaatoris ja andmelingis. Iga lüliti tekitab umbes 10 mikrosekundilise viivituse, mis on PTPv2 puhul vastuvõetamatu. Lõppude lõpuks peame lõppseadmes saavutama 1 μs täpsuse. (See on siis, kui me räägime energiast. Muud rakendused võivad nõuda suuremat täpsust.)
IEEE 1588v2 kirjeldab mitmeid tööalgoritme, mis võimaldavad salvestada viivituse ja seda parandada.
Töö algoritm
Normaalse töö ajal töötab protokoll kahes faasis.
- 1. faas – hierarhia „Master Clock – Slave Clock” loomine.
- 2. faas – kella sünkroonimine end-to-end või Peer-to-Peer mehhanismi abil.
1. etapp – ülem-alluv hierarhia loomine
Igal tavalise või servakella pordil on teatud arv olekuid (alamkell ja ülemkell). Standard kirjeldab nende olekute vahelist üleminekualgoritmi. Programmeerimises nimetatakse sellist algoritmi lõpliku oleku masinaks või olekumasinaks (täpsemalt Wikis).
See olekumasin kasutab kahe kella ühendamisel ülemkella seadistamiseks parimat põhikella algoritmi (BMCA).
See algoritm võimaldab kellal üle võtta vanameistri kella kohustused, kui ülesvoolu suurmeistrikell kaotab GPS-signaali, läheb võrguühenduseta jne.
Olekuüleminekud vastavalt BMCA-le on kokku võetud järgmisel diagrammil:
Teave “traadi” teises otsas oleva kella kohta saadetakse spetsiaalse sõnumiga (Announce message). Kui see teave on kätte saadud, käivitub olekumasina algoritm ja tehakse võrdlus, et näha, milline kell on parem. Parima kella portist saab peakell.
Lihtne hierarhia on näidatud alloleval diagrammil. Teed 1, 2, 3, 4, 5 võivad sisaldada läbipaistvat kella, kuid need ei osale põhikella – orjakella hierarhia loomises.
2. faas – sünkroonige tava- ja servakellad
Kohe pärast hierarhia “Master Clock – Slave Clock” loomist algab tava- ja piirkellade sünkroniseerimise faas.
Sünkroonimiseks saadab ülemkell alamkelladele ajatemplit sisaldava teate.
Põhikell võib olla:
- üheastmeline;
- kaheastmeline.
Üheastmelised kellad saadavad sünkroonimiseks ühe sünkroonimissõnumi.
Kaheastmeline kell kasutab sünkroonimiseks kahte sõnumit – Sync ja Follow_Up.
Sünkroonimisfaasis saab kasutada kahte mehhanismi:
- Päringu-vastuse viivitusmehhanism.
- Peer viivituse mõõtmise mehhanism.
Kõigepealt vaatame neid mehhanisme kõige lihtsamal juhul – kui läbipaistvaid kellasid ei kasutata.
Päringu-vastuse viivitusmehhanism
Mehhanism koosneb kahest etapist:
- Ülem- ja alamkella vahelise teate edastamise viivituse mõõtmine. Teostatakse viivituse päringu-vastuse mehhanismi abil.
- Teostatakse täpse ajanihke korrigeerimine.
Latentsuse mõõtmine
t1 – põhikella poolt sünkroonimisteate saatmise aeg; t2 – alamkella poolt sünkroonimisteate vastuvõtmise aeg; t3 – viitepäringu (Delay_Req) saatmise aeg alamkella poolt; t4 – Delay_Req vastuvõtuaeg põhikella poolt.
Kui alamkell teab aegu t1, t2, t3 ja t4, saab ta arvutada keskmise viivituse sünkroniseerimissõnumi (tmpd) edastamisel. See arvutatakse järgmiselt:
Sünkroonimis- ja jälgimissõnumi edastamisel arvutatakse ajaviivitus ülemseadmest alamseadmesse – t-ms.
Delay_Req ja Delay_Resp teadete edastamisel arvutatakse viivitus alamseadmest ülemseadmesse - t-sm.
Kui nende kahe väärtuse vahel tekib teatav asümmeetria, siis ilmneb viga täpse aja hälbe korrigeerimisel. Viga on põhjustatud sellest, et arvutatud viivitus on t-ms ja t-sm viivituste keskmine. Kui viivitused ei ole üksteisega võrdsed, siis me ei reguleeri aega täpselt.
Aja nihke korrigeerimine
Kui ülem- ja alamkella vaheline viivitus on teada, teostab alamkell ajakorrektsiooni.
Slave kellad kasutavad sünkroonimissõnumit ja valikulist Follow_Up teadet, et arvutada täpse aja nihe paketi edastamisel ülemseadmelt alamkelladele. Nihe arvutatakse järgmise valemi abil:
Peer viivituse mõõtmise mehhanism
See mehhanism kasutab sünkroonimiseks ka kahte etappi:
- Seadmed mõõdavad kõigi portide kaudu kõigi naabrite ajalist viivitust. Selleks kasutavad nad partnerite viivitusmehhanismi.
- Täpse ajanihke korrigeerimine.
Võrdlusrežiimi toetavate seadmete latentsuse mõõtmine
Peer-to-peer mehhanismi toetavate portide vahelist latentsust mõõdetakse järgmiste teadete abil.
Kui port 1 teab aegu t1, t2, t3 ja t4, saab ta arvutada keskmise viivituse (tmld). See arvutatakse järgmise valemi abil:
Seejärel kasutab port seda väärtust iga seadet läbiva sünkroonimissõnumi või valikulise jälgimissõnumi reguleerimisvälja arvutamisel.
Kogu viivitus on võrdne selle seadme kaudu edastatava viivituse, andmekanali kaudu edastamise keskmise viivituse ja selles teates juba sisalduva viivituse summaga, mis on lubatud ülesvoolu seadmetes.
Sõnumid Pdelay_Req, Pdelay_Resp ja valikuline Pdelay_Resp_Follow_Up võimaldavad teil saada viivituse ülem-alam ja alam-ülem (ringkiri).
Mis tahes asümmeetria nende kahe väärtuse vahel toob kaasa ajanihke korrigeerimise vea.
Täpse aja nihke reguleerimine
Slave kellad kasutavad sünkroonimissõnumit ja valikulist Follow_Up teadet, et arvutada täpse aja nihe paketi edastamisel ülemseadmelt alamkelladele. Nihe arvutatakse järgmise valemi abil:
Peer-to-peer mehhanismi reguleerimise eelised – iga Sync või Follow_Up sõnumi viivitus arvutatakse selle edastamisel võrgus. Järelikult ei mõjuta edastustee muutmine kuidagi reguleerimise täpsust.
Selle mehhanismi kasutamisel ei nõua aja sünkroonimine sünkroonimispaketi läbitud teekonna aja viivituse arvutamist, nagu seda tehakse põhivahetuses. Need. Delay_Req ja Delay_Resp sõnumeid ei saadeta. Selle meetodi puhul summeeritakse ülem- ja alamkellade vaheline viivitus lihtsalt iga sünkroonimis- või jälgimissõnumi reguleerimisväljal.
Teine eelis on see, et põhikell on vabastatud Delay_Req sõnumite töötlemise vajadusest.
Läbipaistvate kellade töörežiimid
Järelikult olid need lihtsad näited. Oletame nüüd, et sünkroonimisteele ilmuvad lülitid.
Kui kasutate ilma PTPv2-toeta lüliteid, hilineb sünkroonimispakett lülitil umbes 10 μs võrra.
PTPv2 toetavaid lüliteid nimetatakse IEEE 1588v2 terminoloogias läbipaistvateks kelladeks. Läbipaistvaid kellasid ei sünkroniseerita põhikellast ega osale hierarhias “Master Clock - Slave Clock”, kuid sünkroonimissõnumite edastamisel mäletavad nad, kui kaua nad sõnumit viivitasid. See võimaldab teil viivitust reguleerida.
Läbipaistvad kellad võivad töötada kahes režiimis:
- Otsast lõpuni.
- Peer to peer.
Otsast lõpuni (E2E)
E2E läbipaistev kell edastab sünkroonimise sõnumeid ja nendega kaasnevaid Follow_Up teateid kõigis portides. Isegi need, mis on blokeeritud mõne protokolliga (näiteks RSTP).
Lüliti jätab meelde ajatempli, millal pordis võeti vastu sünkroonimispakett (Follow_Up) ja millal see pordist saadeti. Nende kahe ajatempli põhjal arvutatakse aeg, mis kulub lülitil sõnumi töötlemiseks. Standardis nimetatakse seda aega viibimisajaks.
Töötlemisaeg lisatakse sõnumi Sync (ühesammuline kell) või Follow_Up (kaheastmeline kell) väljale correctionField.
E2E läbipaistev kell mõõdab lülitit läbivate sõnumite Sync ja Delay_Req töötlemisaega. Kuid on oluline mõista, et ülem- ja alamkella vaheline viivitus arvutatakse viivituse päringu-vastuse mehhanismi abil. Kui ülemkell muutub või tee ülemkellast alamkellani muutub, mõõdetakse viivitust uuesti. See pikendab võrgumuudatuste korral üleminekuaega.
P2P läbipaistev kell mõõdab lisaks lülitile sõnumi töötlemiseks kuluva aja mõõtmisele lähima naabri andmelingi viivitust, kasutades naabri latentsusmehhanismi.
Latentsust mõõdetakse igal lingil mõlemas suunas, sealhulgas linkidel, mis on blokeeritud mõne protokolli (nt RSTP) poolt. See võimaldab teil kohe arvutada uue viivituse sünkroonimisteel, kui suurmeistri kell või võrgu topoloogia muutub.
Sõnumite töötlemise aeg lülitite kaupa ja latentsus koguneb sünkroonimis- või jälgimissõnumite saatmisel.
PTPv2 toe tüübid lülitite abil
Lülitid võivad toetada PTPv2:
- programmiliselt;
- riistvara.
PTPv2 protokolli tarkvaras juurutamisel küsib lüliti püsivara ajatemplit. Probleem on selles, et püsivara töötab tsükliliselt ja peate ootama, kuni see lõpetab praeguse tsükli, võtab taotluse töötlemiseks ja väljastab pärast järgmist tsüklit ajatempli. See võtab samuti aega ja me saame viivituse, ehkki mitte nii märkimisväärse kui ilma PTPv2 tarkvaratoeta.
Ainult PTPv2 riistvaratugi võimaldab teil säilitada nõutava täpsuse. Sel juhul väljastab ajatempli pordile paigaldatud spetsiaalne ASIC.
Sõnumi vorming
Kõik PTP-sõnumid koosnevad järgmistest väljadest:
- Päis – 34 baiti.
- Keha – suurus sõltub sõnumi tüübist.
- Järelliide on valikuline.
Päise
Päise väli on kõigi PTP-sõnumite jaoks sama. Selle suurus on 34 baiti.
Päisevälja vorming:
sõnumi tüüp – sisaldab edastatava sõnumi tüüpi, näiteks Sync, Delay_Req, PDelay_Req jne.
sõnumi pikkus – sisaldab PTP-sõnumi täissuurust, sealhulgas päist, sisu ja järelliidet (kuid täitebaite välja arvatud).
domeeninumber – määrab, millisesse PTP domeeni sõnum kuulub.
Domeeninimi - need on mitu erinevat kella, mis on kogutud ühte loogilisse rühma ja sünkroonitud ühest põhikellast, kuid mitte tingimata sünkroonitud erinevasse domeeni kuuluvate kelladega.
lipud – See väli sisaldab erinevaid lippe sõnumi oleku tuvastamiseks.
parandusväli – sisaldab viiteaega nanosekundites. Viiteaeg sisaldab viivitust läbipaistva kella kaudu edastamisel, samuti viivitust kanali kaudu edastamisel, kui kasutatakse Peer-to-Peer režiimi.
sourcePortIdentity – see väli sisaldab teavet selle kohta, millisest pordist see teade algselt saadeti.
järjestuse ID – sisaldab üksikute sõnumite identifitseerimisnumbrit.
kontrollväli – artefaktiväli =) See jääb standardi esimesest versioonist ja sisaldab teavet selle teate tüübi kohta. Põhimõtteliselt sama mis messageType, kuid vähemate valikutega.
logMessageInterval – see väli määratakse sõnumi tüübi järgi.
Keha
Nagu eespool mainitud, on sõnumeid mitut tüüpi. Neid tüüpe kirjeldatakse allpool:
Teadaanne
Teateteadet kasutatakse teistele sama domeeni kelladele selle parameetritest teavitamiseks. See teade võimaldab teil seadistada hierarhia Master Clock – Slave Clock.
Sünkrooni sõnum
Sünkroonimissõnumi saadab põhikell ja see sisaldab põhikella aega sünkroonimissõnumi loomise ajal. Kui põhikell on kaheastmeline, seatakse sünkroonimissõnumi ajatempel 0-le ja praegune ajatempel saadetakse seotud Follow_Up-sõnumis. Sünkroonimissõnumit kasutatakse mõlema latentsusaja mõõtmise mehhanismi jaoks.
Sõnum edastatakse multisaate abil. Soovi korral saate kasutada Unicasti.
Delay_Req teade
Sõnumi Delay_Req vorming on identne sünkroonimissõnumiga. Alamkell saadab Delay_Req. See sisaldab aega, millal alamkell saatis Delay_Req. Seda teadet kasutatakse ainult viivituse päringu-vastuse mehhanismi jaoks.
Sõnum edastatakse multisaate abil. Soovi korral saate kasutada Unicasti.
Follow_Up sõnum
Teate Follow_Up saadab valikuliselt põhikell ja see sisaldab saatmise aega Sõnumite sünkroonimine meister. Ainult kaheastmelised peakellad saadavad teate Follow_Up.
Teate Follow_Up kasutatakse mõlema latentsusaja mõõtmise mehhanismi jaoks.
Sõnum edastatakse multisaate abil. Soovi korral saate kasutada Unicasti.
Delay_Resp sõnum
Teate Delay_Resp saadab põhikell. See sisaldab aega, mil põhikell võttis vastu Delay_Req. Seda teadet kasutatakse ainult viivituse päringu-vastuse mehhanismi jaoks.
Sõnum edastatakse multisaate abil. Soovi korral saate kasutada Unicasti.
Pdelay_Req teade
Pdelay_Req sõnumi saadab seade, mis taotleb viivitust. See sisaldab aega, mil sõnum selle seadme pordist saadeti. Pdelay_Req kasutatakse ainult naaberviivituse mõõtmise mehhanismi jaoks.
Pdelay_Resp sõnum
Pdelay_Resp sõnumi saadab seade, mis on saanud viivituse taotluse. See sisaldab aega, millal see seade Pdelay_Req sõnumi vastu võttis. Pdelay_Resp teadet kasutatakse ainult naaberviivituse mõõtmise mehhanismi jaoks.
Sõnum Pdelay_Resp_Follow_Up
Pdelay_Resp_Follow_Up sõnumi saadab valikuliselt seade, mis on viivitustaotluse vastu võtnud. See sisaldab aega, millal see seade Pdelay_Req sõnumi vastu võttis. Pdelay_Resp_Follow_Up sõnumit saadavad ainult kaheastmelised peakellad.
Seda teadet saab ajatempli asemel kasutada ka täitmisaja jaoks. Täitmisaeg on aeg Pdelay-Req vastuvõtmise hetkest kuni Pdelay_Resp saatmiseni.
Pdelay_Resp_Follow_Up kasutatakse ainult naaberviivituse mõõtmise mehhanismi jaoks.
Haldussõnumid
PTP juhtsõnumid on vajalikud teabe edastamiseks ühe või mitme kella ja juhtsõlme vahel.
Transfeer LV-sse
PTP-sõnumit saab edastada kahel tasemel:
- Võrk – osana IP-andmetest.
- Kanal – Etherneti raami osana.
PTP sõnumite edastamine UDP kaudu üle IP Etherneti kaudu
PTP üle UDP Etherneti kaudu
Profiilid
PTP-l on üsna palju paindlikke parameetreid, mida tuleb konfigureerida. Näiteks:
- BMCA valikud.
- Latentsuse mõõtmise mehhanism.
- Kõigi konfigureeritavate parameetrite intervallid ja algväärtused jne.
Ja hoolimata asjaolust, et me varem ütlesime, et PTPv2 seadmed ühilduvad üksteisega, pole see tõsi. Seadmetel peavad suhtlemiseks olema samad sätted.
Seetõttu on olemas nn PTPv2 profiilid. Profiilid on konfigureeritud sätete ja määratletud protokollipiirangute rühmad, et aja sünkroonimist saaks konkreetse rakenduse jaoks rakendada.
IEEE 1588v2 standard ise kirjeldab ainult ühte profiili – “Vaikeprofiil”. Kõik muud profiilid loovad ja kirjeldavad erinevad organisatsioonid ja ühendused.
Näiteks toiteprofiili ehk PTPv2 toiteprofiili lõid IEEE Power and Energy Society toitesüsteemide edastamise komitee ja alajaamakomitee. Profiili enda nimi on IEEE C37.238-2011.
Profiil kirjeldab, et PTP-d saab üle kanda:
- Ainult L2 võrkude kaudu (st Ethernet, HSR, PRP, mitte-IP).
- Sõnumeid edastatakse ainult multisaadete kaudu.
- Viivituse mõõtmise mehhanismina kasutatakse partnerite viivituse mõõtmise mehhanismi.
Vaikimisi domeen on 0, soovitatav domeen on 93.
C37.238-2011 disainifilosoofia oli vähendada valikuliste funktsioonide arvu ja säilitada ainult vajalikud funktsioonid usaldusväärseks seadmetevaheliseks suhtluseks ja süsteemi stabiilsuse suurendamiseks.
Samuti määratakse sõnumi edastamise sagedus:
Tegelikult on valimiseks saadaval ainult üks parameeter - peamise kella tüüp (üheastmeline või kaheastmeline).
Täpsus ei tohiks olla suurem kui 1 μs. Teisisõnu võib üks sünkroonimistee sisaldada maksimaalselt 15 läbipaistvat kella või kolme piirkella.
Allikas: www.habr.com