București, 2016 [606176]
București, 2016
Universitatea Politehnica București
Facultatea de Automatică și Calculatoare
Departamentul de Automatică și Informatică Industrială
LUCRARE DE LICENȚĂ
Sincronizarea unui cluster cu comunicație de
tip Ethernet determinist
Coordonator Absolvent: [anonimizat]. Nicolae Maximilian Corbu Mihaela
2
CUPRINS
Capitolul 1. Introducere ………………………….. ………………………….. ………………………….. ………….. 3
Capitolul 2. Considerente asupra sincronizării sistemelor la pornire ………………………….. ……… 7
Capitolul 3. Definirea problemei ………………………….. ………………………….. ………………………….. 9
Capitolul 4. Implementare și tehnologii utilizate ………………………….. ………………………….. ….. 15
4.1. Echipamente fizice ………………………….. ………………………….. ………………………….. ……… 15
4.1.1. Instalare Cygwin ………………………….. ………………………….. ………………………….. ….. 18
4.2. Implementare ………………………….. ………………………….. ………………………….. …………….. 20
4.2.1. Modulul Synchronization Master ………………………….. ………………………….. ………… 24
4.2.2. Modulul Compression Master ………………………….. ………………………….. …………….. 30
4.2.3. Script run_SI.sh ………………………….. ………………………….. ………………………….. ……. 40
4.2.4. Script extractTransitions.py ………………………….. ………………………….. ……………….. 42
Capitolul 5. Funcționarea sistemului/ Testare și verificare ………………………….. ………………… 45
Capitolul 6. Rezultate ………………………….. ………………………….. ………………………….. …………… 57
Capitolul 7. Concluzii ………………………….. ………………………….. ………………………….. …………… 58
Bibliografie ………………………….. ………………………….. ………………………….. …………………………. 59
Anexe ………………………….. ………………………….. ………………………….. ………………………….. …….. 60
3
Capitolul 1. Introducere
În zilele noastre cunoașterea limitărilor de timp și a întârzierilor dintr -o comunicație
este o necesitate, de aceste două lucruri depinzând foarte multe aplicații și echipamente. Astfel
determinismul în orice domeniu începe să devină o ceri nță obligatorie.
Termenul de determinism se referă la comunicații, înțelegând prin determinism faptul
că putem determi na întârzierea maximă a datelor, î n orice moment de timp . Aplicând anumiți
stimuli , obținem același rezultat într-un interval de timp rez onabil. Determinismul n u depinde
foarte mult de stările anterioare ale sistemului .
Lucrarea de față are ca scop prezentarea determinării și sincronizării parametrilor unui
cluster cu comunicație de tip Ethernet determinist în limbajul SAL.
Ethernet -ul de terminist este o tehnologie nouă de comunicare în rețea care utilizează
planificarea în timp /calendar de evenimente pentru a aduce comunicațiile de timp real
deterministe la standardul IEEE 802 Ethernet.
Pornind de la acest lucru compania T TTech [1] a dezvoltat TTEthernet.
TTEthernet este o tehnologie nouă de comunicație ce face posibilă utilizarea unei
singure rețele fizice pentru aplicații distribuite cu cerințe critice mixte, mai exa ct sisteme cu
cerințe critice mixte, de exemplu subsistemul de comandă și control sau aplicațiile audio/video.
Sistemele cu cerințele critice mixte sunt acele sistem care conțin un hardware și un software
ce pot executa în același timp mai multe aplicații de diferite grade de criticitate sau diferite
niveluri de siguranță. Acest lucru se realizează printr -o strategie de sincronizare tolerantă la
erori, care stabilește partiționarea temporală.
Sistemele complexe moderne, cum ar fi cele amplasate pe aeronav e și vehicule spațiale,
combină o multitudine de aplicații distribuite care au diferite cerințe de comunicare. Aceste
sisteme sunt numite sisteme critice mixte.
Prezent lucrare își propune să descrie o imagine de ansamblu asupra tehnologiei
TTEthernet și să evidențieze problema sincronizării, tratând aspectele toleranței la erori a unei
componente , și anume end -system -ul, și formulând ipoteze pentru sincronizarea sistemului și
în cazul în care eroare apare la unul din cele 2 switch -uri. Acest lucru s -a rea lizat cu ajutorul
modelului de verificare /emulare SAL de la SRI International.
4
SAL este acronimul de la Symbolic Analysis Laboratory, și reprezintă un cadru de
dezvoltare ce îmbină diferite module pentru abstractizare, analiză de program, demonstrare de
teoreme, și model de verificare ce ia în considerare proprietățile sistemelor de tranziție. O parte
esențială a acestui framework o reprezintă limbajul folosit pentru a descrie sistemele de
tranziție. Acest limbaj este folosit ca limbaj de specificare și ser vește ca sursă comună pentru a
îmbina diferite tool -uri de analiză. El este asemănător unui traducător deoarece poate
transforma din limbajul SAL în formatul de intrare al unui program și din formatul de ieșire al
unui program în formatul de intrare al limbajului SAL.
Limbajul SAL a fost inițial creat într -o colaborare cu David Dill de la Universitatea
Stanford și Thomas Henzinger de la Universitatea din California, Berkeley. Ultima versiune
lansată și cu care s-a lucrat în ace st proiect este cea folosită de către SRI International, și anume
SAL 3.3. Aceasta este open -source [2]
Pentru a putea utiliza resursele mai eficient, tendința în zo na industrială este aceea de a
folosi arhitecturi integrate. Ca rezultat, diverse aplicații cu cerințe diferite de comunicare vor
împărți aceeași rețea fizică. Acest lucru necesită o nouă infrastructură integratoare de
comunicații care să asigure partițion area între nivelurile critice păstrând în același timp lățimea
de bandă suficient de sustenabilă. TTEthernet este o astfel de infrastructură integratoare de
comunicații. Una dintre primele aplicații în care s -a folosit această ar hitectură este proiectul
ORION[3]. TTEthernet ca infrastructură de comunicații integrate oferă o reducere
semnificativă a componentelor și a cablajului în comparație cu programele spațiale an terioare.
Pentru a oferi o idee asupra conținutului lucrării, se va introduc e în cele ce urmează
noțiunea de cluster.
Clusterul este reprezentat de un grup de calculatoare interconectate, ce sunt văzute
funcționând ca un singur sistem. Fiecare computer din cluste r îndeplinește aceeași sarcină, și
este controlat și programat software, astfel încât totul să funcționeze corect. De obicei
calculatoarele dintr -un cluster sunt conectate printr -o rețea locală de mare viteză, facilitând
comunicarea. Toate compo nentele folosesc aceeași structură hardware dar și același sistem de
operare. Există și cazuri când sistemul de operare diferă pentru fiecare componentă.
În cazul clusterului din lucrare, end -system -urile au aceeași structură hardware și
rulează toate Linux, dar fiecare componentă are o funcționalitate bine definită. Astfel pentru
transmisia audio -video din lucrare, cu câte două componente alocate fiecărei părți, o
componentă reprezintă Audio Serverul, alta este Audio Clientul, o a treia componentă este
reprezentată de Video Server, care reprezintă și cea mai importantă parte a celor patru end –
5
system -uri de ea depinzând celelalte , și ultima componentă o constituie Video Client -ul. Video
Client este o componentă importantă de asemenea , pe el având loc rulare a programului final și
observarea situațiilor critice și toleranța la erori a sistemului.
Cluster -ul este o rețea de dimensiune variabilă ce folosește diferite protocoale de
comunicație.
Rețelele de calculatoare au apărut datorită progresului tehnologiei și a nevoi de
colectare, prelucrare și distribuire a informației rapidă.
O rețea de calculatoare reprezintă o colecție de calculatoare autonome interconectate
prin intermediul unor medii de comunicație, asigurând folosirea în comun, de către un mare
număr de utilizatori, a tuturor resurselor fizice, logice și informaționale ale ansamblului .
Interconectarea între două calculatoare presupune existența posibilității de a putea face schimb
de informație între ele. Conectarea lor se poate face prin mai multe metode, cum ar fi cablul de
cupru sau fibra optică.
Rețelele se folosesc de diferite protocoale pentru a comunica și a transmite date, printre
care se numără și TTP (Time -Triggered Protocol) și FlexRay [4]. Ambele sunt protocoale d e
rețea folosite pentru control accesului la mediu .
TTP a fost conceput ca o magistrală de date, cu 2 canale și p oate opera cu unul sau
ambele canale la viteză maximă, a cceptând și redundanța datelor.
În acest sens al doilea capitol detalia ză stadiul actual al cercetării în domeniu. Deși este
o tehnologie nouă pe piață și are rezultate bune, cercetarea și dezvoltarea ei continuă pentru a
o ține pasul cu tendințele și dezvoltarea industriei . În plus, lucrarea de față tratează doar o parte
din tehnologie și anume sincronizare cluster -ului c are are o componentă ce nu mai funcționează
la parametrii stabiliți .
Capitolul trei abordează problematica lucrării cu privire la sincronizarea fiecărei
componente . Se dorește ca în final tot cluster -ul să fie sincronizat și tolerant la erori.
Capitolul 4 descrie implementarea atât hardware a sistemului , cât și realizarea
programelor software ce au ca scop asigurarea funcționării corecte și în situații de eroare. Pentru
cazul implementării software se detaliaz ă câteva module și scripturi importante ale lucrării.
În capitol ul cinci este descrisă partea de testare și validare a programelor realizate și a
funcționării sistemului în diferite contexte.
6
Al șaselea capitol prezintă rezultatele simulării, în timp ce ca pitolul 7 cuprinde
concluziile asupra lucrării și sfaturi cu privire la evitarea diverselor probleme întâmpinate pe
parcursul dezvoltării, implementării și testării.
În final lucrării se vor regăsi bibliografia și anexele aferente.
7
Capitolul 2 . Considerente asupra sincronizării sistemelor la pornire
În lucrarea de față este abordată problema sincronizării sistemului la pornire și
menținerea lui în stare de funcționare corectă , chiar și în cazul în care un terminal cedează din
difer ite motive.
Dezvoltarea algoritmilor pentru sisteme distribuite tolerante la erori, cum este cazul
sistemelor utilizate pentru executarea unor funcții critice la bordul unui avion, nu este ușoară.
Astfel, metode formale au fost dezvoltate ca instrumente state-of-the-art pentru proiectarea
design -ului și verificare asistată de calculator.
TTEthernet a fost introdus prima dată în [5]. Acesta implementează un set de astfel de
algoritmi pentru a sincroniza o multitudine de ceasuri locale într -o rețea de calculatoare
distribuită. Acești algoritmi sunt standardizați în SAE AS 6802 și au fost dezvoltați utilizând
modulul de verificare SAL la partea de proiectare . Odată ce proiectarea algoritmilor a fost
făcută, aceștia au fost transformați manual în cerințe formale. Cerințele formale au constituit
punctul de plecare al DO -254 c a proces de dezvoltare care a dus la implementări reale ale
algoritmilor SAE6802.
Dintre algoritmii SAE6802 face parte și un algoritm numit algoritmul de pornire –
repornire . Acesta definește cum ceasurile locale ale sistemului distribuit sunt inițial sinc ronizate
unul cu altul, de exemplu la pornirea sistemului sau revenirea acestuia după o restartare. De
aceea, algoritmul de pornire/repornire este de o importanță maximă pentru funcționarea
sistemului.
Problema sincronizării unui sistem având o co mponentă defectă și comunicație
deterministă bazată pe protocolul TTP este discutată în [6]. Studiul introducerii unei defecțiuni
într-un sistem [7]a arătat că adăugarea de mecanismele adiționale, cum ar fi un nod central într –
o topologie de tip stea [8], face posibilă respectarea c erințelor de defectare din industria
aerospațială .
Pentru a sincroniza sistemul au fost făcute mai multe si mulări în simulatorul SAL -ului,
și după mai multe încercări de simulare, s -a ajuns la stabilirea numărului de pași necesari pentru
ca algoritmul să poată sincroniza sistemul , și anume: 110,115 și 120 de pași.
Simulările făcute pentru această lucrare s -au bazat pe metoda de cazuri de testare bazate
pe model [9], mai exact cazurile de testare rezultate sunt derivate dintr -un model care descrie
aspectele funcționale ale sistemului testat. Modelul a fost implementat și testat în SAL.
8
Această metodă are un avantaj major, deoarece orice modificare adusă modelului poate
fi testată imediat, problema însă o repr ezintă faptul că pentru un număr mare de pași de căutare
timpul de simulare este mare, uneori ajungând și la 15 ore. O altă problemă o reprezintă faptul
că fiecare m odificare adusă modelului oferă rezultate diferite la fiecare simulare.
Problema algoritmu lui de pornire/repornire pentru tehnologia TTEthernet este cercetată
încă din 2004. În acest an s -a realizat un model care a fost testat folosind metoda bazată pe
modul de emulare, verificare . Această metodă formală funcționează diferit față de cea bazată
pe model , mai exact explorează toate stările programului până când nu mai rămâne niciuna
neexplorată sau până când detectează o eroare.
Ambele metode sunt eficiente deoarece asigură căutare exhaustivă și necesită o
specificare a modelului cât mai explicită pentru a putea efectua testele aferente și a oferi un set
de rezultate.
9
Capitolul 3 . Definirea problemei
Problema principală a sincronizării parametrilor unui cluster Ethernet determinist o
reprezintă stabilirea calendarelor pentru fiecare componentă a cluster -ului, indiferent cât de
simplă sau complexă este structura acestuia.
Așa cum s -a precizat anterior, cluster -ul reprezintă o rețea cu dimensiune variabilă.
Fiind o re țea de calculatoare [10] acesta poate avea diferite forme, care se clasifică a stfel :
a) după tipul med iului de transmisie:
rețele cu fir – conectarea are loc prin cablu de cupru sau fibră optică
rețele wireless – transmisia are loc prin eter
b) după întinderea geografică, se împart în:
rețele locale sau LAN (Local Area Network) – se referă la rețelele care a u o
suprafața mică de transmitere, cum ar fi o cameră, un campus sau o clădire.
rețele metropolitane sau MAN (Metropolitan Area Network) – rețeaua are o
dimensiune mai mare decât LAN -ul, ea acoperind suprafața unui oraș sau a unei
metropole
rețele extinse sau WAN (Wide Area Network) – este o rețea care se realizează
prin interconectarea mai multor LAN -uri, întinzându -se pe suprafețe vaste și
făcând posibilă comunicarea a două calculatoare din orașe, țări sau continente
diferite.
c) după topologia fizică:
rețele bus – calculatoarele sunt așezate astfel încât cablurile să treacă de l a un
calculator la altul liniar, figura 3.1.
rețele stea – toate calculatoare se leagă la un hub central , figura 3.2.
rețele inel – ultimul conexiune se întoarce la prima și for mează un inel
rețele full mesh – fiecare nod este legat la t oate celelalte noduri din rețea
rețele plasă sau neregulate – este o combinație a celor de mai sus, figura 3.3 .
d) după tipul sistemului de operare de rețea:
TCP/IP
IPX/SPX
Apple Talk
e) După tehnologi a de transmisie avem:
rețele punct la punct
10
rețele cu difuzare
Fig. 3.1. Rețea de tip bus sau în linie ([11])
Fig. 3.2. Rețea de tip stea ([11])
Fig. 3.3 . Rețea tip neregulată sau plasă ([11])
11
Lucrarea de față tratează problemă sincronizării pe un cluster ce conține doar 6
componente și anume, 2 switch -uri numite Compression Master (CM), și 4 end -system -uri
numite Syncronization Master (SM) , cu ajutorul limbajului SAL.
Pentru realizarea comunicației între cele 6 sisteme și sincronizarea lor se utilizează
Deterministic Ethernet, tehnologie de comunicație în rețea ce folosește planificarea timpului
pentru a aduce comunicaț ia determin istă în timp real conform standardul ui IEEE 802 Ethernet.
Această tehnologie este introdusă de compania TTTech Computertechnik AG [1].
Compania se bazează pe două tehnologii cheie ce se folosesc de Ethernet și anume: Time –
Sensitive Networking și Time -Triggered Ethernet.
Time-Triggered Ethernet este un protocol de rețea stan dardizat de c ătre SAE
International, SAE AS6802 ce utilizează Ethernet pentru transmisia datelor ș i a pachetelor de
sincronizare/control . Time-Triggered Ethernet oferă , folos ind tehnologia clasică Ethernet ,
servicii ce ajută la îndeplinirea condițiilor critice de timp, deterministe sau de siguranță.
Time-Triggered Ethernet suportă trei tipuri de trafic de date :
Time -Triggered, se transmit în toată rețeaua la perioade bine definite și au o
prioritate ridicată față de celelalte tipuri de mesaje. Apariția mesajului,
întârzierea și precizia lui sunt predefinite și garantate. Întârzierile sunt minime
iar precizia temporală este pe cât posibil de exactă.
Rate-Constrained, este folosit pentru aplicații care nu necesită multă strictețe la
determinism și transmitere în timp real. Acest tip de trafic asigură că lățimea de
bandă este predefinită pentru fiecare aplicație și întârziere, și că abaterile
temporale au limite predefinite.
Best-Effort, urmează metoda c lasică a Ethernet -ului. Nu există nicio garanție
pentru când și dacă se transmit acest tip de trafic , ce întârzieri a u și dacă mesajul
a sosit la componenta care trebuia să îl recepționeze. Traficul Best -Effort
folosește lărgimea de bandă rămasă și are cea mai mică prioritate dintre toate
tipurile de trafic .
Fig. 3.5. Formatul mesajelor in TTEthernet (sursa: [12])
12
În figura 3.5 sunt ilustrate cele trei tipuri de mesaje diferite care există într -o rețea
Ethernet.
Pe lângă tipurile de trafic, TTEthernet introduce și o strategie de sincronizare ce se
folosește de cadre Protocol Control Frame (PCF) [13] care sunt interschimbate între participanții
la comunicație. PCF -urile sunt transmise pe aceleași fire pe care se transmite și fluxul de date.
Structura unui astfel de PCF este prezentată în figura 3. 6.
Fig. 3. 6. Format cadru PCF (sursa: [13])
Acest pachet are un câmp numit transparent clock , în care toate componentele unei
rețele își adaugă întârzierea impusă de PCF pe care îl au. Prin urmare, atunci când o componentă
primește un Protocol Control Frame, știe cât timp cadrul a stat în rețea după valoarea găsită în
câmpul transparent clock. Acest câmp are de obicei valoarea exactă, singurele cazurile în care
avem erori sunt cele în care are loc depășirea limitelor de timp. Pe lân gă transparent clock, PCF
mai are o funcție numită „permanence function”. Aceasta știe cazul cel mai grav de întârziere
al unui cadru PCF în rețea .
13
Această tehnologie este nouă și a fost special concepută pentru siguranța oferită, astfel
ea poate fi folosi tă în orice aplicație de timp real, cyber -physical systems și /sau rețele
industriale. Time -Triggered Ethernet simplifică design -ul pentru toleranța la erori și oferă
soluții pentru aplicații aerospațiale, auto motive și industriale. Siguranța și redundanța sunt
menținute la nivel de rețea fără ajutorul altor aplicații.
TTEthernet a fost introdusă prima dată în Mai 2005 la Washington în cadrul celui de-al
optulea simpozion internațional IEEE orientat pe obiect e de calcul în timp real, ISORC [14],
unde a fost prezentată integrarea comunicației event -triggered și time -triggere d pe un singur
switch Ethernet. T ehnologi a oferă o strategie de sincronizare pentru toleranță la erori.
Strateg iile de sincronizare existente, cum ar fi FlexRay [4] sau Network Time Protocol (NTP)
[15], nu oferă garanțiile și nivel urile de toleranță la eroare cerute .
Dezvoltarea de algoritmi pentru sisteme de calcul distribuite tolerante la erori, cum ar
fi sistemele informatice utilizare pentru a executa funcțiile critice la bordul unui avion, nu este
trivială, de aceea s -au dezvoltate anumite instrumente pentru proiectarea și verificarea asistată
de calculator a unor astfel de sisteme. TTEthernet pune în aplicare un set de astfel de algoritmi
pentru a sincroniza o multitudine de ceasuri locale, într -o rețea de calculatoare distribuite
spațial.
Unul dintre acești algoritmi AS6802 SAE, numit algoritm de pornire -repornire ,
definește modul în care ceasurile locale din sistemul distribuit sunt sincronizate inițial între ele,
de exemplu la alimentarea rețelei cu tensiune sau după o repornire a sistemului. Prin urmare,
algoritmul de pornire -repornire este de o importanță maximă pentru funcționarea unui sistem.
Pornirea sau restartarea strategiei de sincronizare TTEthernet a fost dezvoltată u tilizând
mode lul de verificare din SAL .
14
O rețea TTEthernet este bazată pe un switch Ethernet care are de obicei topologia stea
sau arbore. Pentru a tolera pierderea unui switch rețeaua poate fi replicată. Un exemplu de astfel
de rețea este reprezentat în figura 3.7 .
Fig. 3.7. Rețea TTEthernet
După c um se poate observa și în figura 3 .7., rețeaua este formată din cinci end system –
uri configurate ca fiind Synchronization Masters și două canale redundante. Canalul 1 este
format din trei switch -uri, din care două sunt configurate ca fiind Synchronization Client și un
switch este configurat c a Compression Master. Canalul 2 este format dintr -un singur switch
care este configurat ca Compression Master.
Problema abordată în această lucrare se bazează pe această tehnologie, dar și pe limbajul
SAL.
Principala problemă în a simula sincronizarea în acest mediu, a fost înțelegerea sintaxei
și funcțiilor. Acest limbaj n u este as emănător cu alte limbaje de programa re înaltă, dar este
asemănător cu alte limbaje de intrare folosite de alte tool -uri de verificare, cum ar fi SMV,
Murphi, Mocha și SPIN. Un avantaj important îl constituie timpul redus de a scrie cod [16]
15
Capitolul 4 . Implementare și tehnologii utilizate
4.1. Echipamente fizice
Ca suport în realizarea fizică a proiectului s -au folosit următoarele componente:
4 calculatoare Dell Precision T1500 echipate cu
o 2GB memorie, 250GB hard disk, Quad -Core Intel® Core i5
o TTE-PCIe Card (TTE -XMC Card with passive PCIe carrier) cu 3
module de plug -in SFP pentru 1 Gbit/s optical network connection
o Cablu de alimentare
2 switch -uri TTE -Development, 1Gbit/s, 12 porturi cu 12 modu le plug -in SFP
pentru 1 Gbit/s optical network connection și un cablu de alimentare
9 cabluri optice pentru interconectarea dintre switch -uri și calculatoare. Doar 9
dintre ele sunt obligatorii, unul este folosit ca rezervă în cazul în care se
deteriorează vreunul dintre celelalte.
4 cabluri de rețea cu conectori RJ45
Un switch 4 -porturi tastatura/video/mouse
4 cabluri USB/VGA pentru switch -ul KVM
Tastatură USB și mouse USB
Monitor LCD cu alimentare VGA
O pereche de boxe
Sistemul TTE -Development 1 Gbit/s pentru Linux v3.0 Recovery DVD ce
conține o imagine de Ubuntu 10.04 customizată
Sistemul TTE -Development 1 Gbit/s pentru Linux v3.0 Product DVD ce conține
aplicația „ttedemo”, fișierele audio și video necesare, pachetul de configurare,
TTE-NetDev Driver, e xemple adiționale de aplicații (ttexample) și
documentația sistemului TTE -Development 1 Gbit/s
CD-ul TTE -PCIe Card Driver ce conține pachetele Debian pentru TTE – PCI
Driver și TTE -API Library incluzând și documentația
1 DVD ce conține fișierele de instalar e ale TTE -Tools 3.1.1 pentru Windows
(fișierele .tim ) și Linux (pachetele .deb) incluzând și documentația TTE -Tools
Manualul printat
16
În figura 4.1.1. se află ilustrat mai explicit modul de conectare al componentelor
utilizate, și anume conexiunea dintre end-system -urile TTEthernet și switch -urile sistemului
TTE-Development.
Fig. 4.1.1. Imaginea de ansamblu a sistemului TTE -Development 1 Gbit/s ([17])
După cum am amintit și mai sus, fiecare din cele patru calculatoare execută diferite
părți ale demo -ului aplicației. Fiecare calculator este marcat cu funcția pe care o îndeplinește/
aplic ația pe care o execută și numerele porturi lor switch -urilor folosite pentru a comun ica în
rețea. Cele 4 porturi sunt conectate printr -un cablu de fibră optică.
Switch -ul TTE -Development are 12 porturi, așa cum este ilustrat și în figura 4.1.2 , și în
plus mai are încă un port de monitorizare care nu va fi utilizat pentru lucrarea de față.
17
Fig. 4.1.2. Conexiunile switch -ului TTE -Development ([17])
Porturile de la 1 la 4 sunt folosite pentru conectarea celor 4 calculatoare la aplicația
„ttedemo”. Conține și o interfață JTAG pentru a face update memoriei FPGA cu imagini IP și
un buton de reset care pune switch -ul în modul bootstrap.
Pentru a interacționa cu toate cele patru calculatoare se folosește un switch ca cel din
figura 4 .1.3 Acesta comută manual între cele 4 componente.
Fig. 4.1.3. KVM switch USB for audio -video (sursa: Digitus )
Pentru a putea realiza sincronizarea acestui cluster am plecat de la un model generic
dezvoltat anterior de către compania TTTech , în SAL .
18
4.1.1. Instalare Cygwin
Pentru a se putea lucra cu SAL, mai întâi trebuie parcurși următorii pași:
Click pe [16] pentru a putea folosi versiunea de SAL utilizată în acest proie ct,
așa cum este în figura 4.1.1.1.
Fig. 4.1.1.1 Descărcarea SAL -ului
Utilizarea emulatorul ui din SAL este posibilă numai după instalarea Cygwin
Fig. 4.1.1.2. Instalare Cygwin
Se selectează „install Cygwin”, așa cum se arat ă și în figura 4.1.1.2. astfel fiind
redirecționat către [18]
Se urmează pașii clasici de instalare a i unui program pentru a avea Cygwin pe
calculatorul , ce va fi folosit pentru simulare mai departe
La [19], se va alege versiunea pentru x86 chiar dacă sistemul de operare este pe
64biți, deoarece versiunea pentru 64 încă mai are câteva probleme. Astfel
emulatorul funcționează corect. Pentru o înțelegere mai bună a alegerii versiunii
se poate observa în figura 4.1.1.3. ce trebuie ales.
19
Fig. 4.1.1.3. Alegerea versiunii de Cygwin
După ce Cygwin -ul este instalat, trebuie realizate câteva modificări pentru a evita erorile
de memorie. În real izarea acest ui lucru, se propun două variante:
1. Se merge la [20] și se urmează cei 2 pași sau
2. Se deschide o fereastră din combinația de comenzi Windows+R, și se scriu în
linia de comandă următoarele instrucțiuni:
2.1. pwd pentru a vedea în ce folder suntem
2.2. dacă nu suntem în folderul /cygdrive/c , atunci se introduce comanda
„cd.. ” până când se ajunge în acest director. Apoi se introduc următoarele
comenzi:
2.2.1. C:\>cd \cygwin\bin
2.2.2. C:\cygwin\bin>copy dash.exe ..
2.2.3. C:\cygwin\bin>copy peflags.exe ..
2.2.4. C:\cygwin\bin>path C: \cygwin\bin;%path%
2.2.5. C:\cygwin\bin>..\dash
2.2.6. $../peflags –bigaddr=1 *.exe
2.2.7. $rebaseall – 0xe0000000
Astfel se va extinde memoria de care dispune Cygwin -ul în momentul
instalării și se evită erorile de tip „ Memory dump ”.
După ce se instalează Cygwin -ul și SAL, treb uie citită documentația de la [16] înainte
de a face orice altă modificare.
20
4.2. Implementare
Având partea fizică și softul necesar rea lizării proiectului, putem vorbi în continuare
despre implementarea acestuia.
Așa cum s-a spus și în capitolele anterioare s copul proiectului îl reprezintă sincronizarea
sistemului. Aflarea și observarea timpului necesar de sincronizare a clusterului după momentul
pornirii sau repornirii acestuia , este de asemenea o parte esențială a obiectivului . Drept urmare,
sarcina mea a fost aceea de a vedea după cât timp de la pornirea sau repornirea clusterului,
sistemul este sincronizat. Pentru a determina acest lucru s-a folosit un model generic dezvoltat
anterior de către companie, model sc ris în SAL. Cu ajutorul acestuia se poate vedea în câți pași
sistemul este stabil și complet sincronizat. Ca să se poată observa dacă sistemul este sincronizat
și prin ce tranziții a trecut, s-au introdus două variabile noi, mai exact doi vectori cu ajutorul
cărora s-a putut observa ce tranziții au loc astfel: dacă valoarea variabilei era TRUE atunci
simulatorul/emulatorul parcursese acea tranziție, dacă valoarea era FALSE atunci starea
respectivă nu a fost atinsă sau parcursă.
A fost folosit SAL deoarece exista un model de bază de la care s-a putut pleca și realiza
programul final al proiectului. Î n comparație cu alte medii de dezvoltare , spre exemplu Visual
Studio, SAL -ul oferă avantajul scrierii a mai p uține linii de cod în limbajul propriu pentru a
realiza anumite lucruri specifice . Limbajul SAL este un limbaj ce oferă calități sau proprietăți
de timp real, descrie foarte bine tranzițiile ce au loc în sistem , având caracteristici de timp real
oferă rezu ltate într -un timp relativ scurt și multe altele.
Pentru implementarea s-a plecat de la f ișierul care conține modelul de bază . Modelul
analizează parametrii primiți de la un script, run_SI.sh. Acest s cript oferă posibilitatea setării a
trei parametrii ce diferențiază modelele rezultate între ele. De fiecare dată când modelul general
este rulat se creează un fișier cu extensia .sal, un fișier de trace, în care pot fi vizualizate
rezultatele, un fișier de eroare care arată utilizatorului ce a fost greșit în timpul rulării, oferind
astfel posibilitatea de corectare rapidă a erorilor și obținerea corectă de rezultate comparativ cu
alte limbaje. Pe lângă aceste fișiere, modelul generic mai generează și un fișier .txt în care este
salvată configurația dată în fi șierul run_SI.sh.
Așa cum s -a spus mai sus, a fost necesară determinarea timpul necesar clusterului pentru
a ajunge în stare stabilă, sincronizată din momentul în care sistemul este pornit. Pentru aceasta
s-au analizat tranzițiile sistemului și s -au observ at care au loc și care nu.
21
Analizarea tranzițiilor și observarea producerii lor a fost realizată cu ajutorul unor
variabile ce au fost adăugate în modelul generic.
În SAL atunci când adăugăm o variabilă nouă, trebuie să îi creăm și u n tip
corespunzător, pe ntru ca modulul de verificare să o poată utiliza atunci când creează scenariile.
Tipul noilor variabile se declară astfel:
„TYPE_BOOLEAN: TYPE = {F, MyTrueValue}; % type for TEST,
where F is for FALSE and MyTrueValue for TRUE”
Apoi se declară noile variabile:
„SM_TEST: ARRAY [1..50] OF TYPE_BOOLEAN, %test if
transitions are made”
Această variabilă verifică dacă o tranziție a unui Synchronization Master a avut loc.
„CM_TEST: ARRAY[1..24] OF TYPE_BOOLEAN”
Această variabilă verifică dacă o tranziție a unui Compression Master are loc.
În SAL variabilele nu trebuie instanțiate, deoarece emulatorul face singur acest lucru în
momentul în care e rulat scriptul run_SI.sh.
În modelul SAL tranzițiile de stare sunt definite ca fiind:
Guard
→
State updates
„Guard” se referă la o condiție care trebuie îndeplinită, în timp ce „state updates” se
referă la noile valori ale atributelor variabilelor atunci când tranziția respectivă este efectuată.
Pentru un test -trace au fost adăugate la tranziția d ată, variabila SM_TEST pentru
Synchronization Master, și CM_TEST pentru Compression Master. După ce variabilele au fost
declarate, o tranziție existentă se poate modifica astfel:
Guard
→
State updates
22
CM_TEST’[i] = MyTrueValue; if you have a CM transition
or
SM_TEST’[i] = MyTrueValue; if you have a SM
transition
Prin aceste atribuiri se arată că o tranziție s -a realizat, mai exact CM_TEST[i] și
SM_TEST[i] vor fi setate pe TRUE.
Cluster -ul are pentru CM și SM , în modulul în care acestora li se declară proprietățile și
tranzițiile, stări predefinite c e trebuie verificate pentru a știi dacă au fost parcurse sau nu de
către modelul de verificare din SAL .
Synchronization Master conține următoarele stări:
SM_POWER_UP_ 100
SM_INTEGRATE_1010
SM_UNSYNC_1030
SM_FLOOD_1040
SM_WAIT_4_CYCLE_START_CS_1050
SM_TENTATIVE_SYNC_1060
SM_SYNC_1070
SM_STABLE_1080
Compression Master are următoarele stări:
CM_POWER_UP
CM_INTEGRATE_2010
CM_WAIT_4_CYCLE_START_2020
CM_UNSYNC_2030
CM_CA_ENAB LED_2040
CM_WAIT_4_IN_2050
CM_TENTATIVE_SYNC_2060
CM_SYNC_2070
Toate aceste stări au fost verificate dacă au avut l oc sau nu prin adăugarea noilor
variabile CM_TEST[i] și SM_TEST[i].
23
Pentru a înțelege mai bine ce anume simbolizează fiecare dintre aceste stări se vor
detalia în cele ce urmează.
Modulul Synchronization Master
1. SM_POWER_UP_1000
2. SM_INTEGRATE_1010
3. SM_UNSYNC_1030
4. SM_FLOOD_1040
5. SM_WAIT_4_CYCLE_START_CS_1050
6. SM_TENTATIVE_SYNC_1060
7. SM_SYNC_1070
8. SM_STABLE_1080
Modulul Compression Master
1. CM_POWER_UP
2. CM_INTEGRATE_2010
3. CM_WAIT_4_CYCLE_START_2020
4. CM_ UNSYNC_2030
5. CM_CA_ENABLED_2040
6. CM_WAIT_4_IN_2050
7. CM_TENTATIVE_SYNC_2060
8. CM_SYNC_2070
În fiecare dintre aceste stări se testează cazul ideal și cel ne -ideal. Pentru ambele cazuri
avem declarată o variabilă worst_case_counter, care reține numărul de cazuri nefavorabile ce
au loc în timpul simulării. Acesta își păstrează valoarea dacă modulele sunt în stări ideale, adică
fie sunt sincronizate, fie stabile. Dacă modulul nu este încă sincronizat sau st abil, contorul va
fi incrementat.
O altă variabilă verificată la fiecare tranziție este X_local_timer, unde X poate fi SM
sau CM. Dacă ceasul local este mai mare ca zero aceasta va fi decrementat, iar variabila
SM_TEST[i] sau CM_TEST[i] va avea valoare ad evărată arătând astfel ca modulul de
verificare a testat acea tranziție. Atunci când X_local_timer este egal cu zero SM -ul sau CM -ul
vor trece într -o altă stare, variabila noua de asemenea va lua valoare de adevărat, de data aceasta
arătând că modulul și -a schimbat starea în care se afla .
24
4.2.1. Modulul Synchronization Master
1. Starea SM_POWER_UP_1000
În această stare se verifică valoarea SM_local_timer pentru ambele cazuri, ideal și
ne-ideal .
Pentru cazul ideal, dacă valoarea timer -ului este mai mare decât zero acesta se
decrementează și variabila SM_TEST[i] ia valoarea adevărat. Dacă timer -ul este egal cu zero,
atunci noua stare a SM -ului va fi SM_INTEGRATE_1010, cu alte cuvinte dacă SM -ul va trece
într-o stare nouă care îl va aduce mai aproape de pro prietatea de sincronizare, și de asemenea
noua variabila va primi valoarea TRUE, astfel arătându -se că modulul de verificare a trecut și
prin această stare atunci când a realizat simularea procesului.
Cazul ne-ideal presupune că SM -ul trimite date eronate de aceea el trece în starea
SM_FAULTY. Fiind în stare FAULTY rezultă că aceasta este nesincronizat, de aceea el va
încerca să ajungă la acea stare, pornind din nou de la starea inițială și pa rcurgând o serie de
nouă etape.
2. Starea SM_INTEGRATE_1010
Ca în starea anterioară, și pentru această tranziție se fac mai multe verificări. Pentru
a vedea dacă SM -ul trece sau nu din starea SM_INTEGRATe_1010 în altă stare nu se verifică
doar local_timer -ul ci și alte variabile.
Și aici(în acest caz ) se verifică dacă local_timer -ul este mai mare sau egal cu zero. Dacă
este mai mare ca zero și nu există nici un canal pe care switch -ul să primească un mesaj de
Coldstart Acknowledge sau Integration, se va decrementa timer -ul și Sync hronization Master –
ul își va păstra starea de SM_INTEGRATE_1010.
În cazul în care timer -ul este zero și de asemenea switch -ul nu primește mesaj de
Coldstart Acknowledge sau Integration, Synchronization Master -ul va trece în starea
SM_UNSYNC_1030, iar S M_local_timer va lua valoarea sm_coldstart_timeout .
Dacă există pe unul din canale un mesaj de Coldstart Acknowledge (CA) către switch,
atunci Synchronization Master -ul va trece în starea SM_WAIT_4_CYCLE_START_CS_1050,
mai exact așteaptă să primească răspuns de la switch pentru a putea continua procesul de
sincronizare și stabilizare. SM_local_timer va lua valoarea ca_offset.
Dacă nu există mesaj de CA atunci SM -ul va trece în starea SM_SYNC_1070 iar timer –
ul va fi setat pe zero.
25
3. Starea SM_UNSYNC_1030
Dacă local_timer -ul este mai mare ca zero atunci SM își păstrează starea de
SM_UNSYNC_1030 iar timer -ul se decrementează. Variabila nouă va avea valoarea adevărat.
Dacă local_timer -ul este zero și avem mesaj de Integration pentru switch atunci SM va
rămâne n esincronizat iar timer -ul va primi valoarea sm_coldstart_timeout.
Dacă starea este tot UNSYNC dar switch -ul primește mesaj de coldstart atunci SM va
trece în starea următoare și anume SM_FLOOD_1040, iar timer -ul va primi valoarea cs_offset.
Când Compression Master -ul primește un mesaj de coldstart_ack, Synchronization
Master poate trece din UNSYNC în starea WAIT_4_CYCLE_START_CS_1050, timer -ul fiind
setat la valoarea ca_offset.
Atunci când Compression Master primește mesaj de Integration, SM poat e trece din
UNSYNC în SM_TENTATIVE_SYNC_1060 iar timer -ul se aduce la valoarea zero.
De asemenea, dacă timpul de așteptare pentru ajungere în starea sincronizată este mai
mare decât pragul stabilit și nu se mai primesc mesaje pe canalul de comunicație, a tunci SM -ul
poate trece din starea UNSYNC în starea SM_SYNC_1070, având timer -ul setat pe zero.
4. Starea SM_FLOOD_1040
Atunci când se primește un mesaj de tip coldstart, SM -ul își va păstra starea dar timer –
ul va primi valoarea cs_offset.
Dacă timer -ul este zero, SM -ul se află tot în starea FLOOD și pe canalul de comunicație
se primesc mesaje diferite de coldstart atunci timer -ul va avea valoarea 1, dar când aceasta va
fi mai mare ca zero atunci timer -ul se va decrementa, starea SM -ului păstrându -se.
SM-ul va trece în starea SM_WAIT_4_CYCLE_START_CS_1050 doar atunci când în
rețea se primește un mesaj de coldstart_ack și timer -ul este zero, aceasta fiind setat la valoarea
ca_offset după ce tranziția are loc, iar variabila nouă va avea valoarea TRUE.
Când în rețea nu se mai primesc mesaje de tipul coldstart ci de alt tip, timer -ul este zero
și nu avem canale pe care să se primească un coldstart_ack, SM -ul trece in starea SM_UNSYNC
iar timer -ul ia valoarea sm_coldstart_timeout.
De asemenea, SM -ul își păstr eaza starea și dacă timer -ul este mai mare ca zero iar în
rețea se primesc mesaje diferite de tipul coldstart. În acest caz timer -ul va fi decrementat cu 1.
26
5. Starea SM_WAIT_4_CYCLE_START_CS_1050
În acest caz avem 4 posibilități de a avansa la o altă stare sau de a rămâne la starea
curentă și anume:
– Se primește un mesaj de tipul coldstart, deci se trece în starea SM_FLOOD iar timer –
ul va avea valoarea cs_offset
– Se primește mesaj de tipul coldstart_ack, SM își păstrează starea dar timer -ul ia
valoarea c a_offset
– Se primesc mesaje diferite de tipul coldstart, timer -ul este zero și nu avem canal de
comunicație pe care să se primească vreun coldstart_ack. În acest caz SM -ul va trece
în SM_TENTATIVE_SYNC_1060 iar timer -ul va rămâne zero
– Timer -ul este mai mare ca zero, se transmit mesaje diferite de coldstart și nu există
canal de comunicație care să primească coldstart_ack, deci SM -ul își păstrează
starea dar timer -ul este decrementat cu 1.
În fiecare caz în parte, variabila nou adăugată va lua valoarea TRUE d acă modulul de
verificare a luat în considerare acea tranziție.
6. Starea SM_TENTATIVE_SYNC_1060
Și această stare are mai multe cazuri ideale sau ne -ideale. Cazul ideal este reprezentat
de posibilitatea de trecere la altă stare care să ducă SM -ul în sincron izare, cazul ne -ideal este
reprezentat de rămânerea în aceeași stare sau întoarcere la alte stări anterioare.
Următoarele tranziții sunt posibile din această stare:
Să se primească un mesaj de tip coldstart și să existe de asemenea pe canalul
de comunicaț ie un mesaj de tipul coldstart_ack. În această situație SM -ul își
păstrează starea iar local_timer -ul ia valoarea cs_offset.
Dacă există doar canal de primire a unui mesaj de tip coldstart_ack atunci
SM-ul se va întoarce la starea SM_WAIT_4_CYCLE_START_CS_1050 iar
timer -ul va avea valoarea ca_offset.
Când nu există pe canalul de comunicație nici un mesaj de coldstart_ack se
păstrează starea iar timer -ul e setat pe valoarea zero.
În toate cazurile, variabila nouă va avea valoarea TRU E dacă acea tranziție a avut loc.
27
7. Starea SM_SYNC_1070
Așa cum reiese și din denumire, dacă un Synchronization Master ajunge în această stare
înseamnă că acesta este sincronizat.
Din această stare putem tranzita în următoarele stări:
– SM_FLOOD_1040 – atunci când avem un mesaj de tip coldstart în rețea și pe unul
dintre cele 2 canale se primește un mesaj de tip coldstart_ack. La această tranziție
timer -ul local va primi valoarea cs_offset.
– SM_WAIT_4_CYCLE_START_CS_1050 – pentru a ajunge la această stare t rebuie
ca pe un canal să se primească un mesaj de tipul coldstart_ack. De asemenea
valoarea timer -ului se modifică, acesta fiind setat la valoarea lui ca_offset.
– SM_SYNC_1070 – își păstrează starea dacă nu există nici un mesaj de tipul
coldstart_ack primit pe vreunul din canalele de comunicație, și ceasul local al SM –
ului este 0. În acest caz ceasul local al SM -ului va fi incrementat.
– SM_UNSYNC_1030 – din stare sincronizată poate ajunge să fie nesincronizat
astfel:
Fie nu există mesaje de tipul coldstart_ack pe nici un canal din rețea, ceasul
local este zero și SM_local_async_membership nu depășește pragul setat sau
este mai mare decât SM_local_sync_membership. În această situație noua
valoare a ceasului local va fi sm_listen_timeout.
Fie nu exis tă mesaje de tipul coldstart_ack în rețea pe nici un canal de
comunicație, ceasul local are valoarea smc_scheduled_receive_pit iar
valorile naturale ale mesajelor de intrare sunt mai mari decât zero și mai mici
decât sm_sync_threshold_sync. Astfel noua val oarea a timer -ului local al
Synchronization Master -ului va fi sm_restart_timeout, iar ceasul local va fi
setat pe valoarea zero.
– SM_INTEGRATE_1010 – această stare este atinsă atunci când ceasul local are
valoarea smc_scheduled_receive_pit, nu există mesaje de coldstart_ack recepționate
în rețea iar valorile naturale ale mesajelor de intrare sunt zero. În acest caz timer -ul
local va lua valoarea sm_restart_timeout iar ceasul local va fi setat pe zero.
– Mai există 2 situații speciale din care se mai realizează tranziții pentru această stare:
Când nu avem mesaje de tipul coldstart_ack pe nici un canal de comunicație,
valoarea ceasului l ocal este smc_scheduled_receive _pit, și valorile naturale
ale mesajelor de intrare fie de pe poziția 1, fie de pe poziția 2 sunt mai mari
sau egale decât sm_sync_threshold_sync se va realiza tranziția astfel:
28
Se verifică dacă numărul de cicluri stabile ale SM -ului este mai mare
sau egal cu numărul de cicluri stabile date din configurație
Dacă rezultatul comparației este TRUE atunc i noua stare a
Synchronization Master -ului va fi SM_STABLE_1080, în caz
contrar starea rămâne SM_SYNC_1070.
Pentru ambele cazuri timer -ul local va fi setat pe zero iar ceasul local
se va incrementa.
Se observă că dacă rezultatul comparației este adevărat S M-ul nu este
doar sincronizat ci este și complet stabil.
Ultima tranziție din această stare setează timer -ul local pe zero și
incrementează ceasul local, dacă nu există mesaje de tipul coldstart_ack pe
nici un canal iar ceasul local are valori diferite dec ât sm_dispatch_pit și
sm_scheduled_receive_pit.
În toate tranzițiile acestei stări noua variabilă de test ia valoare de adevăr dacă tranziția
a avut loc, altfel rămâne la valoare falsă.
8. Starea SM_STABLE_1080
Și în această stare avem mai multe tranziții care pot avea loc. În urma tranzițiilor se
poate ajunge în următoarele stări :
– SM_WAIT_4_CYCLE_START_CS_1050 – în această stare se ajunge dacă există
mesaje de tip coldstart_ack în rețea. Astfel după realizarea tranziției timer -ul local
va fi setat la valo area ca_offset iar ceasul local va avea valoarea zero.
– SM_STABLE_1080 – pentru păstrarea stării avem 2 cazuri, după cum urmează:
Nu există mesaje de tipul coldstart_ack în rețea, iar valorile naturale ale
mesajelor de intrare fie de pe poziția 1, fie de pe poziția 2 sunt mai mari sau
egale decât sm_stable_threshold_sync. Timer -ul local va lua valoarea 0 iar
ceasul local va fi incrementat.
Nu există mesaje de tip coldstart_ack în rețea, valoarea incrementată a
ceasului local este 0, și valoarea naturală a SM _local_async_membership
este mai mică și decât sm_stable_threshold_async și decât valoarea naturală
a SM_local_sync_membership. Ceasul local va fi incrementat.
– SM_INTEGRATE_1010 – și această stare are 2 tranziții posibile:
Nu sunt mesaje de colstart_ack în rețea, valoarea ceasului local este zero, și
valoarea naturală a SM_local_async_membership este mai mare sau egală
29
fie decât sm_stable_threshold_async, fie decât valoarea naturală a
SM_local_sync_membership. În acest caz timer -ul local va avea valoarea
sm_listen_timeout iar ceasul local va fi zero.
Nu există mesaje de tipul coldstart_ack pe nici un canal de comunicație,
ceasul local are valoarea smc_scheduled_receive_pit, iar valorile naturale
ale mesajelor primite pe pozițiile 1 și 2 sunt mai mici decât
sm_stable_threshold_sync. Astfel timer -ul local va fi setat pe
sm_listen_timeout iar ceasul local al SM -ului pe zero.
– Ca și în cazul anterior mai există 2 situații în care nu se trece la altă stare dar în
funcție de anumite condiții se modifică valorile cea sului local și /sau a timer -ului
local. Acestea sunt:
Dacă nu există mesaje de tipul coldstart_ack în rețea și ceasul local are
valorile diferite de sm_dispat ch_pit și smc_scheduled_receive _pit atunci
timer -ul local va fi setat pe zero iar ceasul local se v a incrementa.
Dacă niciuna dintre tranzițiile de mai sus nu este realizată atunci noua
valoare a stării Synchronization Master -ului va rămâne cea default.
În toate tranzițiile, chiar și cea în care se păstrează valoarea default a stării, variabila de
test va lua valoarea adevărat, dacă tranziția a avut loc și își va păstra valoarea falsă în caz
contrar.
30
4.2.2 . Modulul Compression Master
1. Starea CM_POWER_UP_2000
Pentru această stare există 2 situații:
Dacă timer -ul local al Compression Master -ului este mai mare ca zero atunci
acesta se va decrementa și își va păstra starea
Dacă timer -ul local este zero atunci se va trece în starea
CM_INTEGRATE_2010 iar timer -ul local va avea atribuită valoarea
cm_listen_timeout.
În ambele cazuri variabil a de test va lua valoarea TRUE dacă tranziția are loc și FALSE
în caz contrar.
2. Starea CM_INTEGRATE_2010
Din această stare avem 4 situații în care putem evolua:
CM_INTEGRATE_2010 – nu avem mesaj de tip integration și timer -ul local
este mai mare decât zero. În acest caz timer -ul se va decrementa, ceasul local va
fi setat pe zero iar Compression Master -ul își păstrează starea.
CM_UNSYNC_2030 – nu avem mesaj de tip integration iar timer -ul local este
egal cu zero. Astfel aceasta va fi decrementat iar ceas ul local va fi setat pe zero.
CM_WAIT_4_CYCLE_START_2020 – avem mesaje de tip integration și nu se
depășește valoarea de prag cm_integrate_to_sync_threshold, dar este depășită
valoarea cm_integrate_to_wait_threshold. În această situație timer -ul local este
trecut pe zero, iar ceasul local va lua valoarea incrementată a
cm_compressed_pit.
CM_SYNC_2070 – avem mesaj de tip integration și se depășește valoarea de
prag cm_integrate_to_sync_threshold. Timer -ul local este setat pe zero, și ceasul
local ia valoarea incrementată a cm_compressed_pit.
Dacă aceste tranziții au loc, valoarea variabilei de test este trecută pe TRUE, altfel
rămâne la FALSE.
31
3. Starea CM_WAIT_4_CYCLE_START_2020
Această stare are doar 3 tranziții.
Stările în care poate ajunge sunt următoarele:
– CM_WAIT_4_CYCLE_START_2020 – dacă valoarea ceasului local este diferită
de cm_compressed_pit atunci se păstrează starea, iar în urma tranziției ceasul va fi
incrementat și timer -ul local setat pe zero.
– CM_TENTATIVE_SYNC_2060 – când ceasul loca l este egal cu
cm_compressed_pit iar valoarea următorului mesaj de ieșire este mai mare ca zero,
CM-ul încearcă să se sincronizeze cu restul sistemului. Timer -ul local va fi setat pe
zero iar ceasul local va fi incrementat.
– CM_UNSYNC_2030 – ceasul local es te egal cu cm_compressed_pit iar valoarea
următorului mesaj de ieșire este egală cu zero. În această situație atât timer -ul local,
cât și ceasul local vor fi setate pe zero.
Variabila de test va avea valoare de adevăr numai dacă tranziția a avut loc.
4. Starea CM_UNSYNC_2030
Dacă un Compression Master se află în această stare, înseamnă ca el nu este sincronizat.
În funcție de parametrii pe care îi are el poate trece într -una din următoarele stări:
CM_UNSYNC_2030 – își păstrează starea dacă nu primește mesaj de tip
integration, se depășesc valorile de prag cm_unsync_to_sync_threshold și
cm_unsync_to_tent_sync_threshold și nu primește nici mesaj de tip coldstart
sau coldstart_ack. Timer -ul și ceasul local vor avea valoarea zero.
CM_TENTATIVE_SYNC_2060 – în acea stă stare ajunge dacă îndeplinește
simultan 2 condiții, și anume:
nu primește mesaj de tip integration și depășește valoarea
cm_unsync_to_sync_threshold și
primește mesaj de tip integration și depășește valoarea
cm_unsync_to_tent_sync_threshold
astfel timer -ul local e setat pe zero, iar ceasul local ia valoarea incrementată a lui
cm_compressed _pit.
CM_SYNC_2070 – primește mesaj de tip integration și depășește valoarea
cm_unsync_to_sync_threshold. Timer -ul local ia valoarea zero, iar ceasul
local ia valo area incrementată a cm_compressed_pit.
32
CM_CA_ENABLED_2040 – în această stare ajunge prin 2 modalități:
Nu primește mesaj de integration și depășește valorile de prag
cm_unsync_to_sync_threshold și
cm_unsync_to_tent_sync_threshold iar următorul mesaj de ieș ire
este coldstart. În acest caz timer -ul local ia valoarea
cm_ca_enabled_timeout iar ceasul local e setat pe 0.
Nu primește mesaj de integration, depășește valorile de prag
cm_unsync_to_sync_threshold și
cm_unsync_to_tent_sync_threshold, și următorul mesa j de ieșire
este de tip coldstart_ack. Ceasul local ia valoarea zero, iar timer -ul
este setat la valoarea cm_ca_enabled_timeout.
În toate tranzițiile variabila de test își modifică valoarea din FALSE în TRUE dacă
acestea au loc.
5. Starea CM_CA_ENABLED_2040
Un Compression Master poate tranzita din această stare în următoarele 2 stări:
CM_CA_ENABLED_2040 – dacă timer -ul local este mai mare decât zero
atunci își păstrează starea și decrementează timer -ul și setează ceasul local pe
zero.
CM_WAIT_4_IN_2050 – dacă timer -ul local al Compression Master -ului este
zero atunci va trece în starea CM_WAIT_4_IN. Timer -ul local va lua valoarea
cm_wait_4_in_timeout iar ceasul local rămâne la valoarea zero.
Variabila nouă, CM_TEST[i], va avea valoare de TRUE dacă tranziți a dintr -o stare în
alta va avea loc, și FALSE în caz contrar.
6. Starea CM_WAIT_4_IN_2050
Pentru acest caz avem 3 situații posibile de tranziție, și anume:
CM_WAIT_4_IN_2050 – își păstrează starea atunci când timer -ul local este mai
mare ca zero, nu avem mes aj de tip integration în rețea și valoarea naturală a
membership -ului nu este mai mare sau egală cu valoarea
cm_integrate_to_sync_threshold. Având aceste condiții se decrementează
timer -ul local și se setează ceasul local pe zero.
33
CM_UNSYNC_2030 – timer -ul local este zero, nu avem mesaj de tip integration
și valoarea naturală a membership -ului nu este mai mare sau egală decât cea a
cm_integrate_to_sync_threshold. În această situație atât timer -ul local cât și
ceasul local sunt setate pe zero.
CM_SYNC_2070 – avem mesaj de tip integration în rețea și valoarea naturala a
câmpului membership este mai mare sau egală cu
cm_integrate_to_sync_threshold. În acest caz timer -ul local este setat pe zero iar
ceasul local este incrementat cu valoarea cm_compressed_pit.
CM_TEST[i] va lua valoare de adevăr în toate cazurile dacă acestea au loc, altfel
rămâne la valoarea falsă.
7. Starea CM_TENTATIVE_SYNC_2060
Compression Master -ul aflat în această stare este aproape sincronizat.
În această stare avem 2 situații care depind de mai multe variabile, după cum
urmează:
Își păstrează starea dacă ceasul local are valoarea diferită de zero. Atunci când
tranziția are loc se setează timer -ul pe zero iar ceasul local se incrementează.
Dacă ceasul local are valoarea zero atunci noua stare a Compression Master -ului
este:
CM_UNSYNC_2030 – dacă valoarea naturală a
CM_local_async_membership este mai mare sau egală cu
cm_tentative_sync_threshold.
CM_SYNC_2070 – dacă valoarea naturală a următorului mesaj de ieșire
este mai mare sau egală cu valoa rea cm_tentative_sync_threshold.
CM_UNSYNC_2030 – dacă valoarea naturală a următorului mesaj de
ieșire este mai mică decât valoarea cm_tentative_sync_threshold.
CM_TENTATIVE_SYNC_2060 – dacă nu îndeplinește niciuna dintre
condițiile de mai sus își păstreaz ă starea în care se află
Ceasul local va fi incrementat iar timer -ul va fi setat pe zero.
Și în aceste tranziții valorile variabilelor de test, CM_TEST[i], iau valoarea de adevăr
dacă tranziția are loc sau își păstrează valoarea de fals, dacă modulul de v erificare nu trece și
prin acele cazuri.
34
8. Starea CM_SYNC_2070
În această stare Compression Master -ul este stabil și sincronizat, adică rețeaua este
sincronizată .
Pentru această stare există două situații în care poate trece switch -ul, și anume:
CM_SYNC_2070 – dacă ceasul local este diferit zero. În această situație timer –
ul local este setat pe zero iar ceasul local va fi incrementat.
Dacă ceasul local este egal cu zero avem următoarele cazuri:
CM_INTEGRATE_2010 – dacă valoarea naturală a
CM_local _async_membership este mai mare decât valoarea
cm_sync_threshold_async
CM_SYNC_2070 – dacă valoarea naturală a mesajului următor de ieșire
este mai mare sau egală decât cm_sync_threshold_async
Altfel, dacă niciuna dintre condițiile de mai sus nu sunt îndep linite starea
pe care o are este CM_TENTATIVE_SYNC_2060.
Indiferent de ramura pe care va intra modulul de verificare, timer -ul local ia
valoarea cm_restart_timeout iar ceasul local va fi incrementat.
Și de această dată, la fiecare tranziție variabila CM_T EST[i], va avea fie valoare de
adevăr fie de fals, în funcție de realizarea sau nu a acesteia.
Pe lângă cele două module, mai avem și altele, printre care :
modulul de diagnoză, pentru fiecare tip de eroare, fie un Compression Master
eronat sau nesincronizat, fie un Synchronization Master instabil sau
nesincronizat sau care trimite mesaje în afara ferestrelor de timp,
modulul conexiunilor pentru fiecare tip de eroare, fie un Synchronization Master
trimite eronat sau nu s -a sincronizat, fie un Com pression Master aflat în aceleași
situații ca mai sus,
modulul de definire a parametrilor de sincronizare
modulul de definire a Mem bership-ului
modulul de definire a funcțiilor folosite în program
modulul de definire a mesajelor transmise
modulul ce defi nește componența cluster -ului
modulul de proprietăți atunci când se efectuează testele și simulările
35
Figura 4.2.2.1. arată mai explici t cum sunt legate aceste module, iar figurile 4.2.2.2.,
4.2.2.3., 4.2.2.4., 4.2.2.5., 4.2.2.6., 4.2.2.7., 4.2.2.8., 4.2. 2.9. sunt prezentate clasele, în mod
explicit, atribute și operații.
Fig. 4.2.2.1. Diagramă clase SAL
36
Fig. 4.2.2.2. Clasa run_SI
Fig. 4.2.2.3. Clasa TTEthernet_generic_SI
37
Fig. 4.2.2.4. Clasa Synchronization Master Module
Fig. 4.2.2.5. Clasa Compression Master Module
38
Fig. 4.2.2.6. Clasa Time Definition
Fig. 4.2.2.7. Clasa Synchronization Master Definition
Fig. 4.2.2.8. Clasa Compression Master Definition
39
Fig. 4.2.2.9. Clasa Function Definition
După cum se poate observa toate module le enumerate mai sus, sunt conectate la modulul
principal TTEthernet_generic_SI, care este definit prin context. Acest modul va rula numai
după primirea parametrilor IS_PROOF și IS_TESTCASE de la scriptul run_SI.sh, parametrii
transmiși de către utilizator.
Un alt modul important îl constituie modulul Diagnosis, fie pentru Compression Master
fie pentru Synchronization Master, deoarece în aceste module se modifică val oarea atributului
worst_case_counter.
Modificarea se face astfel:
dacă Synchronization Master -ul sau Compression Master -ul este stabil și
variabila IS_PROOF este setată pe valoarea TRUE atunci valoarea variabilei
worst_case_counter rămâne la valoarea pe c are o are în acel moment
dacă Synchronization Master -ul sau Compression Master -ul nu este stabil și
variabila IS_TESTCASE are valoarea TRUE atunci variabila
worst_case_counter este incrementată .
De asemenea alt modul important îl reprezintă cel de proprietăți. În acest modul se
declară teoreme sau LEMME. Mai exact o astfel de lemă este definită astfel:
test1: LEMMA cluster | – G(FORALL(x:[1..4]):
(FORALL(y:[1..50]): SM_TEST[x][y] = F));
Această lemă are ca scop verificarea va riabilelor de test SM_TEST[i] și CM_TEST[i] .
Ele sunt verificate dacă au mereu valoarea FALS folosind funcția G(). Cum nu o să fie mereu
false modelul de verificare din SAL va căuta scenarii care să seteze pe TRUE aceste variabile.
Adăugarea acestor leme permite unui test trace să verifice sistematic că toate tranzițiile au loc
atunci când se execută un caz de simulare al algoritmului de pornire/repornire.
40
4.2.3. Script run_SI.sh
Scriptul run_SI.sh are nevoie de setarea următorilor parametrii:
numărul maxim de Synchronization Master din rețea. În mod implicit acesta este
4, deoarece cluster -ul are 4 astfel de end system -uri
valoarea variabilei worst_case_counter, care poate lua valori între 0 și 200.
Valoarea acestei variabile arată numărul minim de pa și pe care simulatorul
trebuie să îi parcurgă pentru a detecta un caz eronat sau nefavorabil, mai exact
să caute un caz nesincronizat în acest număr de pași.
Valoarea variabile depth. Prin această variabilă se transmite modulului de
verificare numărul maxi m de pași pe care trebuie să îi parcurgă pentru a găsi un
caz sincronizat al cluster -ului. Valoarea acestuia va fi worst_case_counter + 2
întotdeauna.
Se definește dacă va fi executat proof sau testcase. Acest lucru se face prin
setarea pe TRUE sau FALSE a variabilelor is_proof și is_testcase. Aceste
variabile sunt transmise prin parametrii mai departe către fișierul
TTEthernet_generic_SI.sal
Pentru cazul în care is_proof este setat pe TRUE avem două situații:
Proof_implicit va genera toate stările inițiale așa cum sunt definite în
secțiunea INITIALIZATION din specificații; au câteva bug -uri
cunoscute dar pot produce contraexemple astăzi.
Proof_explicit va genera un set configurabil de stări inițiale așa cum sunt
definite în secțiunea TRANSITION a specificațiilor
Pentru cazul proof_explicit trebuie selectate ce stări vor fi adevărate pentru
momentul în care are loc execuția scriptului
Un alt parametru ce trebuie setat, este cazul de scenariu de eșec, și anume:
fault_free,
SM_failures
CM_failures
Pe lângă setarea parametrilor, în script se setează variabila scenario_name care conține
numele SI_CM_startup_$(worst_case_counter) , astfel știind ce număr de pași a fost selectat
pentru a testa timpul de sincronizare al cluster -ului.
Execuția se realizează cu ajutorul comenzii ./run_SI.sh. În momentul în care se apasă
Enter se realizează următorii pași:
41
se cre ează noul folder ce va conține toate fișierele generate de script pentru
worst_case_counter -ul stabilit de că tre utilizator. Folder -ul va avea numele
scenario_name -ului
se copiază contextul scriptului ru_SI.sh într -un fișier txt, numit config.txt, pentru
a știi ce configurație s -a utilizat, adică ce parametrii s -au setat și cu ce valori au
se atribuie valoarea TT Ethernet_exec unei variabile filename, apoi se copiază
conținutul fișierului TTEthernet_generic_SI.sal într -un alt fișier aflat în folderul
scenario_name, având numele filename și extensia .sal. Acest fișier conține
modelul specific pentru un anumit scenar iu de încercare de sincronizare a
cluster -ului.
se creează alte două fișiere:
unul cu extensia .trc, în care se afișează contraexemplul găsit, dacă
setările au fost făcute corect și numărul de pași a permis simulatorului să
găsească unul . Cele mai import ante rezultate din acest fișier sunt:
a_list_CM_state[1] = CM_UNSYNC_2030
a_list_CM_state[2] = CM_UNSYNC_2030
a_list_SM_state[1] = SM_FAULTY
a_list_SM_state[2] = SM_POWER_UP_1000
a_list_SM_state[3] = SM_POWER_UP_1000
a_list_SM_state[4] = SM_POWER_UP_1000
ele reflectă starea individuală a fiecărui end -system (Synchronization
Master) și a fiecărui switch (Compression Master). De aceea, atunci
când aceste stări sunt căutate în fișierul .trc se observă cum li se
modifică stările în funcție de pasul la care se află, și în mod obligatoriu
ele trebuie să își modifice starea la fiecare pas.
altul cu extensia .stderr, care afișează erorile din configurație, în cazul în
care există, sau dacă totul este setat corect va afișa timpii în care se
efectuează mai multe oper ații cum ar fi importarea contextului, parsarea
fișierului TTEthernet_exec.sal, verificarea contextului, convertirea
proprietăților în proprietăți logice , numărarea variabilelor de sistem și a
celor auxiliare, executarea comenzii bmc și afișarea timpului t otal de
execuție. După fiecare operație modelul de verificare afișează timpul în
care aceasta s -a realizat.
42
4.2.4. Script extractTransitions.py
Pentru a putea urmări mai ușor cum se modifică valorile variabilelor noi adăugate, se
creează cu ajutorul li mbajului Python un script ce extrage doar tranzițiile de interes și afișează
dacă s -a sincronizat sistemul sau nu.
Scriptul are definite mai multe clase, și anume:
clasa Tran – cu ajutorul acestei clase se extrag toate tranzițiile timer -ului local
pentru a putea observa când anume se trece printr -o tranziție și cum se modifică
aceasta. Se definesc trei metode, una de inițializare a timere -lor locale, alta
pentru setarea atributelor timer -lor și una pentru afișare a acestora într -o ordine
bine definită.
Clasa PCF – această clasă ne ajută să căutăm conținutul unui cadru PCF într -un
fișier cu extensia .trc.
Clasa AllPCFs – este utilizată pentru a extrage toate cadrele PCF dintr -un fișier
cu extensia .trc. În această clasă avem 2 metode statice: una folosită la căutarea
în fișier, căutarea realizată după tipul mesajului, adică de intrare sau de ieșire, și
tipul dispozitivului, Compression Master sau Synchronization Mast er, și o altă
metodă folosită pentru printarea rezultatelor în funcție de valoarea de adevăr a
variabilelor rx și tx. Dacă rx are valoarea TRUE atunci se vor afișa cadrele PCF
primite, dacă tx are valoare TRUE atunci se printează cadrele PCF transmise.
După definirea claselor se inițializează o variabilă de tipul AllPCFs, care va apela
metoda searchPcfs și va afișa valorile variabilelor noi definite și timpii în care operațiile de
tranziție se realizează.
Figura 4.2.4.1. ilustrează cele 3 clase ale scriptu lui și metodele definite pentru a realiza
extragerea tranzițiilor și a timpilor locali.
43
Fig. 4.2.4.1. Diagrama extractTransition.py
Pentru a vedea dacă configurația din SAL poate fi implementată și pe hardware -ul
utilizat, trebuie extrase câmpurile PCF din fișierul .trc, de aceea s -a creat scriptul
extractTransition.py. Acesta extrage următoarele informații:
Message_in, reprezintă tipul de PCF primit
Messages_out, reprezintă tipul de PCF trimis
Membership_new, care constituie valoarea câmpului membership a PCF -ului
Integration_cycle
După ce se apelează scriptul va afișa datele extrase într -o forma tabelară, așa cum se
poate observa în figura 4.2.4.2.
Odată ce aceste informații sunt cunosc ute, clusterul poate fi simulat.
Scriptul este prezentat în anexă, iar acesta conține și comentarii care pot facilita
înțelegerea acestuia.
44
Fig. 4.2.4.2. Rezultatul rulării scriptului extractTransition.py
45
Capitolul 5. Funcționarea sistemului/ Testare și verificare
După ce au fost realizate simulările și s -au implementat cerințele, aplicația poate fi
testată pe suportul hardware prezentat în figura 5.1.
Fig. 5.1. Clusterul audio -video
După ce acesta este alimentat, se poate observa și în figura 5.1. că switch -ul KVM audio –
video este primul care primește alimentare. De asemenea, se poate vedea că există un singur
monitor de operare, o singură tastatură și un mouse. Toate acestea sunt conectate la KVM care
permite trecerea de la o componentă la alta cu atribuire de monitor, tastatură și mouse, pentru
ca acestea să poată fi pornite corect, fără a întâmpina vreo eroare de tip lipsă dispozitiv periferic.
Figura 5.2. prezintă etapa următoare alimentării sistemului, și anume pornirea celor
două switch -uri, ce au rol de Compression Master.
46
Fig. 5.2. Alimentarea switch -urilor
De asemenea în această figură se poate observa că swicth -ul KVM are ledul roșu aprins
în poziția 1, acest lucru însemnând că putem porni prima componentă a sistemului, imediat
după pornirea celor 2 switch -uri.
În momentul pornirii primei componente, Vide o Server, se observă în figura 5.3. că și
ledurile porturilor specifice conexiunii primului Synchronization Master la cele două switch –
uri vor fi pornite. Se observă că din cele 12 porturi ale switch -urilor, doar primele 4 sunt folosite
pentru această apli cație. Fiecare port are câte două intrări: prima, așa cum se vede și în figura
5.3., specifică faptul că Synchronization Master -ul a fost pornit/alimentat, iar a doua arată că
funcționează aplicația/programul specific acelei componente.
47
Fig. 5.3. Pornire a primei componente
După deschiderea componentei, se deschide un terminal și se introduce comanda
/home/demonstrator/ttedemo/video_server, ca în figura 5.4.
Fig. 5.4. Comanda pentru schimbarea directorului
Apoi se introduce comanda ./launch.sh și se observă în figura 5.5. că se va aprinde și
ledul ce arată faptul că aplicația rulează, iar în figura 5.6. că serverul a început să realizeze
funcțiile necesare pentru a putea rula pe ultima compon entă partea vide o a clusterului, mai exact
să încarce fișierele video din sistem.
48
Fig. 5.5. Funcționarea componentei video server
Fig. 5.6. Încărcarea fișierelor video
După realizarea acestor pași se trece la al doilea Synchronization Master, care are
funcție de Audio Server, prin comutarea manuală pe al doilea buton al switch -ului KVM. După
alimentare, și la aceasta se deschide un terminal la care se introduce comanda „ cd
/home/demonstrator/ttedemo/audio_server” și apoi comanda „./launch.sh”. Rezultatele se pot
observa în figurile de mai jos. Figura 5.7. și arată funcți onarea componentei la pornire, în timp
ce figura 5.8. expune rezultatul rulării.
49
Fig. 5.7. Alimentarea Audio Serverului
Se observă că deși aplicația a fost rulată ledul ce arată acest lucru încă nu este pornit.
Fig. 5.8. Rularea aplicației
Următoarea componentă ce necesită pornire este Audio Client -ul. La fel ca la primele
două, se deschide un terminal în care se introduc comenzile „cd
/home/demonstrator/ttedemo/audio_client” și „./launch.sh” și se observă în figurile 5.9.
pornirea componentei și a aplicației, și în figura 5.10. rezultatul rulării programului.
50
Fig. 5.9. Alimentarea Audio C lient-ului
Se observă că după rularea aplicației din Audio Client se va aprinde și ledul galben al
rulării aplicației din Audio Server, lucru ce arată că serverul nu funcționează până nu este pornit
și clientul.
Fig. 5.10. Rularea aplicației
În final d upă ce toate cele 3 componente au fost pornite, va fi pornit și Synchronization
Master -ul cu funcția de Video Client. De asemenea se vor folosi comenzile „cd
/home/demonstrator/ttedemo/video_client” și „./launch.sh”, pentru a putea rula aplicația.
Singura diferență față de celelalte componente o reprezintă rezultatul rulării ultimei comenzi.
51
Dacă la celelalte aveam doar terminalul în care se observau operațiile realizate, aici rezultatul
este diferit, întocmai cum este prezentat în figurile 5.12. și 5.13.
Figura 5.11. prezintă switch -ul având activate toate porturile.
Fig. 5.11. Activarea tuturor componentelor
Fig. 5.12. Fereastra de comandă a aplicației
52
Fig. 5.13. Rezultatul rulării
După cum se poate observa în figura 5.14. panoul de control este împărțit în mai multe
zone.
Fig. 5.14 Panou de comandă
În prima parte avem playlist -ul audio, care conține 50 de melodii cu diferite durate, a
doua zonă cuprinde playlist -ul video al aplicației. După cele două zone de playlist av em partea
de control al fluxului de date sau traficului. Acesta este de 3 tipuri începând de la stânga la
53
dreap ta: Best -Effort, Rate -Constrain ed de prioritate mică și Rate -Constrained de prioritate
ridicată așa cum se poate observa și în figura 5.15.
Fig. 5.15. Tipurile de trafic perturbator
Fiecare tip de trafic sau combinație a acestora influențează diferit transmisia video:
Trafic de tip Best -Effort – nu are un impact mare asupra transmisiei video, el
având cea mai mică prioritate dintre toate tipurile de trafic
Trafic de tip Rate -Constrained cu prioritate mică – dacă acționează singur
produce doar întârzieri minimale în primirea unor cadre sau le pierde și redă
numai ce primește. Dacă acționează împreună cu traficul de tip Best -Effort
întârzier ea va crește puțin, iar cadrele pierdute vor fi mai multe decât cazul
anterior.
Trafic de tip Rate -Constrained cu prioritate ridicată – dacă este acționat
împreună cu traficul de tip Best -Effort atunci produce doar întârzierea
pachetelor și uneori pierdere a lor. Dacă atât cel cu prioritate ridicată cât și cel cu
prioritate scăzută sunt selectate la nivel maxim atunci transmisia se blochează,
utilizatorul având doar un cadru pe care î l poate vizualiza până la
descongestionarea traficului. Figurile 5.16. , 5.17. și 5.18. ilustrează mai bine
această situație. Se observă că în partea stângă, unde avem trafic de tip Time –
Triggered, videoclipul rulează în timp ce în partea dreaptă a rămas blocat pe un
singur cadru.
54
Fig. 5.16. Trafic blocat
Fig. 5.17. Trafic blocat
55
Fig. 5.18. Trafic perturbat
Atunci când toate cele trei tipuri de trafic sunt setate la nivel maxim matricea de trafic
arată ca în figura 5.19.
Fig. 5.19. Matricea de trafic
Se poate observa în terminal ce se întâmplă în momentul acționării diferitelor tipuri de
trafic la diferite niveluri, figura 5.20. Butonul de reset din figura 5.19. permite restabilirea
transmisiei la valorile inițiale.
56
Fig 5.20. Transmisia datelor
Dacă se dorește oprirea aplicației, se va închide fereastra în care rulează videoclipul,
apoi fereastra de control. După ce acestea au fost închise video clientul încetează rularea
programului. În momentul în care aplicația s -a oprit s e va stinge și ledul por tocaliu.
Pentru oprirea sistemului se va proceda în sens invers, adică întâi se va închide Video
Client -ul, apoi Audio Clientul, urmat de Audio Server și Video Server, comutarea între ele
realizându -se cu ajutorul switch -ului KVM. La închiderea Video Ser ver-ul se va opri și switch –
ul KVM și monitorul.
57
Capitolul 6. Rezultate
Tabelul 6 .1. arată rezultatele simulării clusterului în două cazuri: când avem 2
Synchronization Master ce transmit eronat și cazul în care doar un singur Synchronization
Master este defect.
Prima coloană denumește componenta defectă, în timp ce a doua arată starea inițială a
acesteia. Coloanele trei și patru prezintă timpii de simulare în care s -au obținut contraexemple
și numărul de pași simulați, în timp ce coloanele cinci și șase arată rezultatele pentru cazul în
care nu se mai produce un contraexemplu. Timpul de verificare este în secunde.
Tabel 6 .1. Rezultatele verificării pentru 2 SM faulty
În urma simulărilor, cu diferite valori pentru worst_case_counter, s -a observat că limita
la care modelul de emulare nu mai oferă un contraexemplu, pentru cazul în care avem scenariul
cu un Synchronization Master defect, este de 120 de pași. Timpul de emulare al fiecărui model
variază semnificativ. În primul rând timpul de evaluare crește odată cu valoarea variabilei
depth . Timpul de simulare sau verificare din tabel reprezintă timpul final de verificare.
Pentru cazul Synchronization Master defect, la simulările cu valoarea pașilor egală cu
115 și 120 am obținut rezultate bune, adică sistemul est e sincronizat, end -system -ul defect
restabilit, astfel încât să poată menține starea de sincronizare, iar valoarea variabilei „stable”,
care oferă informații despre starea sistemului, este TRUE.
Faulty Init States Counterexample Upper Bound
Worst Case Verif. Time Worst Case Verif. Time
SM1, SM2 integrate
unsync 50 351.088 55 169.332
SM1 integrate 115 1584.247 120 1073.36
58
Capitolul 7. Concluzii
Lucrarea de față prezintă modul de realizarea al verificării sincronizării unui cluster cu
comunicație de tip Ethernet determinist. Modelul de la care s -a pornit pentru realizarea acestui
lucru este scris în SAL și permite evaluarea mai multor comportamente eronate ale algoritmului
de pornire -repornire.
Așa cum am descris în capitolele anterioare, există 3 cazuri pe care le puteam testa, fault
free, Synchronization Master defect și Compression Master defect, iar eu am ales doar cazul
doi, și anume un Synchronization Master care tri mite eronat. În urma mai multor simulări , a
rezultat că pentru valorile numărului de pași egale cu 115 și 120, sistemul este sincronizat și
end-system -ul defect este restabilit.
S-au folosit, ca suport fizic, 4 end -system -uri și 2 switch -uri. În timpul si mulării s -a
observat și faptul că dacă aveam un singur switch rezultatele ar fi fost aceleași.
Pentru validarea simulărilor, și implicit a codului, s -a implementat programul și pe
suport fizic, iar rezultatele au arătat că sincronizarea se produce conform simulărilor.
Pe viitor se pot analiza și cazurile fault f ree și Compression Master defect, pornind de
la rezultatele obținute în această l ucrare, și de asemenea se pot studia și cazuri complexe, cum
ar fi:
– Două Synchronization Master transmit eronat
– Un Co mpression Master și un Synchronization Master se defectează
– Un end -system defect și o altă eroare din sistem ce produc funcționare eronată
Acestea sunt doar câteva exemple ce mai pot fi studiate pentru structura folosită în
această lucrare , în cazul în car e aceasta se extinde și cazurile de funcționare eronată se extind.
Pentru ca partea de simulare să poată funcționa corect, trebuie respectate cu atenție mare
instrucțiunile de la capitolul 4.1.1., în special partea de extindere a memoriei de operare a
Cygwin-ului, deoarece în caz contrar simulatorul va transmite mesaje de eroare. Am întâmpinat
această problema pe parcurs, și acest lucru a cauzat întârzierea terminării lucrării în timpul
estimat. De aceea, tocmai pentru a evita aceste aspecte este bine să s e urmeze pașii descriși.
59
Bibliografie
[1] Pagina companiei TTTech https://www.tttech.com/ Accesat 20.05.2016
[2] Mediul de dezvoltare SAL http://sal.csl.sri.com/ Accesat: 25.05.2016
[3] C. E. Howard, „Orion avionics employ COTS technologies”, Avionics Intelligence,
Iunie 2009
[4] FlexRay Communications System – Protocol Specification – Version 2.1. FlexRay
Consortium, 2005, Disponibil la http://www.flexray.com
[5] H. Hopertz, A. Adamaj, P. Grillinger și K. Steinhammer (2005), „The time -triggered
ethernet (tte) design”, 8th IEEE International Symposium on Object -oriented Real –
time distributed Computting (IS ORC), Seattle, Washington, May. 2005.
[6] G. Bauer, H. Kopetz, and P. Puschner. Assumption Coverage under Different Failure
Modes in the Time -Triggered Architecture. In Proc. Of International Conference on
Emerging Technologies and Factory Automation, pag. 333 -341, Octombrie 2001
[7] A. Ademaj, G. Bauer, H. Sivencrona, and J. Torin. Evaluation of fault handling of the
Time -Triggered Architecture with bus and star topology. În Proc. Of International
Conference on Dependable Systems and Network (DSN 2003), San Franci sco, Iunie,
2003.
[8] G. Bauer, H. Kopetz and W. Steiner. The central guardian approach to enforce fault
isolation in a time -triggered system. În Proc. Of 6th International Symposium on
Autonomuous, Descentralized Systems (ISADS 2003), pag. 37 -44, Pisa, Italia, Aprilie,
2003
[9] Prezentarea metodei de testare bazată pe model
http://www.tutorialspoint.com/software_testing_dictionary/model_based_testing.htm
Accesat : 23.04.2016
[10] Clasificare rețele de comunicație
http://shannon.etc.upt.ro/laboratoare/rcd/rcd_laborator.pdf Accesat: 20.06.2016
[11] Radu Dobrescu (2005), „ Transmiterea datelor”, Editu ra Academiei, 2005
[12] Descrierea tehnologiei TTEthernet https://en.wikipedia.org/wiki/TTEthernet
Accesat: 01.06.2016
[13] Format cadru PCF pag. 69
https://www.irit.fr/torrents/seminars/files/Chaudron_2013 -06-28.pdf Accesat:
10.06.2016
[14] H. Hopertz, A. Adamaj, P. Grillinger și K. Steinhammer (2005), „The time –
triggered ethernet (tte) design”, 8th IEEE International Symposium on Object -oriented
Real-time distributed Computting (ISORC), Seattle, Washington, May. 2005.
[15] D. Mills, „Internet tim e synchronization: the network time protocol”, IEEE
Transactions on Communications, vol. 39, nr. 10, pag. 1482 -1493, Octombrie 1991
[16] Mediul de dezvoltare SAL http://sal.csl.sri.com/ Accesat: 25.05.2016
[17] Proiectul TTE -Development, clusterul utilizat în lucrare
https://www.tttech.com/products/aerospace/development -test-vv/development –
switches/tte -development -switch -1-gbits -12-ports/ Accesat: 25.05.2016
[18] Etapele de instalare Cygwin http://sal –
wiki.csl.sri.com/index.php/Cygwin_installation Accesat: 30.05.2016
[19] Proiec t Cygwin http://www.cygwin.com/ Accesat: 15.05.2016
[20] Documentație lărgire memorie pentru Cygwin
https://www.cygwin.com/cygwin -ug-net/setup -maxmem.html Accesat: 15.05.2 016
60
Anexe
# -*- coding: iso -8859-1 -*-
# Copyright (C) 2015 TTTech Computertechnik AG. All rights reserved.
# Schoenbrunnerstrasse 7, A –1040 Wien, Austria. office@ttech.com
#
#++
# Name
# extractTransitions.py
#
# Purpose
# Extracts transitions and PCFs from a *.trc file generated by SAL
model.
#
# Revision Dates
# 2-Oct-2015 (MCO) Creation
# 29 -Oct-2015 (MCO) Update __repr__ method from PCF
# ««revision -date»»···
#–
import sys
transLst = [] #list for transition
class Tran :
"""
With this class we extract all local timer transitions in order to
have a closer undestanding on the time when a transition occured.
"""
def __init_ _(self, step):
self.step = step
self.cm_local_timer_1 = 0
self.cm_local_timer_2 = 0
self.sm_local_timer_1 = 0
self.sm_local_timer_2 = 0
61
self.sm_local_timer_3 = 0
self.sm_local_timer_4 = 0
# end de f __init__
def setAttr(self, attrName, attrVal) :
setattr(self, attrName, attrVal)
if attrName.lower() == 'cm_local_timer_1' :
self.cm_local_timer_1 = attrVal
if attrName.lower() == 'cm_local_timer_2' :
self.cm_local_timer_2 = attrVal
if attrName.lower() == 'sm_local_timer_1' :
self.sm_local_timer_1 = attrVal
if attrName.lower() == 'sm_local_timer_2' :
self.sm_local_timer_2 = attrVal
if attrName.lower() == 'sm_local_timer_3' :
self.sm_local_timer_3 = attrVal
if attrName.lower() == 'sm_local_timer_4' :
self.sm_local_timer_4 = attrVal
# end def setAttr
def __repr__(self) :
return " %4d | %7d | %7d | %7d | %7d | %7d | %7d" % (self.step,
self.cm_local_timer_1, self.cm_local_timer_2, self.sm_local_timer_1,
self.sm_local_timer_2, self.sm_local_timer_3, self.sm_local_timer_4)
# end def __repr__
# end class Tran
class PCF :
"""
This class help us to search the content of a PCF frame from a
*.trc file
"""
def __init__(self, step, devType):
self.step = step
self.devType = devType # 'SM' or 'CM'
62
self.devIdx = 0 # index of the CM or SM that
receives/sends this PCF
self.isRx = True
self.chan = 0
self.pcfType = 0
self.pcfIntCycle = 0
self.pcfMembership = [] # list with the membership bits
self.typeTranspMsg = 0
# end def __init__
def __repr__(self) :
return "%4d | %s %4d | %4d | %5s | %7d | %11d | %13s | %19d |" %
(self.step, self.devType, self.devIdx, self.chan, 'RX' if self.isRx == True
else 'TX', sel f.pcfType, self.pcfIntCycle, ''.join(map(str,
self.pcfMembership)), self.typeTranspMsg)
# end def __repr__
# end class PCF
class AllPCFs :
"""
With this class we extract all the PCFs frame from the *.trc file
"""
pcfsLst = [] #list for PCF frames
def __init__(self) :
pass
# end def __init__
@staticmethod
def searchPcfs(fname):
print "Searching in file %s…" % fname
f = open(fname, 'r')
linLst = f.readlines()
i = 0
while i < len(linLst) :
el = linLst[i].strip()
63
if el.startswith('Step'):
stepNo = int(el.split()[1][: -1])
if 'integration_cycle' in el : # a new PCF started in the
*.trc file
if el.startswith('CM_messages_in'):
p = PCF(stepNo, 'CM')
AllPCFs.pcfsLst.append(p)
# extract what a CM receive
lst = el.split('=') # e l =
'CM_messages_in[1][1].integration_cycle = 0'
p.pcfIntCycle = int(lst[1].strip())
p.chan = int(lst[0][15:16])
p.devIdx = int(lst[0][18:19])
p.isRx = True
for bit in range(4) :
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'CM_messages_in[1][1].membership_new[1] = false'
val = 1 if lst[1].strip() == 'true' else 0
p.pcfMembership.append(val)
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'CM_messages_in[2][4].msg_type = quiet'
if lst[1].strip() == 'quiet' :
val = 0
elif lst[1].strip() == 'integration' :
val = 2
elif lst[1].strip( ) == 'coldstart' :
val = 4
elif lst[1].strip() == 'coldstart_ack':
val = 8
64
p.pcfType = val
# extract what a SM receive
elif el.startswith('SM_messages_in'):
p = PCF(stepNo, 'SM')
AllPCFs.pcfsLst.append(p)
lst = el.split('=') # el =
'SM_messages_in[1][1][0].integration_cycle = 0'
p.pcfIntCycle = int(lst[1].strip())
p.devIdx = int(lst[0][15:16])
p.chan = int(lst[0][18:19])
p.isRx = True
p.typeTranspMsg = int(lst[0][21:22])
for bit in range(4) :
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'SM_messages_in[4][2][0].membership_new[ 1] = false'
val = 1 if lst[1].strip() == 'true' else 0
p.pcfMembership.append(val)
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'SM_messages_in[4][2][0].msg_type = quiet'
if lst[1].strip() == 'quiet' :
val = 0
elif lst[1].strip() == 'integration' :
val = 2
elif lst[1].strip() == 'coldstart' :
val = 4
elif lst[1].strip() == 'coldstart_ack':
val = 8
p.pcfType = val
65
# extract what a CM se nd
elif el.startswith('CM_messages_out'):
p = PCF(stepNo, 'CM')
AllPCFs.pcfsLst.append(p)
lst = el.split('=') # el =
'CM_messages_out[1][1][0].integration_ cycle = 0'
p.pcfIntCycle = int(lst[1].strip())
p.chan = int(lst[0][16:17])
p.devIdx = int(lst[0][19:20])
p.isRx = False
p.typeTra nspMsg = int(lst[0][22:23])
for bit in range(4) :
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'CM_messages_out[1][1][0].membersh ip_new[1] = false'
val = 1 if lst[1].strip() == 'true' else 0
p.pcfMembership.append(val)
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'CM_messages_out[1][1][0].msg_type = quiet'
if lst[1].strip() == 'quiet' :
val = 0
elif lst[1].strip() == 'integration' :
val = 2
elif lst[1].strip() == 'coldstart' :
val = 4
elif lst[1].strip() == 'coldstart_ack':
val = 8
p.pcfType = val
# extract what a SM se nd
elif el.startswith('SM_messages_out'):
66
p = PCF(stepNo, 'SM')
AllPCFs.pcfsLst.append(p)
lst = el.split('=') # el =
'SM_messages_out[1][1].integration_cyc le = 0'
p.pcfIntCycle = int(lst[1].strip())
p.devIdx = int(lst[0][16:17])
p.chan = int(lst[0][19:20])
p.isRx = False
for bit in range(4):
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'SM_messages_out[1][1].membership_new[1] = false'
val = 1 if lst[1].str ip() == 'true' else 0
p.pcfMembership.append(val)
i += 1
el = linLst[i].strip()
lst = el.split('=') # el =
'SM_messages_out[1][1].msg_type = quiet'
if lst[1].strip() == 'quiet' :
val = 0
elif lst[1].strip() == 'integration' :
val = 2
elif lst[1].strip() == 'coldstart' :
val = 4
elif lst[1].strip() == 'coldstart_ack':
val = 8
p.pcfType = val
i += 1
f.close()
#end def searchPcf
@staticmethod
def printAll(rx = True, tx = True) :
67
"""If `rx` = True print received PCFs.
If `tx` = True print transmitted PCFs.
"""
print "Step | Dev Idx | c han | RX/TX | pcfType | pcfIntCycle |
pcfMembership | Type_transparent_msg"
for pcf in AllPCFs.pcfsLst:
if rx and pcf.isRx :
print pcf
if tx and not pcf.isRx :
print pcf
#end def printAll
# end class AllPCFs
def parseFile(fName):
print "Parsing %s…" % fName
f = open(fName,'r')
linesLst = f.readlines()
for l in linesLst:
l = l.strip()
if l.startswith('Step'):
nr = int(l.split()[1][: -1])
t = Tran(nr)
transLst.append(t)
if l.startswith('CM_local_timer'):
lst = l.split('=')
idxCM = lst[0].split('[')[1].strip()[: -1]
val = int(lst[1])
t.setAttr('CM_local_timer _%s' % idxCM, val)
if l.startswith('SM_local_timer'):
lst = l.split('=')
idxSM = lst[0].split('[')[1].strip()[: -1]
val = int(lst[1])
t.setAttr('SM_local_timer_%s' % idxSM, val)
f.close()
68
# end def parseFile
pcfs = AllPCFs()
pcfs.searchPcfs(sys.argv[1])
pcfs.printAll()
pcfs.printAll(rx = True, tx = False)
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: București, 2016 [606176] (ID: 606176)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.