Implementation of a configuration server for a hardware SNTP synchronization platform based on FPGA

IMPLEMENTATION OF A CONFIGURATION SERVER FOR A HARDWARE SNTP SYNCHRONIZATION PLATFORM BASED ON FPGA J. Qui os, J. Viejo, A. Millan, A. Mu˜ noz, J. I. Villa and D. Gue e o G upo ID2 (In es igaci´ on y Desa ollo Digi al) Depa amen o de Tecnolog´ ıa Elec ´ onica - Uni e sidad de Se illa E. T. S. Ing. In o m´ a ica, Campus Uni e si a io Reina Me cedes 41012 Se illa (SPAIN) Email: jqui os@d e.us.es, [email p o ec ed], amilla[email p o ec ed], am i e a@d e.us.es, [email p o ec ed], gue e@d e.us.es ABSTRACT This pape p esen s he implemen a ion o a configu a ion se e o a SNTP synch oniza ion pla o m which imple- men s accu a e synch oniza ion solu ions o Remo e Te - minal Uni s commonly used in indus ial con ol p ocesses. The configu a ion se e p o ides se ings o o he s pla - o m de ices using he BOOTP p o ocol and an in e ace ha allow o adminis e he sys em. This en i onmen e- qui es a compac (specific dimensions) and low powe and low cos de ice. Thus, a gene al pu pose de ice (e.g. a PC) is disca ded and an embedded one wi h hese ea u es has been de eloped. Howe e , in addi ion o hese equi emen s i o e s a flexibili y simila o he PC. The eby i is able o upda e and ca y ou asks beyond synch oniza ion pla o m easily. 1. INTRODUCTION The ime synch oniza ion is c i ical in a g ea wide indus- ial p ocesses. Depending on he applica ion, a p ecision o up o ew mic oseconds can be equi ed. This p oblem has been ackled by he indus y, which has de eloped sys ems o esol e i . Howe e , hese solu ions a e based on so - wa e and need complex and expensi e ha dwa e o achie e an accep able accu acy. In his sense, a synch oniza ion pla o m based on he indus y no m IEC 61850 [1], which defines he Simple Ne - wo k Time P o ocol (SNTP) [2] o e E he ne as a s anda d way o synch onize a se o subs a ions wi h a ime se e , has been ully de eloped in ha dwa e, achie ing a low cos and powe , compac and accu a e pla o m which p o ides synch oniza ion in he ange o he mic oseconds [3,4]. The SNTP synch oniza ion pla o m consis s o h ee ypes o de ices: SNTP se e , SNTP clien and configu- a ion se e (Fig. 1). I can be used in indus ial en i- onmen s whe e he e a e se e al Remo e Te minal Uni s ��� ��� ��� ���� ������ ���� ������ ���� ������ ���� ����� ��� ��� ���� ����� ���� ����� ���� ����� ���� ��� ��� ��� ��� ��������������� ����������������� ������������� ����������������� ������� �������� ������������� ������ Fig. 1. Typical scena io o deploying ha dwa e SNTP clien and se e s (synch oniza ion de ices and p o ocols a e ma ked in g ay, and configu a ion de ices and p o ocols a e ma ked in black). (RTUs) which equi e ime synch oniza ion. The SNTP se - e ecei es accu acy ime in o ma ion om a Global Po- si ioning Sys em (GPS) de ice. The SNTP clien s in u n synch onize wi h he se e h ough Local A ea Ne wo k (LAN) using he SNTP p o ocol, and ansmi he ime in- o ma ion o RTUs emula ing a GPS de ice: SNTP clien s gene a e he GPS signals equi ed, Pulse pe second (PPS) signal and Recommended Minimum Na iga ion In o ma- ion (RMC) ame [5,6]. SNTP is a p o ocol o he Applica ion Laye o he TCP/IP model. The eby a co ec configu a ion o he lowe laye s (Ne wo k In e ace, In e ne and T anspo ) is necessa y o a success ul communica ion. Media Access Con ol (MAC) add ess is assigned and s o ed a bi s eam gene a ion ime and he NTP s anda d po (123 UDP) is used. Thus, In e - ne Laye configu a ion is only needed o be configu ed a ope a ion ime. The configu a ion equi ed by he commu- nica ion be ween GPS and SNTP se e is he de aul speed o he se ial po used o ansmi RMC ame and when he PPS signal indica es he s a o a second: ising o alling edge. When he SNTP clien emula es he GPS, he s a o a second is always indica ed by he ising edge o he PPS signal, so he de aul speed o he se ial po is jus needed. The e o e, i is necessa y a me hod o configu e all pla - o m de ices. Because all pla o m de ices a e connec ed h ough E he ne , Boo s ap P o ocol (BOOTP) will be he p o ocol used o his pu pose. This unc ionali y is imple- men ed by he configu a ion se e , which mus ha e he same ea u es han he pla o m de ices. In his way, he design can be based on a gene al pu pose de ice (e.g. a PC) o on a dedica ed one. The fi s is mo e expensi e and highe powe consume han a dedica ed de ice, u he mo e adap - ing i o specific dimensions is mo e di ficul han he las one. The eby, an embedded de ice is he bes op ion, bu a ully ha dwa e implemen a ion is inflexible: i o en p esen s long de elopmen and suppo ime and cos . So ha , he configu a ion se e implemen a ion is based on a Sys em on Chip (SoC) design which sha e he bes ea u es o he las wo designs men ioned. On he one hand, i p esen s a flexibili y simila o a PC: educed de elopmen ime and cos , i is easily upda ed and e en o being able o ca y ou unc ionali ies beyond he synch oniza ion pla o m. On he o he hand, i is an embedded de ice, so i ulfills powe con- sump ion and size eque imen s. Mo eo e , he cos can be educed i he de eloped design sha es mos ha dwa e ele- men s wi h o he pla o m de ices. This pape desc ibes he configu a ion se e implemen- a ion and is o ganized as ollows: in sec ion 2 some con- cep s o BOOTP p o ocol a e p esen ed, sec ion 3 enume - a es he de ice specifica ions, sec ion 4 gi es some design and implemen a ion de ails, sec ion 5 includes some esul s, and sec ion 6 discusses some conclusions. 2. BASIC CONCEPTS OF BOOTP PROTOCOL The BOOTP is a ne wo k p o ocol based on he clien -se e model, and i is used by a de ice (clien ) o ob ain i s In e ne P o ocol (IP) se ings [7]. I s de ailed ope a ion is desc ibed below (Fig. 2). When a clien needs IP configu a ion i sends a BOOTP eques wi h he b oadcas add ess as des ina ion add ess. This packe is ecei ed and p ocessed by he BOOTP se e , which keeps a pool o se ings. I i has an en y o his clien , which is iden ified wi h i s MAC add ess, he se e will send a BOOT eply wi h he clien IP se ings. O he - wise, he se e will no answe (Fig. 2). This p o ocol p o- ����� ������ ����� ��� ����������� �������� �� ���� ������������� ��� ������������ ������ ��������� ���� � ����� ����������������� �� ������� ����� ������� ��� ����� ������� ����� ����� ����� ������ ����� ������ �� Fig. 2. Ope a ion o he BOOTP P o ocol. ides no only IP se ings, he packe o ma includes o he configu a ion fields [7, 8] as he boo file name used o boo h ough ne wo k. His o ically, his p o ocol has been used by de ices a s a ing up ime o ob ain he needed se ings o connec a se e and download he Ope a i e Sys em (OS) image o execu e i . Mo eo e , he BOOTP p o ocol can be used o ob ain only an IP configu a ion and he eques s can be sen by a clien any ime. In his way, a dynamic IP add ess assignmen can be implemen ed sending pe iodic BOOTP eques s, al hough he p o ocol was designed o p o ide a s a ic IP add ess assignmen . Nowadays, ano he p o ocol has limi ed he use o BOOTP: Dynamic Hos Configu a- ion P o ocol (DHCP) [9]. I o e s mo e unc ionali y han BOOTP (e.g. dynamic IP add ess assignmen ), bu i s imple- men a ion is mo e complex. Howe e , DHCP and BOOTP can be used in he same ne wo k because mos DHCP se e s a e compa ible wi h BOOTP. In ou pla o m, he SNTP clien s and se e a e ully implemen ed in ha dwa e, so he BOOTP is he configu a ion p o ocol chosen because i educes he complexi y and implemen a ion ime. Fu he - mo e, i is possible o modi y some aspec s o he p o ocol o ansmi mo e in o ma ion wi h minimal changes in he clien s. 3. SYSTEM SPECIFICATION The objec i e is o de elop a configu a ion se e which ha e o es ablish wo p ocesses o communica ion. On he one hand, i will configu e he o he de ices o he pla o m using he BOOTP p o ocol h ough he LAN. On he o he hand, i will allow o adminis e he sys em h ough an use in e ace. Below a mo e de ailed sys em specifica ion is lis ed: •The configu a ion se e ha dwa e mus be as simila as possible o SNTP clien /se e ha dwa e. In his sense, he same ha dwa e design, which is based on a SPARTAN-3E XC3S500E FPGA, has been used. The e o e, i was jus necessa y o add a FLASH me- mo y (non- ola ile memo y) and a SDRAM memo y module in o de o achie e a ha dwa e which be able o un an OS. The eby a mo e flexible, cheape and easie o assembly ha dwa e is ob ained, due o all ha dwa e design is eused, adding he needed memo- ies is conside ed as an assembly op ion, and any pla - o m de ice can be implemen ed on he se e ha d- wa e, i is only necessa y o change he design syn he- sized on FPGA. •The SoC will be implemen ed on FPGA. An OS will be execu ed by i o achie e a educ ion in he de el- opmen and suppo ime. •The BOOTP p o ocol will be used in he communica- ion wi h SNTP clien s and se e . So, he se e has o execu e a BOOTP se e . •The de ice will adminis e he synch oniza ion pla - o m h ough a web applica ion. A HTTP se e is equi ed o his pu pose. •The implemen ed web applica ion mus ha e he ol- lowing ea u es: –I will be based on configu a ion p ofiles. –I will check and e i y new se ings. –I will s o e all se ings in a non- ola ile me- mo y. •The de ices will be iden ified by i s MAC. The e o e, he se e has o emembe he MAC o all de ices ha send a BOOTP eques and has no been config- u ed p e iously. •The in e connec ion be ween adminis a ion in e ace (web applica ion), BOOTP se e and HTTP se e mus be implemen ed. In ha way, he sys em will be au onomous. The de eloped de ice con o ms wi h hese eque imen s and, in addi ion, i is possible o add new uncionali ies o i . In he nex sec ions, he de elopmen and he esul s o he configu a ion se e a e showed. 4. SYSTEM DESIGN AND IMPLEMENTATION The ha dwa e is based on a SPARTAN-3E XC3S500E FPGA. The SoC syn hesized on his de ice has been designed wi h XPS so wa e and i is based on XILINX IP Co es which a e op imized o be implemen ed on XILINX de ices, so Mi- c oBlaze is he sys em p ocesso . Pe alinux has been he chosen embedded Linux dis ibu ion and uClinux [10] he Linux ke nel. The se e unc ionali y is implemen ed in so wa e whe- e is di ided in o h ee modules which a e de ailed below (Fig. 3). Adminis a ion in e ace makes up he fi s module. This communica ion is based on a web applica ion using he HTTP p o ocol. Thus, he configu a ion in o ma ion is adminis- e ed h ough a web b owse . Two Common Ga eway In e - aces (CGIs) ha e been de eloped in C: one o hem (Load CGI) s a s he p ocess sending he web applica ion and he cu en sys em configu a ion, and he second one (Apply CGI) ecei es, checks and applies he modifica ions. All he se - ings a e checked in he applica ion (clien side) as well. This las ea u e is implemen ed in Ja aSc ip using he jQue- y lib a y o achie e a c oss-b owse code. When he new configu a ion is comple ed, his applica ion sends and se s i up educing he amoun o FLASH w i ings (in e media e se ings a e no sa ed). Finally, he h pd web se e has been he HTTP web se e used. The second module consis s o he in e ace be ween se - e and o he s pla o m de ices. The se ings p o ided by he se e depends on he ype o de ice: SNTP se e o clien . In e ne Laye configu a ion and de aul speed se ial o he po a e equi ed by hem bo h. In addi ion o hese se ings, SNTP se e needs he ac i e edge o he PPS sig- nal, and he SNTP clien needs he SNTP se e IP add ess and he in e al ime be ween SNTP eques s. The BOOTP p o ocol is used o his pu pose. The packe o ma defined by his p o ocol has fields o ansmi In e ne Laye configu- a ion (IP add ess, ne mask, and de aul ga eway), bu i do no ha e fields o pla o m specific in o ma ion. Howe e , his se ings a e send in he boo file name field. The se ings a e ansmi ed as a s ing o hexadecimal digi s codified as ASCII cha ac e s which will be di e en depending on he ype o de ice. This me hod only modifies he seman ic o a field p oducing alid BOOTP packe s. So he se e can ope a e wi h s anda d BOOTP clien s. The In e ne Sys ems Conso ium (ISC) DHCP so wa e, which is a DHCP and BOOTP se e , is he BOOTP se e used. Finally, he hi d module defines he in e connec ion be- ween he wo in e aces p e iously desc ibed (Fig. 3). In his sense, web applica ion mus be able o ead and modi y he cu en se ings, which a e used by he BOOTP se e o configu e he pla o m de ices. These se ings a e sa ed in he BOOTP se e configu a ion file, which is loca ed on he non- ola ile memo y. A s a ing up ime, he se e checks and e ifies his file o insu e he sys em ope a ion. The unc ionali y o showing he cu en configu a ion is imple- men ed by he Load CGI, which eads and pa ses his file. When he web applica ion sends new se ings o be sa ed ���� ������������ ���� ������������ ���� ������� ���� ������� ����� ��� ������ �������� ����� ��� ����� ������ ����� ������ ������������������ ���� ����������� ����� ������� �������� ������������� ����� ����� ��� �� ������������� ����� ��� �������� ������ � ������ � ������ � Fig. 3. O e all diag am o he configu a ion se e ope a ion. and applied, Apply CGI checks he alidi y and cohe ence o he new configu a ion and hen gene a es he new BOOTP se e configu a ion file. Mo eo e , he se e mus sa e all add esses o pla o m de ices, because he de ices a e iden- ified wi h i s MAC add ess. In his way, he MAC o he known de ices a e loca ed in he BOOTP se e configu a- ion file. I an unknown de ice sends a BOOTP eques i s add ess has o be sa ed. The BOOTP se e has been con- figu ed o send log in o ma ion o syslog daemon, which in u n w i es his in o ma ion o a log file. Load CGI eads and pa ses his file o show unknown de ices add esses. Fu he - mo e, he sys em shows he ela i e and absolu e da e and ime o he fi s BOOTP eques o each de ice. 5. RESULTS In his sec ion, ha dwa e and so wa e implemen a ion e- sul s a e desc ibed in some de ail. Resou ce Usage (%) Slices 4238 (91%) Slices Flip Flops 4958 (53%) 4 Inpu LUTs 7444 (79%) Bonded IOBs 75 (47%) Block RAMs 19 (95%) GCLKs 6(25%) Maximum ope a ion equency 75.857 MHz Table 1. Ha dwa e implemen a ion esul s on SPARTAN-3E XC3S500E. 5.1. Ha dwa e esul s The SoC design has been implemen ed on a SPARTAN-3E XC3S500E FPGA. The Table 1 shows he design esul s. The maximum ope a ion equency (75 MHz) is enough, due o i is o e PCB clock equency (50 MHz). I is e- ma kable ha 95% o Block RAMs a e used by he design. The e o e, he Memo y Managemen Uni (MMU) suppo in Mic oBlaze P ocesso can no be used, due o he ac Usage o RAM memo y To al usage o RAM memo y I em Maximum memo y usage in KB (%) To al Memo y 28900 (100%) Wa ing a BOOTP/HTTP eques 11344 (39.25%) Maximum load (Sa ing se ings) 11628.28 (40.24%) Usage o RAM memo y by p ocesses P ocess Maximum memo y usage in KB (%) BOOTP se e 578.336 (2.00%) HTTP se e 292.916 (1.01%) Load CGI 141.492 (0.49%) Sa e GCI 271.248 (0.94%) To al 1283.992 (4.44%) Usage o FLASH memo y Usage o FLASH memo y I em Memo y usage in KB (%) To al Memo y 15625 (100%) Sys em loade 800 (5.12%) Ope a i e Sys em 4000 (25.6%) Use Flash pa i ion 8000 (51.2%) To al 12800 (81.92%) Table 2. Usage o RAM and FLASH memo y. ���� ������ � ���� ������ � ���� ������ � ���� ������ � ������ ������������� ������ ���� ������ ������� �������� ��� Fig. 4. En i onmen used o es he configu a ion se e . ha ou addi ional Block RAMs a e equi ed o his pu - pose. Fo his eason a non-MMU suppo Linux Ke nel (uClinux) has been used. This is because he se e ha d- wa e should be as simila as possible o ha dwa e o o he pla o m de ices, and a low cos FPGA is used by hem. I he immedia ely abo e de ice in he Spa an-3E amily is chosen, he Mic oBlaze P ocesso wi h MMU suppo may be syn hesized and a ull Linux ke nel (wi h MMU suppo ) may be used. Mo eo e , he usage o Slices will be below 50% and i would be possible o syn hesize o he ha dwa e unc ionali ies on he same de ice. 5.2. So wa e esul s The en i onmen whe e he es s ook place is showed by Fig. 4, whe e all de ices we e u ned on and he se ings we e modified along he ime o check s abili y, possible e - o s and memo y usage o he sys em. Fig. 5 shows he web in e ace o he configu a ion se e . The CPU esul s a e no ele an because he configu a ion p ocess is no a c i - ical ask, so hey a e omi ed. Rega ding o RAM memo y usage (Table 2), i is ema kable ha mo e han 50% o he a ailable memo y is ee. This ac allows o add new so - wa e implemen ed unc ionali ies o he sys em. The 82% o FLASH memo y is used by he sys em (Table 2). How- e e , he use FLASH pa i ion size can be educed i mo e FLASH memo y is equi ed by he OS image. Se ings o a new de ice equi e ≈99 by es and o a new configu a- ion p ofile ≈64 by es. The eby, i pa i ion size is educed by hal , he sys em can con inue wo king, bu a fi size can educe he FLASH li e. 6. CONCLUSION The design and implemen a ion o a configu a ion se e o he SNTP synch oniza ion pla o m has been p esen ed. I has been based on a SoC syn hesized on a FPGA, which exe- cu es an OS. The unc ionali y is implemen ed in so wa e o achie e a flexible, low powe and low cos and compac de- ice ha i is no limi ed o he pla o m en i onmen being able o ca y ou asks beyond i . Fig. 5. Web in e ace o he configu a ion se e . 7. ACKNOWLEDGMENT This wo k has been pa ially suppo ed by he Minis y o Educa ion and Cul u e o he Spanish Go e nmen h ough he TEC2007-61802/MIC (HIPER) p ojec and he PROFIT- MITC SEPIC TSI-020100-2008-258 p ojec . 8. REFERENCES [1] H. Dawidczak, “IEC 61850 Communica ion Ne wo ks and Sys ems In Subs a ions,” In e na ional Elec o echnical Com- mission and Technical Commi ee 57, 1995. [2] D. Mills, “Simple Ne wo k Time P o ocol (SNTP) Ve sion 4 o IP 4, IP 6 and OSI,” In e ne Enginee ing Task Fo ce (IETF), RFC 4330 (In o ma ional), Jan. 2006. [3] J. Viejo, J. Juan, M. J. Bellido, E. Os ua, A. Millan, P. R. de Cla ijo, A. Mu˜ noz, and D. Gue e o, “Design and imple- men a ion o a SNTP clien on FPGA,” in P oc. 2008 IEEE In e na ional Symposium on Indus ial Elec onics (ISIE), Camb idge (Uni ed Kingdom), July 2008. [4] J. Viejo, J. Juan, E. Os ua, M. J. Bellido, A. Millan, A. Mu˜ noz, and J. I. Villa , “Accu a e and compac implemen- a ion o a ha dwa e SNTP Clien ,” in P oc. 15 h Ibe chip Wo kshop (IWS), Buenos Ai es (A gen ina), Ma . 2009. [5] J. Qui os, J. Viejo, A. Mu˜ noz, A. Millan, E. Os ua, and J. I. Villa , “Implemen aci´ on sob e FPGA de un clien e SNTP us- ando Mic oBlaze,” in P oc. 16 h Ibe chip Wo kshop (IWS), Iguazu Falls (B azil), Feb. 2010. [6] E. Os ua, M. J. Bellido, J. Viejo, A. Millan, A. Mu˜ noz, and D. Gue e o, “Aplicaci´ on de Picoblaze como Emu- lado /Recep o de un GPS en el dise˜ no ha dwa e de un clien e/se ido SNTP,” in 9 h Jo nadas de Compu aci´ on Re- configu able y Aplicaciones (JCRA), Mad id (Spain), Sep . 2009. [7] W. J. C o and J. Gilmo e, “Boo s ap P o ocol,” In e ne Enginee ing Task Fo ce (IETF), RFC 951 (D a S anda d), Sep . 1985, upda ed by RFCs 1395, 1497, 1532, 1542. [8] R. D oms and S. Alexande , “DHCP Op ions and BOOTP Vendo Ex ensions,” In e ne Enginee ing Task Fo ce (IETF), RFC 2132 (S anda ds T ack), Ma . 1997. [9] ——, “Dynamic Hos Configu a ion P o ocol,” In e ne En- ginee ing Task Fo ce (IETF), RFC 2131 (DRAFT STAN- DARD), Ma . 1997. [10] R. Klenke, “Expe iences using he xilinx mic oblaze so - co e p ocesso and uclinux in compu e enginee ing caps one senio design p ojec s,” in Mic oelec onic Sys ems Educa- ion, 2007. MSE ’07. IEEE In e na ional Con e ence on, June 2007, pp. 123 – 124.