Post on 28-Dec-2015
description
transcript
183
CAPITOLUL 12
PROTOCOLUL FLEX RAY
12.1 Generalităţi
Originea conceptului FlexRay provine din formaţia grupului de companii care au
dorit să realizeze o analiză tehnică exclusivă a reţelelor existente, folosite sau disponibile în
industria pentru automobile: CAN, TTCAN, TCN, TTP/C şi Byteflight, pentru a descoperi
dacă vreuna dintre acestea poate îndeplini toate cererile tehnice ale aplicaţiilor.
Concluziile au demonstrat că trebuie dezvoltat un nou protocol: FlexRay.
Constatările referitoare la soluţiile existente sunt prezentate în continuare :
CAN nu este suficient de rapid pentru noile aplicaţii cerute şi este dificil de efectuat
transmisia deterministă şi redundantă. FlexRay nu va înlocui CAN, dar va funcţiona
împreună cu el.
TICAN are în mod inevitabil acelaşi dezavantaj al vitezei limitate, ca şi CAN. De
asemenea, eşuează în furnizarea:
- suportului pentru transmisii optice;
- unui canal de transmisie redundant;
- unui timp global de toleranţă la defecte;
- unui supraveghetor de magistrală (bus guardian).
Pentru TTP/C, conţinutul datelor transportate de cadru este considerat prea mic. Mai
mult, chiar dacă se foloseşte protocolul TDMA pentru accesul la magistrală, nu sunt
multe proprietăţi în comun cu FlexRay. De asemenea, TTP/C nu oferă flexibilitate, în
comparaţie cu FlexRay, în ceea ce priveşte:
- combinaţia dintre secţiunile de transmisie sincrone şi asincrone;
- fantele de transmisie multiple pentru un singur nod, în secţiunea sincronă;
- acţiunea nodurilor pe canale simple, duble sau mixte;
- o strategie de a nu renunţa niciodată, în relaţia privind controlul sistemului de
comunicaţie, referitor la aplicaţie;
- problemele statutului de membru în FlexRay, licenţa şi drepturile de service.
Byteflight nu oferă destulă funcţionalitate. Dacă FlexRay este utilizat în mod pur
asincron, el poate fi configurat pentru a fi compatibil funcţional cu Byteflight.
184
12.2 Scurt istoric
În anul 2000, a fost semnată o colaborare între următoarele companii:
- producătorii de automobile Daimler Crysler AG, BMW AG şi General Motors
Corporation;
- producătorul de echipamente Robert Bosch GmbH;
- fabricanţii de chipuri Motorola GmbH (acum Freescale) pentru controlerul de
comunicaţii şi Philips GmbH pentru componentele reţelei fizice (implicat de
asemenea în specificaţia acestui protocol);
- Volkswagen AG, completând apelul nominal al partenerilor de bază ai consorţiului
FlexRay.
Fiecare dintre aceşti parteneri trebuia să aducă cerinţe specifice proiectului. Cele două
clase: Membrii Premium şi Membrii Asociaţi au fost definitivate în acelaşi timp.
Compania DeComSys dezvoltatoare de unelte (al cărui personal provine din echipa
care a dezvoltat protocolul TTP/C) este administratorul oficial al consorţiului, care a
prezentat conceptul FlexRay la o conferinţă publică în Munchen, în aprilie 2002, precum şi
în prima zi de producţie, în septembrie 2004, la Boblingen.
12.3 Obiectivele protocolului FlexRay
Încă de la început, obiectivul consorţiului FlexRay a fost crearea unui sistem de
comunicaţie pentru controlul şi monitorizarea aplicaţiilor la trei nivele diferite:
la rate de bit înalte, astfel încât să sporească, să complementeze şi să suplinească
aplicaţile limitate de viteza de bit a protocolului CAN;
capabil pentru implementarea soluţiilor X-by-Wire;
dezvoltarea soluţiilor care oferă redundanţă:
- prin trimiterea aceloraşi mesaje de mai multe ori, lucru posibil datorită vitezei
înalte de transfer;
- prin asigurarea a două canale separate de comunicaţii, care transmit aceleaşi date
în paralel;
- având două canale de comunicaţii care transmit complementar date, în timp
normal, astfel încât oferă o viteză aparent mai mare decât viteza de bit a
protocolului şi asigură utilizarea în întregime a canalului rămas, ca fall-back;
capabil să deservească toate funcţiile electronice viitoare în autovehicule.
Protocolul FlexRay susţine comunicaţii implementate utilizând următoarele topologii:
- canal unic;
- două canale;
- magistrală şi magistrală cu coturi;
- topologii tip stea activă şi stea pasivă;
- stele multiple cu sub-magistrale opţionale;
- combinaţii ale topologiilor de mai sus.
185
În ceea ce priveşte comunicaţiile, protocolul FlexRay trebuie să îndeplineacscă
următoarele condiţii:
să aibă o lăţime mare a benzii de transmisie de date digitale (10 Mbit/s);
să transmită date în modurile sincron şi asincron;
să transporte în reţea date deterministe, cu latenţa mesajului cunoscută şi garantată;
să aibă viteze diferite simultane, alocând corespunzător lăţimea de bandă nodurilor;
să fie capabil să transporte la ieşire segmente statice şi dinamice ale datelor:
- pentru distribuirea cererilor;
- pentu distribuirea ariilor de funcţionalitate;
- pentru susţinerea unui număr configurabil de fante de timp de transmisie, pentru
fiecare nod şi fiecare ciclu de funcţionare;
să aibă o geometrie variabilă pentru redundanţa hardware şi software (canal unic,
canal dublu şi sistem combinat);
să asigure modul “somn” şi “deşteptare” al participanţilor din reţea;
să gestioneze consumul de putere pentru participanţii din reţea;
să detecteze şi să semnalizeze erorile foarte rapid;
să reziste erorilor de sincronizare ale bazei de timp globale;
să ofere servicii de toleranţă la defecte şi declanşare a timpului, prin dispozitive de
tip hardware;
să gestioneze erorile din reţeaua fizică printr-un bus-guardian independent;
să fie capabil să susţină prezenţa unui supraveghetor de magistrală descentralizat, în
reţeaua fizică (toate topologiile combinate);
protocolul să fie independent de folosirea supraveghetorului de magistrală central
(bus-guardian opţional, fără interferenţe);
să permită alipirea unor noi noduri la sistemul existent, fără a necesita
reconfigurarea nodurilor existente deja. Datele configurate trebuie să respecte
principiul necesităţii cunoaşterii (printr-un dispozitiv intrinsec special de cunoaştere
şi căutare).
Pentru sistemele X-by-Wire, protocolul FlexRay trebuie sa îndeplinească
următoarele condiţii de securitate:
- să fie capabil să gestioneze comunicaţiile redundante;
- să asigure accesul deterministic la reţea (redundanţă sincronă);
- să evite ciocnirile pentru accesul la magistrală;
- să asigure o opţiune pentru redundanţa cu geometrie variabilă (canal unic, canal
dublu, sistem combinat);
- să funcţioneze după strategia “nu renunţa niciodată”, asigurând astfel că orice
sistem de comunicaţie nedisponibil îşi dezactivează automat mecanismele
backup distribuite;
- repornirea unui nod într-un sistem de operare să implice mult mai mult decât
simpla repornire a comunicaţiilor sale;
- să menţină comunicaţia atât timp cât comunicarea între alte noduri nu este
compromisă.
Securitatea maximă se obţine printr-o combinaţie a hardware-ului (arhitectură dublu
canal, bus gardian independent, CPUs cu toleranţă la defecte), mecanisme încorporate în
protocol şi suportul aplicaţiei. De asemenea, este necesar să se asigure:
186
- robusteţea sistemului la erori tranzitorii şi radiaţii externe;
- minim de radiaţie externă pentru sistem, EMC (compatibilitate electromagnetică),
protecţie, etc.
Referitor la cererile pentru aplicaţii, FlexRay trebuie să asigure că aplicaţia:
este întotdeauna pe deplin responsabilă pentru orice decizie în condiţiile securităţii
şi disponibilităţii reţelei;
ia întotdeauna decizia finală;
este întotdeauna în control pentru sistemul de comunicaţii, nu invers;
menţine recepţia cât mai mult posibil, deoarece o pauză în comunicare reprezintă o
decizie critică ce trebuie luată la nivel de aplicaţie;
este capabilă să ofere moduri de operare diferite, respectând comunicaţia:
- funcţionare normală sau continuă;
- funcţionare în mod dedicat:
funcţionare continuă, dar cu notificarea nodului gazdă;
funcţionare redusă, cu erori: stoparea transmisiei şi notificarea;
eroare fatală: funcţionare stopată. Toţi pinii şi gardianul magistralei sunt
schimbaţi în stările de eroare sigură.
Este astfel încât nodurile pot fi configurate să supravieţuiască mai multe cicluri de
funcţionare fără a primi cadre de comunicaţie.
Parametrii generali şi cererile enumerate anterior vor sta la baza cererilor pentru
următoarele trei clase de aplicaţii, neacoperite încă de CAN sau de alte protocoale existente:
Clasa 1- comunicaţii cu bandă largă;
Clasa 2 – comunicaţii deterministe cu bandă largă;
Clasa 3 – cominicaţii deterministe şi redundante de bandă largă.
Pe o scară de timp de aproximativ 10 ani, aceste idei îşi vor găsi suport material în
industrie, în noile arhitcturi de reţele folosite în aplicaţiile on-board ale protocolului
FlexRay, în cele trei clase de aplicaţii decsrise mai sus, folosind CAN ca o submagistrală a
FlexRay şi LIN ca o submagistrală a CAN.
12.4 Descrierea protocolului FlexRay
În 30 iunie 2004, pe site-ul FlexRay au fost postate trei documente de referinţă:
versiunea 2.0 a protocolului, reţeaua fizică şi gardianul de magistrală. Versiunea finală 2.1
(mai 2005) include câteva modificări minore.
FlexRay a fost proiectat să asigure un sistem de comunicaţii în care sunt imposibile
ciocnirile pentru accesul la mediu; cu alte cuvinte, nodurile nu sunt subiect de arbitrare pe
canalul de transmisie iar ciocnirile nu pot avea loc într-o funcţionare normală. Ciocnirile
pot apărea în timpul fazei de pornire a protocolului în mediul de transmisie. Reţeaua fizică
nu oferă nici un mod de rezolvare a acestor ciocniri, de aceea, astfel de probleme trebuie să
le rezolve stratul de aplicaţie.
În scopul asigurării sistemului cu flexibilitatea maximă a aplicaţiei, este necesar:
- să permită funcţionarea în timp real, adică să comunice la un moment de timp precis,
cunoscut pentru un timp maxim, cu asigurarea că este singura staţie prezentă la acel
moment în mediul fizic de comunicaţie, aceasta făcând ciocnirile imposibile;
187
- să permită comunicarea la o viteză de bit variabilă dacă se cere acest lucru, şi astfel să
solicite un timp de comunicaţie nespecificat.
FlexRay urmează protocolul TTCAN în propunerea comunicării bazată pe bucle de
comunicaţie, numite cicluri de comunicaţie, în care accesul este asigurat sincron, în fante de
timp specificate precis de proiectantul de sistem.
Timpul necesar pentru acest ciclu este divizat în fante de timp egale, care aparţin
exclusiv unităţilor CPU care le activează să transmită datele. Alocările exclusive (la
unităţile CPU) ale acestor sloturi sunt transferate la ieşire, adică, în timpul fazei de
proiectare a sistemului, eliminând astfel competiţia pentru accesul la reţea şi alte efecte în
timpul fazei de funcţionare normală, numită online.
Proiectantul sau managerul de reţea răspunde de alegerea corectă a acestor valori.
Principiul accesului la mediu, cu fante de timp predeterminate (TDMA) elimină structural
orice posibilitate a ciocnirilor de mesaje.
Protocolul combină două modele: timpul controlat şi controlul evenimentelor
externe, în acest scop fiind create două arii complet distincte într-un ciclu de comunicaţie
(figura 12.1):
- segmentul static şi
- segmentul dinamic.
Parte statică
Start trigerat de o bază de
timp sincronă
Configuraţie statică
Parte statică Parte dinamică
Start trigerat de o bază de
timp sincronă
Configuraţie mixtă
SOC Parte dinamică
Start trigerat de SOC
Configuraţie dinamică
Fig. 12.1
188
În figura 12.2 este prezentat un ciclu de comunicaţii FlexRay.
Comunicaţiile se desfăşoară cu ajutorul ciclurilor de comunicaţie recurente, fiecare
cuprinzând un segment static, un segment dinamic, o fereastră simbol opţională şi, în final,
o fază în care reţeaua este la mers în gol (idle mode, numit NIT – network idle time). Acest
ciclu este iniţializat de nodul manager de reţea.
Cadrul de comunicaţii FlexRay cuprinde câmpuri de date separate (figura 12.3):
Triggerare derivată din baza de
timp sinconizată (eveniment
start ciclu)
Triggerare derivată din baza de
timp sinconizată (eveniment
start ciclu)
Timp mers în gol
reţea
Segment
static
Segment
dinamic
Fereastră
simbol
Timp mers în gol
reţea
Segment
static
t
Ciclu de
comunicaţie x-1 Ciclu de comunicaţie x
Ciclu de
comunicaţie x+1
Fig. 12.2
Frame ID lung. sarc. Header NR. data 0 data 1 …. data n CRC CRC
CRC
utilă CRC ciclu
11 biţi 7 biţi 11 biţi 6 biţi 0 … 254 biţi 24 biţi
Segment header lung. sarcina. utilă
header Segment header
Cadru FlexRay 5 + (0 … 254) + 3
bytes
Fig. 12.3
Bit rezervat
Indicator start-up
cadru
Indicator cadru de sincronizare
cadru
Indicator cadru nul
Indicator introducere încărcare
Header CRC arie de acoperire
1 1 1 1 1
189
- header-ul;
- câmpul de date utile;
- cadru sfârşit câmp.
Header
Începând cu o secvenţă numită secvenţă start cadru (FSS – frame start sequence),
având 8 biţi de ‘’0’’ fără un bit de START sau STOP, header-ul este codificat în 40 biţi (5 +
11 + 7 + 11 + 6), făcând in total 5 bytes. Semnificatia celor 5 bytes, în ordinea apariţiei lor,
este următoarea:
Rezervat = 1;
Indicator introducere încărcare;
Indicator cadru nul;
Indicator cadru de sincronizare:
‘’0’’ indică transmisia unui cadru normal
‘’1’’ indică transmisia unui cadru de sincronizare folosit pentru sincronizarea clock-
urilor.
Indicator start-up cadru.
Indicator cadru (Frame ID) Conţine 11 biţi (de la 1 la 2047, valoarea ‘0’’ fiind ilegală) şi defineşte doi parametri
importanţi de comunicaţie:
Poziţia fantei de timp în segmentul static;
Nivelul de prioritate în segmentul dinamic. O valoare scăzută indică o prioritate
înaltă.
În plus, două controlere sunt interzise de la transmiterea cadrelor, având acelaşi
identificator, în acelaşi canal de transmisie.
Lungime sarcină utilă (payload lenght) Cei 7 biţi ai câmpului (maxim 128 valori) indică valoarea (împărţită la 2 deoarece
lungimea cuvântului este de 16 biţi) numărului de cuvinte transmise în câmpul payload
(lungime sarcină utilă) de maxim 254, de la 0 la 123. Valorile care depăşesc 123 sunt tratate
ca erori. Lungimea sarcinii utile poate include identificatorii de mesaje (în 0 sau 16 biţi).
Header CRC CRC-ul câmpului header are 11 biţi pentru a proteja lungimea şi sincronizarea
bitului cu o distanţă Hamming de 6. Acest CRC este configurat de controlerul gazdă
responsabil de comunicaţie şi este verificat de controlerul care îl recepţionează.
Numărătorul de cicluri
Are 6 biţi (dând 64 de valori), indică numărul ciclului de comunicaţii curent şi se
comportă ca un index de continuitate pentru comunicaţii. Este incrementat automat de
controler şi trebuie să fie identic pentru toate cadrele transmise într-un ciclu de comunicaţie.
Deoarece are 6 biţi, incrementarea sa nu este infinită şi are o periodicitate recurentă.
Câmp sarcină utilă (payload field)
Transportă data utilă (de la 0 la 254 bytes) şi constă în două elemente esenţiale
pentru protocolul FlexRay: segmentul static şi segmentul dinamic (figura 12.4).
190
Segmentul static
Aşa cum indică partea stângă a diagramei, porţiunea din ciclul de comunicaţie în
timpul căreia accesul la mediu este controlat şi monitorizat de un acces multiplu cu
divizarea timpului static (TDMA) este numit segment static al protocolului FlexRay. Scopul
acestui segment este de a asigura comunicaţia deterministă, de a defini semanticile
(sensurile) mesajelor de stare şi de a gestiona sistemul distribuit şi buclele închise de
control. Acestea oferă beneficii majore pentru proiectarea şi simularea funcţiilor distribuite.
Câmpul sarcină utilă este iniţial împărţit în fante de timp egale, incluzând câteva
spaţii rezervate, bine structurate, apoi START şi END la momente de timp bine precizate de
aplicaţie. Fiecare fantă de timp este reprezentată de un identificator unic (ID). Aceste fante
de timp trebuie alocate prin nume unor noduri sau funcţii, structura prevenind orice
perturbare a comunicaţiilor între noduri. Astfel, avem:
Acces la mediu cu timp distribuit asigurat (TDMA);
Evitarea apariţiei ciocnirilor;
Proiectarea unui sistem de timp real, deoarece latenţele sunt cunoscute;
Proiectarea unui sistem cu lăţime de bandă cunoscută, pentru un timp de bit dat.
Ciclu de comunicaţie
Acces multiplu cu divizarea timpului fixată
Acces multiplu cu divizarea
timpului flexibilă
A1
A1 B
C1
C1
D1 A2
A2
E1
E1 F1
D2 C2 E2
A3 C2
Silence Silence Silence
Cadru fizic Cadru fizic
T_wx_delta
t
t
1 2 3 4 5 6 7 8
1
Fig. 12.4
9 12
1 3 4 5 6 7 2 8 10
191
Segmentul dinamic
Partea dreaptă a aceleeaşi diagrame prezintă porţiunea din ciclul de comunicaţie în
timpul căreia accesul la mediu este controlat şi monitorizat de mini-fante, cunoscute ca
acces multiplu cu divizarea flexibilă a timpului (FTDMA – flexible time division multiple
access). În protocolul FlexRay, acesta se numeşte segment dinamic. În segmentul dinamic,
accesul la mediu este permis dinamic în funcţie de nivelul de prioritate atribuit nodurilor
care au date de transmis, prin valoarea cadrului ID conţinut în header-ul mesajului. Scopul
acestui sement este asigurarea comunicaţiilor prin limite de timp şi lăţime de bandă.
Segmentul este divizat iniţial de proiectant în mini-fante de timp egale, care încep şi se
încheie la momente de timp precise (figura 12.5).
Fiecare dintre noduri este apoi liber să modifice durata fantelor de timp în funcţie de
cantitatea de date ce trebuie transmisă, pentru a îndeplini cererile, la un nivel sigur de
arbitrare a accesului la mediu pentru:
Furnizarea accesului uşor la mediul cu timp distribuit (acces la mediu cu tip
distribuit flexibil, FTDMA) şi un sistem cu lăţime de bandă variabilă;
Activând arbitrarea la ieşirea di reţea;
Transferând mesaje spontane;
Asigurând transmisia spontană;
Gestionarea diagnozei datelor;
Transferul oricăror tipuri de mesaje, în orice mod
Câmpul sfârşit cadru
Are 24 de biţi şi protejează integritatea cadrului cu o distanţă Hamming de 6.
A1 B1 C1 D1 E1
Minifanta t_wx_delta
t
Fig. 12.5
11 14 15 17 16 22 12 10 13 18 19 20 21 23 24 25 26 27
C2
ID unic
IDA1=11, IDB1=14, … lung.fantelor depinde
de nr. de date transmise
minifanta începe când cadrul termină
Δttransmiţător=t_wx_tx+t_wx_delta
Δtreceptor=t_wx_rx+t_wx_delta
192
CAPITOLUL 13
SINTEZA SISTEMELOR DE TIMP REAL FOLOSIND
GRAFURI DE PROCESARE
13.1 Constrângeri de timp în sistemele de timp real
Într-un sistem de timp real pot apare, din diverse motive, constrângeri de timp
(datorită algoritmului de proiectare ales, a condiţiilor de mediu de funcţionare, etc.).
Constrângerile uzuale sunt numite constrângeri standard şi acestea sunt perioadele şi
termenii limită. Ele sunt impuse de către proiectant. În afara constrângerilor standard, în
sistemele de timp real apar şi alte constrângeri, datorită condiţiilor de funcţionare. Acestea
din urmă sunt însă mai puţin restrictive.
Aplicarea constrângerilor standard de timp (termenii limită şi perioadele) duc la
următoarele două limitări:
- supraconstrâng specificaţiile din sistem şi
- lipsesc de expresivitate sistemul.
Nu toate job-urile unei aplicaţii în timp real au perioade şi termeni limită “naturali”,
ci doar unele dintre ele. Restul sunt obţinute în timpul proiectării sistemului şi sunt numite
artefacturi. Termenul limită şi perioada nu pot fi selectate amândouă odată ci pe rând.
În general, aplicaţiile în timp real (cum ar fi, de exemplu, aplicaţiile de control) au
constrângeri de timp care nu pot fi exprimate prin termeni limită şi perioade sau care
supraconstrâng puternic sistemul dacă sunt exprimate prin intermediul constrângerilor de
timp standard.
În cele ce urmează, vor fi descrise limitările constrângerilor de timp standard şi
impactul lor asupra sistemelor în timp real folosind ca exemplu manipularea unui
eveniment sporadic.
a) Job-uri pseudoperiodice
Se consideră un eveniment sporadic pe care îl vom nota cu e. Când are loc un astfel
de eveniment, sistemul trebuie să reacţioneze într-un anumit interval de timp dat, notat
react. Timpii exacţi la care se produce evenimentul e nu pot fi determinaţi dinainte, dar se
poate stabili un interval minim de timp, notat mint.
Pentru evenimentul e, se consideră un job notat cu Je, care are un timp maxim de
execuţie c(Je). Evenimentul e trebuie să facă parte dintr-un job periodic, cu perioadă şi
termen limită fixaţi pentru Je. Cazurile în care Je manevrează evenimentul sporadic e,
fezabile în timp, sunt următoarele: fiecare eveniment e este manevrat de un caz al job-lui Je
in interiorul intervalului de timp react şi nu se pierde nici o realizare a evenimentului e.
În cel mai defavorabil caz, un eveniment el se produce la momentul t(e
l) – imediat
după momentul când job-ul Jei a început să fie executat de către sistemul de timp real –
verificat pentru evenimentul e şi găsit că nu a avut loc. În acest caz, evenimentul el va fi
manevrat de următorul job, notat Jei+1
.
193
Conform afirmaţiilor făcute mai sus, putem scrie că :
d(Jei+1
) – t (el ) < react. (13.1)
unde prin d s-a notat termenul limită (engl. deadline).
Într-un sistem de timp real, două evenimente de tip e sunt separate prin cel puţin un
interval de timp egal cu mint. Cu scopul de a nu pierde nici un eveniment, la un interval mai
mic decât separarea prin mint trebuie declanşate două situaţii consecutive ale job-ului Je..
Astfel:
st(Jei+1
– Jei )< mint. (13.2)
unde st indică momentul (timpul) de start. Aceste condiţii de realizabilitate permit alegerea
unor constrângeri de timp diferite pentru unele situaţii individuale ale job-ului Je.
b) Constrângeri de timp impuse de modelul job-ului
Deoarece modelul job-ului impune perioada p şi termenul limită d, ca şi
constrângeri de timp, proiectantul trebuie să transforme în mod corespunzător condiţiile de
realizabilitate (2.3). Astfel:
1. p(Je) + d(Je) < react (13.3)
2. p < mint
Aceste cerinţe ar putea fi îndeplinite de diferite perechi termen limită - perioadă.
13.1.1 Selecţia unei singure perechi perioadă - termen limită
În ultimul pas al proiectării sistemului (adică, după stabilirea condiţiilor de
funcţionare, mediului de lucru, constrângerilor de timp nestandardizate, funcţiilor de calcul,
etc.) este necesară selectarea constrângerilor de timp standard, adică alegerea unei singure
perechi perioadă - termen limită, abandonând astfel alte perechi egal realizabile.
Exemplu: Pentru a ilustra această selecţie, se consideră următoarele un caz numeric
cu următoarele date iniţiale pentru evenimentul e şi job-ul spoardic Je :
- intervalul de timp de reacţie a sistemului de timp real: react = 61,
- intervalul de timp minim de producere a evenimentului e: mint = 70,
- timpul maxim de execuţie al job-ului Je este: c(Je) = 9.
Presupunem că, din setul de perechi realizabile perioadă- termen limită se selectează
cinci perechi. Fie acestea următoarele perechi: (50,10), (40,20), (30,30) şi (10,50).
Sistemul de timp real conţine job-ul sporadic Je şi două job-uri periodice, Jp0 care au
timpul maxim de execuţie c(Jp0) = 10, perioada p(Jp0) = 30 şi termenul limită d(Jp0) = 30,
respective job-ul Jp1 cu timpul maxim de execuţie c(Jp1) = 30, perioada p(Jp1) = 70 şi
termenul limită d(Jp1) = 70.
Fie utilizarea sistemului definită ca raportul între timpul maxim în care sistemul
execută şi timpul total de funcţionare (execuţie şi mers în gol).
194
În tabelul 13.1 sunt date valorile calculate pentru utilizăarea sistemului pentru job-
urile considerate mai sus: Jp0, Jp1 şi Je.
Tabelul 13.1
Jp0 Jp1 Je
c 10 30 9 9 9 9 9
d 15 70 10 20 30 40 50
p 30 70 50 40 30 20 10
utotal 0.94 0.99 1.06 1.21 1.66
`Conform tabelului de mai sus, se constată că perechea (50,10) are cel mai scăzut
necesar de utilizare, dar de asemenea cel mai strâns termen limită, făcând-o mai dificilă
pentru găsirea de programe realizabile. De fapt, dacă se consideră începutul tuturor job-
urilor la momentul de timp 0, va exista o ciocnire între job-urile J0 şi Je la momentul 150
care nu poate fi evitată deoarece d(Je) este foarte strâns, nepermiţând nici o schimbare a
job-ului Je. Acest lucru poate fi evitat prin selectarea unei valori mult mai relaxată pentru
d(Je). Aşa cum se poate observa din tabel, totuşi, noul set de job-uri poate deveni
nerealizabil datorită cererilor crescute de procesare pentru Je.
Concluzii: Specificaţia devine crescător supraconstrânsă. Folosind constrângerile de
timp, informaţiile despre opţiunile posibile sau altă selecţie sunt pierdute în fiecare pas. În
locul reprezentării informaţiilor despre realizabiltatea în timp a job-ului, se reţine numai
rezultatul sub formă de numere.
Alte limitări ale constrângerilor de timp standard:
- cerinţe dependente de date, în care proprietăţile de timp (perioadele) depind de
datele de intrare (de exemplu, citirea datelor de la sensori);
- cerinţe dependente de timp, când timpul real (termenul limită) devine cunoscut
doar în momentul funcţionării (de exemplu, poziţionarea elementelor de acţionare);
- cerinţe de calitate, cu constrângeri care implică mai multe elemente;
- descompunerea termenilor limită capăt la capăt (end-to-end) şi
- distribuţia.
13.1.2 Constrângeri de timp dinamice
Constrângerile de timp dinamice rezolvă problemele menţionate mai sus.
Informaţiile despre realizabilitatea în timp şi valorile alternative întâlnite în timpul
procesului de proiectare sunt păstrate numai ca o compensare la numerele rezultante în aşa-
numitele entităţi de timp pentru accesul rapid pe durata proiectării şi programării.
Entitatea de timp (TE) este o unitate funcţională, adică o activitate a sistemului cu
constrângeri de timp, cum ar fi un job dintr-o aplicaţie în timp real sau un mesaj, combinată
cu o funcţie de realizabilitate care verifică timpul curent pentru TE.
Opţional, poate fi prevăzută o funcţie de urgentare (instaurare) pentru generarea
setărilor de timp realizabile.
Majoritatea activităţilor într-un sistem de timp real sunt de tip periodic şi au un
anumit număr de momente de apariţie în timpul funcţionării.
195
Ca urmare, avem în vedere următoarele tipuri de constrângeri:
a. Constrângeri de timp ale apariţiei - ITC (engl. Instance Timing Constraints)
reprezintă setul de constrângeri de timp pentru o singură apariţie a unei entităţi de timp TE.
Ele sunt aceleaşi pentru toate apariţiile acestei entităţi de timp TE.
b. Constrângeri de timp statice - sTC (engl. Statical Timing Constraints)
reprezintă constrângerile de timp ale unei entităţi de timp TE care rămân fixe pe întreaga
durată de funcţionare. Constrângerile de timp standard (perioadă, termen limită, etc.)
reprezintă constrângeri de timp statice.
c. Constrângeri de timp dinamice - dTC (engl. dinamic Timing Constraints) sunt
acele constrângeri de timp ale unei entităţi TE, care pot varia pentru fiecare apariţie ale
entităţii în timp. Constrângerile de timp pot fi diferite pentru fiecare apariţie.
Funcţia de fezabilitate - FF (engl. Feasability Function). Fiind dat un set static sau
situaţii cu constrângeri de timp de tip TC, pentru o entitate de timp TE, funcţia de
fezabilitate determină dacă cererile de timp ale entităţii de timp TE sunt îndeplinite de
aceste constrângeri de timp TC .
Funcţia de urgentare (instaurare) - IF (engl. Instantiation Function) instaurează
un set de constrângeri statice de timp realizabile ITC [60]. O funcţie de instaurare poate
varia timpii de start, perioada p sau timpii limită dl. Pentru exemplificare se consideră un
job pseudoperiodic şi se construiesc entităţile de timp (TE).
Unitatea funcţională este job-ul Je , care manevrează evenimentul e.
Constrângerile de timp dinamice ale apariţiei i sunt determinate de informaţia
despre realizabilitatea în timp a evenimentului sporadic:
i = 0 : starttime(Jei) < mint
i > 0 : starttime(Jei ) – starttime(Je
i – 1 ) < mint
endtime(Jei ) – starttime(Je
i – 1 ) < react (13.4)
Constrângeri de timp statice ale situaţiei:
p(Je) + d(Je) < react, p < mint (13.5)
În cazul constrângerilor dinamice de timp trebuie avute în vedere următoarele:
- selectarea constrângerilor de timp standard corespunzătoare,
- schimbarea constrângerilor de timp în timpul construcţiei programului şi
- programarea directă a entităţilor, evitând în totalitate artifact-urile termenului limită şi
perioadelor.
Cererile de calitate pentru un algoritm de control sunt transformate în cerinţe de timp
ale job-urilor de control, de exemplu perioada de eşantionare şi întârzierile buclei de
reacţie, cu toleranţele corespunzătoare. Trebuie selectate valorile concrete pentru perioadă
şi termenul limită.
196
13.2 Programarea constrângerilor de timp în sistemele de timp real
Selectarea constrângerilor de timp statice
Dacă se utilizează un algoritm de programare standard cu constrângeri de timp
standard, atunci se va alege o specificaţie cu constrângeri de timp dinamice. Dacă în
procesul de proiectare se introduce un artefact de supraconstrângere, atunci vor fi luate în
calcul diferitele opţiuni şi fezabilitatea (realizabilitatea) lor. După încheierea specificaţiei
este necesară efectuarea unui test de programabilitate. Dacă acesta nu reuşeşte, se vor lua în
considerare constrângerile standard ce candidează pentru instaurare.
Selectarea constrângerilor de timp dinamice
Un programator static poate folosi constrângeri de timp dinamice pe durata
construcţiei programului. Deşi acestea rămân fixate odată ce programul a fost construit,
programatorul are mai multă flexibilitate şi pot fi găsite mai multe soluţii.
O altă îmbunătăţire faţă de constrângerile de timp standard este aceea că
programatorul poate considera şi selecta constrângerile individuale exprimate prin
constrângeri de timp dinamice (dTC) pe durata construcţiei programului.
Programarea entităţilor de timp
Metodele anterioare au propus folosirea programării standard şi a constrângerilor de
timp standard, ca o linie de bază pentru aplicarea constrângerilor de timp dinamice:
informaţiile de cel mai înalt nivel despre entităţile de timp sunt utilizate pentru a instaura
cel mai scăzut nivel al constrângerilor folosite de către algoritmi. Aceste constrângeri pot fi
abandonate şi înlocuite de unele noi furnizate de informaţiile din entităţile de timp.
Se va dezvolta un algoritm capabil să programeze în mod direct entităţile de timp.
Metodele de programare pentru îndepliniea constrângerilor şi aplicabilitatea lor sunt
necesare datorită sprijinului acestora la specificarea soluţiilor algoritmilor.
13.3 Teoria programării cu grafuri
O mare varietate de sisteme de timp real, incluzând filtrele digitale, sistemele de
comunicaţii multimedia, sistemele de procesare a tranzacţiilor “on-line”, sistemele pentru
schimburi de mesaje, sistemele de control de fabricaţie şi sistemele de control al proceselor
ţin cont de aceste soluţii.
Algoritmii care stau la baza modelelor de sisteme distribuite de timp real au suportul
în calculul ponderat şi în programarea liniară. Aceste calcule sunt utilizate în scopul
simplificării sistemelor, pentru realizarea unei analize corecte la toate nivelele de prioritate.
Algoritmii oferă garanţii arbitrare referitor la îndeplinirea constrângerilor de timp ale
reţelelor, pentru intervale mici de timp. Astfel, sistemul poate garanta răspunsul în timp real
al procesului care a fost implementat. În multe metodologii ale grafurilor de procesare în
timp, nu pot fi analizate proprietăţile programării, latenţei, cererile de memorie şi cererile
de stocare deoarece ele depind de timpul de execuţie.
Prin aplicarea teoriei de programare la un graf PGM (Programming Graph Method),
se poate sintetiza o aplicaţie de timp real de la un graf general de procesare. Când graful
satisface condiţia de programare pentru un anumit program prescris EDF, pot fi limitate
cererile de stocare pentru fiecare coadă de date (mesaje, evenimente aflate în aşteptare).
197
În majoritatea aplicaţiilor de procesare a semnalelor, limitarea cererilor de memorie
pentru fiecare coadă conduce la obţinerea unor limite de stocare optime pentru întregul graf.
Prin metoda sintezei se obţine un cadru de evaluare a programabilităţii şi cererilor de
memorie, însă rămâne deschisă problema partiţionării grafului de procesare într-un sistem
distribuit, când graful nu este programabil pe un sistem uniprocesor.
Prin selectarea riguroasă a termenilor limită corespunzători nodurilor din graf, o
execuţie programată dinamic a grafului foloseşte mai puţin spaţiu de stocare decât
implementările planificate cu programe de tip off-line state-of-the-art. Până nu demult,
programarea off-line era favorabilă deoarece aceasta cerea termeni limită mici şi o
capacitate mare de procesare a semnalelor. Astăzi, deoarece viteza de procesare continuă să
crească mai repede decât densităţile de memorie, administrarea memoriei devine critică
pentru multe aplicaţii de procesare a semnalelor. Prin utilizarea unora din capacităţile
procesorului în deciziile de procesare on-line, se poate obţine o latenţă mai bună şi se
utilizează mai puţină memorie decât în cazul programării off-line.
În ceea ce priveşte restricţiile de mediu asupra mărimii, greutăţii şi consumului de
putere, acestea au fost de multe ori limitate atât de capacitatea de procesare cât şi de
capacitatea de stocare a sistemelor de procesare a semnalelor. Datorită creşterii vitezei de
procesare, densităţii de memorie şi performanţă, capacitatea procesorului nu mai constituie
o problemă majoră pentru multe aplicaţii de procesare a semnalelor. Folosirea memoriei
este în momentul de faţă o problemă prioritară.
Analizele în timp real implică adesea analize de timp pentru a afla dacă unitatea
centrală de procesare are capacitate de procesare suficientă pentru a realiza execuţia în timp
real. Se folosesc analize de timp pentru administrarea cererilor de memorie. Analiza
cererilor de memorie comportă două aspecte: cereri de cod şi cereri pentru stocarea de date.
Programarea statică Prin utilizarea programării statice se realizează o minimizare a cererilor de memorie
pentru marginile de intrare sau de ieşire ale unui graf. Programele statice de execuţie ale
nodurilor sunt create “off-line” şi apoi executate pe o bază periodică folosindu-se algoritmi
de programare statici.
Programarea dinamică
În cazul programării de tip dinamic, pentru execuţia grafului se foloseşte un
programator simplu, dinamic, on-line pentru obţinerea unei memorii optimale. Cererile de
memorie sunt mai mici în acest caz decât în cazul utilizării programelor statice create prin
programarea off-line.
Programarea în timp real
Pentru realizarea programării în timp real, trebuie construit un sistem cu timp de
rulare prescris, astfel încât spaţiul de stocare cerut pentru marginile de intrare şi de ieşire ale
grafului să poată fi limitat şi controlat. Pentru aceasta, se apelează la un graf de procesare
realizat pentru un set de job-uri care respectă un model de execuţie în timp real. Condiţiile
de programare pentru model stabilesc dacă graful se adaptează la procesor, adică dacă este
disponibilă suficientă capacitate de procesare pentru garantarea execuţiei în timp real a
tuturor job-urilor. Prin execuţie în timp real se înţelege o execuţie în care sunt respectate
cererile de latenţă şi memorie. Pentru grafurile de procesare a semnalelor, latenţa este
timpul între momentul când un senzor produce o dată simbol şi momentul când graful dă la
ieşire semnalul procesat.
198
13.4 Metoda grafului de procesare PGM
Prin metoda grafului de procesare PGM (engl. Processing Grapf Method) pot fi
evaluate cererile de administrare a procesorului, latenţa şi utilizarea memoriei în sinteza
sistemelor distribuite de procesare a semnalelor. Administrarea cererilor de memorie se face
prin grafuri de procesare aciclice. Programarea dinamică on-line poate asigura cereri de
memorie aproape minime.
Grafurile dirijate formate din noduri care reprezintă funcţii de procesare, şi
marginile grafului care descriu fluxul de date de la un nod către următorul, sunt utile în
proiectarea standard pentru dezvoltarea sistemelor de procesare a semnalelor digitale
complexe. Când ajung suficiente date la un nod, acesta execută funcţia sa de la început
până la sfârşit, în mod izolat (adică, fără a se sincroniza cu celelalte noduri).
Astfel de grafuri dirijate sunt numite grafuri de procesare (engl. Processing
Graphs) şi descriu modul de procesare a semnalelor. Fiecare nod reprezintă o funcţie
matematică, dependentă de un curent de date care curge pe marginile grafului, de la
nodurile sursă (de obicei, senzori) către nodurile formate (dispozitive de ieşire).
Metodologia grafului de procesare permite înţelegerea mai uşoară a procesării
semnalelor prin alegerea unei structuri de algoritm de tip grafic. Un avantaj important al
reprezentării grafice este acela că, porţiuni ale operaţiei de procesare a semnalelor
(subgrafuri) pot fi înţelese chiar în absenţa întregului algoritm. Optimizarea compilatoarelor
şi eficienţa conduitei de scriere poate ajuta la minimizarea spaţiului cerut pentru formarea
cozii, însă grafurile de procesare cer, de asemenea, şi spaţiu de stocare pentru rezultatele de
procesare imediate stocate temporar pe marginile grafului. Odată ce nodul îşi încheie
execuţia, el adaugă datele la margine conectându-le la un nod cu consum redus de flux de
date. În momentul în care s-au acumulat suficiente date pe marginea de intrare a nodului
consumator, acesta execută şi rearanjează datele de intrare. Spaţiul cerut pentru păstrarea
rezultatelor intermediare pe toate marginile grafului simultan poate fi destul de mare. Odată
ce a fost creat graful de procesare, singura variabilă liberă ce controlează cantitatea de date
stocată pe o margine în relaţia de execuţie dintre nodurile producătoare şi consumatoare
este termenul limită.
Un graf de procesare este descris formal ca un graf dirijat (sau digraf) notat G =
(N,M,). Tripleta (N,M,) constă dintr-un set finit N de noduri, un set finit M de margini şi
o funcţie de incidenţă care asociază fiecărei margini din M, o pereche (nu neapărat
distinctă) de noduri din N.
Fie o margine m M şi nodurile u,v N, astfel încât (m)=(u,v). Spunem că
marginea m alătură nodul u la nodul v sau că u şi v sunt adiacente. Nodul u este numit coada
nodului sursă al marginii m şi v este capul nodului marginii m.
Marginea m este definită ca margine de ieşire pentru nodul u şi margine de intrare
pentru nodul v. Numărul marginilor de intrare pentru un nod v este notat -(v) iar numărul
marginilor de ieşire este +(v). Folosind aceste notaţii, se pot deduce următoarele:
Un nod cu -(v) = 0 este un nod de intrare. Fie I = {v vV -
(v) = 0} setul tuturor
nodurilor de intrare.
Un nod cu +(v) = 0 reprezintă un nod de ieşire. Fie O = {v vV +
(v) = 0}
setul tuturor nodurilor de ieşire.
Putem afirma că între nodurile u, v V, există o cale notată cu u ⇝ v, dacă şi
numai dacă există o secvenţă de noduri (w1, w2, ... , wk), astfel încât w1=u, wk= v şi i, 1 i
199
k: e E :: (e) = (wi, wi+1). Altfel spus, există calea între u = w1 şi v = wk dacă există o
secvenţă de noduri (w1, w2, ... , wk) astfel încât wi este adiacent la wi+1, cu i = 1, 2, ..., (k-1).
13.4.1 Graful PGM
Există multe modele ale grafurilor de procesare, însă metoda de sinteză pentru
construirea sistemelor în timp real, în scopul facilitării proiectării şi implementării
aplicaţiilor de procesare a semnalelor, se bazează pe graful PGM.
În PGM, un sistem este exprimat printr-un graf dirijat în care nodurile reprezintă
funcţii de procesare, iar marginile reprezintă canale de comunicaţii bufferate, numite cozi.
Funcţia este implicit definită de topologia grafului printr-o arhitectură software
independentă de aplicaţia hardware gazdă. Marginile grafului sunt denumite şi cozi FIFO
(engl. First-In-First-Out) cu trei atribute asociate fiecărei cozi:
- o cantitate de produs, notată p(q),
- o cantitate de prag, notată s(q) şi
- o cantitate de consum, notată c(q).
Cantitatea creată specifică numărul de simboluri (elemente de date de structură
adăugate cozii (sau marginii), atunci când nodul producător (respectiv, nodul sursă pentru
coadă) completează execuţia.
Cantitatea de prag reprezintă numărul minim de simboluri cerut a fi prezent în coadă
(margine) înainte ca nodului să-i fie permis să proceseze datele de la coada de intrare.
Cantitatea de consum este numărul de simboluri luate din coadă (din capul cozii)
după ce funcţia de procesare îşi încheie execuţia.
Spunem că o margine este cu prag depăşit, dacă numărul de simboluri neatribuite
marginii este egal sau mai mare decât cantitatea de prag s(q).
PGM permite mărimi produs, prag şi consum neunitare, precum şi o cantitate de
consum, mai mică decât cea de prag. Singurele restricţii asupra atributelor cozilor sunt
acelea că ele trebuie să fie valori nenegative iar cantitatea de consum trebuie să fie mai
mică sau egală cu cantitatea de prag. Pentru exemplificare, considerăm porţiunea lanţului
reprezentat în figura 13.1.
Marginea etichetată q conectează nodurile u şi w şi are: p(q) = 4, s(q) = 7 şi c(q) = 3.
Nodul u trebuie să execute de două ori înainte ca nodul v să fie primul ales pentru execuţie.
După ce nodul v îşi încheie execuţia, el consumă doar 3 din cele 8 simboluri din marginea
sa de intrare. Adesea, filtrele de procesare a semnalelor utilizează o cantitate de prag care
este mai mare decât cantitatea de consum. Filtrul citeşte simbolurile s(q) de la margine, dar
consumă numai c(q) simboluri, lăsând în final (s(q) - c(q)) pe margine pentru a fi folosite în
calculul următor.
w u
Fig. 13.1 Un lanţ cu două noduri
q
p(q)= 4 s(q)=7
c(q)=3
200
În cazul în care un nod are mai multe margini, atunci acel nod este ales pentru
execuţie în momentul când toate marginile (sau cozile de intrare) au pragul depăşit (adică,
atunci când fiecare margine de intrare q conţine cel puţin s(q) simboluri). După ce funcţia
de procesare îşi termină execuţia, fiecărei margini de ieşire q îi sunt adăugate p(q)
simboluri. Înainte ca nodul să îşi încheie execuţia, dar după ce datele sunt produse, din
fiecare margine de intrare q sunt scoase c(q) simboluri.
Spunem că execuţia unui nod este validă, dacă şi numai dacă nodul execută numai
când este ales pentru execuţie şi nu se suprapun două execuţii ale aceluiaşi nod, fiecare
margine de intrare a consumat datele după ce fiecare margine de ieşire şi-a produs datele.
Datele sunt produse la cel mult o margine de ieşire pe durata fiecărei execuţii a nodului.
O execuţie de graf constă într-o secvenţă (posibil infinită) de execuţii de noduri. O
execuţie de graf este validă dacă şi numai dacă toate nodurile din secvenţa de execuţie au
execuţii valide şi nu se înregistrează pierderi de date. S-a ales ca model graful de procesare
PGM, deoarece el este generat cu paradigma cu legături multiple. Sinteza anterioară a
sistemelor de procesare în timp real de la PGM se baza pe grafuri simple PGM, numite
lanţuri.
În continuare, se va extinde analiza pentru lanţuri care păstrează grafuri ciclice
dirijate. În consecinţă, vor fi prezentate noi metode pentru minimizarea spaţiilor de
memorie în cazul grafurilor comune, ciclice, de tip PGM executate cu acelaşi programator
simplu, prioritar, cu termen limită.
Graful este descris cu ajutorul modelului procesului cu execuţie bazată pe viteze
RBE (Rate-Based Execution process model), o generalizare a modelului de proces sporadic.
Modelul de procesor RBE permite execuţia nodului cu o viteză medie, determinabilă. pentru
grafurile de tip PGM. Forţând toate nodurile din graf să aibă o execuţie periodică, latenţa
semnalului procesat creşte dar se simplifică analiza cererilor de memorie.
13.4.2 Parametrii care influenţează latenţa şi limitele de stocare
Pentru un graf dat, latenţa reprezintă intervalul de timp între momentul în care
primul nod începe să execute şi momentul în care ultimul nod din graf încheie execuţia şi
trimite la ieşire datele corespunzătoare funcţiei de execuţie. Într-un graf, singurii parametri
liberi care influenţează latenţa şi limitele de stocare sunt termenii limită.
Dacă cererea de latenţă din aplicaţie este mai mică decât valoarea latenţei dedusă
sub ipoteza de sincronizare puternică (ex. (F(N0, Nn).y0), atunci graful dat nu va satisface
cererea de latenţă niciodată.
Dacă cererea de latenţă este mai mare decât limita stabilită prin ipoteza de
sincronizare puternică dar mai mică decât limita inferioară, schimbarea termenilor limită nu
va ajuta graful să satisfacă cererea sa de latenţă; în acest caz este necesară folosirea unei
unităţi centrale de procesare mai rapide.
Dacă cererea de latenţă este mai mare decât această limită inferioară dar mai mică
decât limita superioară (F(N0, Nn) - 1).y0 + dn (unde di < di+1 , 1 i < n) atunci se vor
urma procedurile de reducere a latenţei până la limita dorită. Dacă acest lucru nu este
posibil, atunci vor fi necesare costuri suplimentare pentru schimburi externe. De exemplu,
dacă tehnica de atribuire a termenului final nu este posibilă datorită cedării limitelor de
latenţă satisfăcătoare înainte ca testul de programabilitate să întoarcă un rezultat negativ, se
poate decide dacă este necesară folosirea unui procesor mai rapid sau adăugarea de
memorie pentru mărirea spaţiului de stocare. Prima alegere rezolvă problema latenţei,
201
folosind o unitate centrală suficient de rapidă. Adăugarea de memorie nu conduce
întotdeauna la reducerea latenţei.
Pentru susţinerea afirmaţiilor anterioare, presupunem că există un graf pentru care
termenii limită nu au fost reduşi, astfel încât primele k noduri din lanţ au toate temeni limită
egali cu intervalul lor de viteză (di = yi , i : 1 i k ) iar ultimele (n - k) noduri au valori
ai termenilor limită egali cu dk . Limita de latenţă este încă prea mare şi micşorând termenii
limită pentru ultimele (n - k) noduri se obţine un rezultat negativ. Putem reduce limita de
latenţă mai departe, prin setarea tuturor termenilor limită astfel încât cererea de latenţă va
avea valoarea maximă:
Lmax = Latency Requirementiniţial - (F(N0, Nn) - 1). y0 (13.6)
Aceasta duce la creşterea cererilor de stocare pentru primele k noduri, dar poate
produce o stivă suficientă în program, astfel încât graful este acum programabil chiar dacă
termenii limită pentru ultimele (n - k) noduri au fost reduşi în scopul obţinerii limitei de
latenţă dorită. Graful va deveni programabil cu aceşti noi termeni limită însă va avea nevoie
de mult mai multă memorie datorită costurilor de schimb extern: mai multă memorie, o
unitate centrală mai rapidă sau cereri mai mici.
Deoarece aplicaţia propusă are topologia unui lanţ, s-a restrâns analiza la lanţuri iar
rezultatele au fost apoi extinse la grafuri PGM generale.
13.5 Sinteza grafurilor de procesare
Metoda de sinteză implică trei paşi:
1) identificarea vitezelor de execuţie ale nodurilor,
2) maparea fiecărui nod într-un job, în modelul bazat pe viteză, RBE (engl. Rate-
Based Execution) şi
3) verificarea cerinţelor de latenţă şi a cerinţelor de memorie.
Administrarea cererilor de memorie pentru o aplicaţie cere adesea o iteraţie cu paşii
2) şi 3) întrucât schimburile externe sunt făcute între cererea procesorului şi necesităţile de
memorie. Un rezultat afirmativ după testarea condiţiei de programabilitate semnifică faptul
că procesorul are suficientă capacitate pentru a executa graful astfel încât latenţa şi cerinţele
spaţiului de stocare pot fi garantate.
13.5.1 Vitezele de execuţie ale nodurilor
Pentru a introduce noţiunea de viteză de execuţie a unui nod, presupunem ipoteza
de sincronism puternic. În această ipoteză, execuţia grafului se face pe o maşină infinit
rapidă şi fiecare nod execută fără a consuma timp (sistemul reacţionează instantaneu la
stimulii externi). Astfel, procesele nu sunt afectate de programare iar modelele de execuţie
sunt aceleaşi, indiferent de politica de programare folosită. Viteza de execuţie a fiecărui nod
din graf depinde de: topologia grafului, de modul în care au fost definite nodurile, de
atributele fluxului de date şi de viteza cu care nodul sursă produce datele. Astfel, cunoscând
viteza cu care un nod sursă livrează datele, se pot deduce vitezele de execuţie ale tuturor
celorlalte noduri. Această proprietate fundamentală a fluxului de date în timp real stă la
202
baza rezultatelor prezentate în acest paragraf. Multe metode de execuţie în timp real
definesc execuţia unui job ca fiind periodică sau sporadică.
De fiecare dată când un job este ales să execute, se spune că acel job este eliberat.
Un job periodic este eliberat exact o dată la fiecare p unităţi de timp (p poartă denumirea de
perioadă a job-ului). Dacă job-ul este sporadic, atunci cel puţin p unităţi de timp separă
fiecare eliberare a acelui job şi nu poate fi precizată nici o limită superioară pentru
eliberările subsecvenţei unui job sporadic. Chiar atunci când nodul sursă al unui lanţ PGM
este periodic, execuţiile celorlalte noduri din graf nu pot fi descrise ca fiind periodice sau
sporadice. Execuţia job-ului poate fi periodică sau sporadică. Pentru exemplificare,
considerăm lanţul din figura 13.2.
Dacă nodul u execută la momentele 0, y, 2y, 3y, ..., nodul v este ales pentru o
execuţie la momentele y şi 2y şi pentru două execuţii la momentul 3y. Modelul de execuţie
al nodului v este repetitiv, dar niciodată periodic sau sporadic. Chiar dacă execuţia grafului
este forţată astfel încât să se potrivească unui model de job periodic sau sporadic, cu un job
reprezentând fiecare nod, se va introduce latenţă adiţională.
Job-urile periodice sau sporadice multiple pot fi folosite în modelarea nodului. O
paradigmă care foloseşte viteze de forma x pentru execuţiile unui nod în y unităţi de timp
reprezintă un model mult mai simplu pentru analiza programării latenţei şi a cererilor de
stocare într-o aplicaţie a grafului de procesare.
Vitezele de execuţie ale nodului sunt definite după cum urmează: timpul de execuţie
de ordin j al nodului v este reprezentat ca Tj(v). Viteza de execuţie este definită de o
pereche întreagă (x,y). Viteza de execuţie pentru nodul v, notată Rv = (x,y),este validă dacă
nodul v execută exact x timpi în toate intervalele de timp [t, t+ y], unde t > T1(v).
Pentru analiză, se vor considera lanţuri şi grafuri aciclice.
Fie i ⇝ w un lanţ PGM astfel încât, dacă i I (setul nodurilor de intrare), u,v { i
⇝w} cu (q) = (u,v) şi Ri = (xi ,yi ). Presupunând ipoteza de sincronism puternică şi nici
un simbol pe marginea q prioritară la începutul execuţiei grafului, viteza de execuţie a
nodului v este Rv = (xv,yv) unde:
u
u
v xqcxqp
qpx
))(,)(gcd(
)( şi u
u
v yqcxqp
qcy
))(,)(gcd(
)( (13.7)
Prin gcd s-a definit cel mai mare divizor comun (engl. greatest common divider); c
reprezintă cantitatea de consum iar p reprezintă cantitatea de produs.
Ecuaţiile (13.7) pot fi folosite pentru deducerea vitezei de execuţie a oricărui
consumator în limitele producătorilor lui, într-un lanţ de noduri. De exemplu, luând (q) =
Ni Ni+1
Qi-1 Qi Qi+1
p=4 r=7,
c=3
Fig. 13.2 Lanţ între două noduri
203
(u,w) pentru marginea q şi o viteză de execuţie Ru = (3,16) pentru nodul u din figura 13.3
(nodul execută 3 timpi în orice interval de lungime 16), viteza de execuţie a nodului
consumator w este dedusă astfel:
))(,)(gcd(
)(,
))(,)(gcd(
)(),(
qcxqp
yqc
qcxqp
xqpyxR
u
u
u
u
www
16,4)3,12gcd(
48,
)3,12gcd(
12
)3,34gcd(
163,
)3,34gcd(
34
(13.8)
Considerăm în continuare cazul în care nodul w are şi altă margine de intrare, cum
se arată în figura 13.3.
Nodul w este un nod consumator de date produse de ambele noduri u şi v.
Mărimea Rwu = ( xwu , ywu ) reprezintă viteza de execuţie a nodului cu
respectarea datelor produse de nodul u, ca pereche producător / consumator într-un lanţ.
Astfel, Ru = (3,16), Rwu = (4,16), deduse din relaţiile (13.3). Cu Rv = (2,12), Rwv este
calculat astfel:
),( vwvwvw yxR
))(,)(gcd(
)(,
))(,)(gcd(
)(
cxp
c
cxp
xp
vv
v
)2,23gcd(
212,
)2,23gcd(
23 12,3
2
24,
2
6
(13.9)
Deoarece nodul w poate să execute doar când ambele margini şi au pragul
depăşit, nici Rwv, nici Rwu nu satisfac definiţia unei viteze de execuţie valabile pentru
nodul w, deoarece nodul w nu va executa exact 4 timpi în orice interval de lungime 16 sau
exact 3 timpi in orice interval de lungime 12. În general, Rwv Rwu trebuie să fie cazul în
care xwu / ywu. = xwv / ywv. dacă este posibilă execuţia unui graf valid. Intuitiv,
expresia xwu / ywu. = xwv / ywv înseamnă că viteza de execuţie a stărilor regulate a
nodului w în raport cu nodul u este egală cu viteza de execuţie a stărilor regulate a nodului
u
v
w
p()= 4
s()= 7,
c()= 3
s()= c()= 2
p()= 3
Fig. 13.3 Un nod cu două margini de intrare
204
w în raport cu nodul v. Fără egalitatea vitezelor de execuţie ale stărilor regulate ar fi
imposibil să se programeze o execuţie valabilă a grafului folosind memorie finită.
Fie G = (N, M, ) un digraf şi u, v, w N pentru care există marginile şi astfel
încât () = (u, w) şi () = (v,w). Dacă este posibilă execuţia unui graf valabil folosind
memorie finită pentru stocarea (buffering) simbolurilor, atunci:
xwu / ywu. = xwv / ywv. (13.10)
Când un nod consumator are o viteză de execuţie a stărilor regulate constantă, în
raport cu cea a producătorilor, relaţia poate fi generalizată pentru a deduce viteza de
execuţie a unui nod cu margini de intrare multiple.
Fie G = (N, M, ) un digraf PGM pentru care este posibilă o execuţie valabilă
folosind memorie finită şi nodul v N cu -(v) 1. Presupunând ipoteza de sincronism
puternic şi nici un simbol pe marginile de intrare pentru nodul v prioritar la începutul
execuţiei grafului, viteza de execuţie a nodului v este Rv = (xv, yv) unde: lcm = cel mai mic
multiplu comun c.m.m.m.c (engl. lowest common multiple) şi gcd = cel mai mare divizor
comun c.m.m.d.c. (engl. greatest common divider).
,),()(|)(,)(gcd(
)(
vuqqcxqp
yqclcmy
u
v
v (13.11)
),()(:,,)(
)(vuquq
yqc
xqpyx
u
u
vv
De exemplu, fiind date nodurile u şi v din figura 13.2, cu Ru = (3,16) şi Rv = (2,12)
când xwu / ywu. = xwv / ywv., viteza de execuţie pentru nodul w este:
))(,)(gcd(
)(,
))(,)(gcd(
)(lcm
cxp
yc
cxp
ycy
v
v
u
u
w
)2,23gcd(
122,
)3,34gcd(
163lcm 4812,16lcm
2
122,
3
163lcm
163
3448
)(
)(
u
u
wwyc
xpyx
12 (13.12)
Astfel, Rw = (xw , yw) = (12,48) şi, după prima sa execuţie, nodul w din figura 13.3
va executa 12 timpi în fiecare interval de lungime 48.
205
13.5.2 Maparea nodurilor dintr-un graf utilizând modelul RBE
Modelul RBE (engl. Rate Based Execution) este un model de job general alcătuit din
procese independente, specificate cu ajutorul a 4 parametri: (x, y, d, e). Perechea (x, y)
reprezintă viteza de execuţie a job-ului RBE, unde x este numărul de execuţii cerut într-un
interval de lungime y. Parametrul d (deadline) caracterizează timpul de răspuns, adică
timpul maxim dorit între momentul eliberării unui job şi încheierea execuţiei sale (d este
termenul limită relativ). Parametrul e reprezintă timpul maxim cerut de procesor pentru
executarea job-ului.
Un set de job-uri RBE este realizabil dacă există un program prioritar, astfel încât
eliberarea de ordin j a job-ului Ji la momentul ti,j să fie garantată să încheie execuţia în
timpul Di (j) unde:
Di(j) = ti,j + di , dacă 1 j xi şi Di(j) = max (ti,j + di , Di(j - xi) + yi , dacă j > xi
Modelul de job RBE nu precizează momentul când un job va fi eliberat, însă relaţiile
anterioare asigură că, nu mai mult de xi termeni limită vor fi într-un interval de lungime yi,
chiar atunci când într-un interval de lungime yi au loc mai mult decât xi eliberări ale lui Ji.
Funcţia de atribuire a termenilor limită previne acest lucru prin crearea mai multor cereri de
proces într-un interval de un job, decât atunci când acesta este specificat prin mai mulţi
parametri.
Fiecărui nod i se va asocia un job. Astfel, fiecare nod u din graf este asociat cu 4
parametri (xu ,yu ,du ,eu ). Parametrii xu şi yu sunt deduşi din relaţiile (13.12). Parametrul eu
reprezintă timpul de execuţie pentru cel mai defavorabil caz al nodului u. Singurul
parametru liber este parametrul du - termen limită relativ, care influenţează cererile de
capacitate ale procesorului, latenţa şi cererile de stocare. Ỉn general, dacă se alege o valoare
mică pentru du, latenţa va fi mai mică şi cererile de memorie vor fi reduse. Dacă se alege o
valoare mai mare pentru du, latenţa va fi mai mare, cererile de memorie vor fi mai mari şi
va creşte costul cererilor de capacitate a procesorului. Valorile pentru timpul de execuţie,
produs, prag, consum şi termenul limită vor afecta toate programarea, latenţa şi cererile de
stocare, iar una dintre aceste valori poate face schimb cu oricare alta. Termenul limită
relativ trebuie selectat astfel încât rezultatul în stocarea modestă pe marginile grafului să se
facă fără a supraîncărca procesorul cu cereri. Cum du afectează cererile de capacitate ale
procesorului, latenţa şi cererile de stocare, un punct de plecare pentru selecţia lui du este ca
du să fie mai mare sau egal cu termenul limită al nodului prcedent şi mai mic sau egal cu yu.
Când termenul limită al fiecărui nod este mai mare sau egal cu precedentul termen
limită al aceluiaşi nod, se poate utiliza o tehnică de programare numită moştenire de timp de
eliberare, în scopul minimizării latenţei. Nodului u i se atribuie un timp de eliberare logic
(la momentul eliberării lui actuale) care este egal cu timpul de eliberare logic al nodului
care a iniţiat u în timpul execuţiei grafului. Funcţia de atribuire a termenilor limită foloseşte
timpi de eliberare logici în locul timpilor de eliberare reali.
După ce s-a asociat fiecărui nod u din graf parametrii (xu ,yu ,du ,eu), obţinem un
sistem de job-uri RBE de forma J = {J1 ,J2 ,..., Jn}. Un job este eliberat atunci când toate
marginile de intrare ale nodului au pragul depăşit; asigurarea constrângerilor precedente se
face pentru o execuţie corectă a grafului. Job-urile eliberate sunt programate cu algoritmul
de programare RBE-EDF, un program EDF simplu, prioritar, care utilizează funcţia de
atribuire a termenilor limită cu moştenirea timpului de eliberare. Realizarea unui set de job-
206
uri RBE poate fi obţinută cu relaţiile (13.10), care reduc condiţia de realizare EDF stabilită
pentru U 1 când xi = 1 şi di = yi .
Fie J = {(x1 ,y1 ,d1 ,e) ,... ,(xn ,yn ,dn ,en )} un set de job-uri. J va fi realizabil dacă şi
numai dacă:
n
i
ii
i
ii yxy
ydLfLL
1
,0
00
0)(
adaca
adacaaafunde (13.13)
Fie J = {(x1 ,y1 ,d1 ,e1) ,... ,(xn ,yn ,dn ,en )} un set de job-uri pentru care, pentru
maparea u N i : (xi ,yi ,di ,ei) = (xn ,yn ,dn ,en). Conform celor precizate anterior, putem
afirma că, graful de procesare definit prin funcţia G = (N, M, ) este programabil cu
programul RBE-EDF dacă relaţia (2.13) se păstrează pentru J. Un rezultat afirmativ după
testarea relaţiei (2.13) înseamnă că programul RBE-EDF poate fi folosit la executarea
grafului fără a omite nici un termen limită şi cererile de stocare ale fiecărui nod şi de
asemenea ale întregului graf pot fi limitate.
13.5.3 Cereri de stocare şi administrarea memoriei
Cele trei utilizări primare ale memoriei într-un sistem de procesare a semnalelor
sunt următoarele: spaţiu de stocare a datelor finale planificat, spaţiu pentru vehicularea
datelor pe marginile fiecărui nod în parte şi spaţiu de stocare pentru rezultatele intermediare
de pe marginile grafului.
Cererile de memorie pentru primele două sunt aceleaşi pentru oricare dintre
implementări: statică sau dinamică. Pentru administrarea cererilor de memorie ale
marginilor grafului se foloseşte programarea statică. Programele de execuţie ale nodului
static sunt create off-line şi apoi executate pe o bază periodică. O folosire eficientă a
spaţiului de stocare implică spaţiu de stare mai mare pentru program. Spaţiul de stocare
cerut pentru programele statice depinde de algoritmul de programare folosit. Pentru a obţine
spaţiul cerut pentru marginea de intrare trebuie luată în considerare viteza datelor de intrare
şi durata programului. Programele statice sunt de obicei executate pe o bază periodică, cu
un timer ce indică momentul de start al execuţiei programului. Dacă programul execută fără
a insera timp nefolosit (timp în care nu se execută nimic) odată ce începe, atunci execuţia
nu poate începe până când nu au fost acumulate suficiente date pe marginile de intrare ale
grafului, pentru a asigura o execuţie validă a grafului. Perioada unui program static este
egală cu valoarea maximă y a vitezelor de execuţie pentru setul de noduri conectate la
dispozitivele externe. In funcţie de program, timpii de execuţie ai nodului precum şi
caracteristicile execuţiei nodului sursă, se pot acumula mai multe sau mai puţine date în
timpul executării programului. Este importantă cunoaşterea dependenţei de lungime a
perioadei programate şi când anume începe programul static, precum şi cantitatea de date
care se acumulează pe cozile de intrare.
Folosirea algoritmilor de programare off-line pentru administrarea cererilor de
memorie implică un spaţiu mare de stocare în memorie, de aceea se apelează la un program
on-line simplu, dinamic, pentru execuţia grafului. Unul din avantajele modelului RBE faţă
de alţi algoritmi de programare dinamici este acela că are o mare flexibilitate în descrierea
momentelor în care nodurile vor executa. Flexibilitatea în programare are însă şi
207
dezavantajul că face dificilă deducerea limitelor strânse pentru cererile de stocare ale unei
margini.
Regulile de execuţie pentru nodurile PGM cu multiple margini de intrare sunt astfel
încât o margine de intrare poate fi cu prag depăşit cu mult înaintea alteia şi ecuaţiile deduse
din funcţiile pentru limitarea cererilor de stocare nu pot fi aplicate la grafurile PGM
generale. Multe aplicaţii de procesare a semnalelor au caracteristicile fluxului de date astfel
încât să putem obţine limite de stocare cât mai strânse.
13.6 Proprietăţile de timp real în execuţia unui flux de date
Analiza proprietăţilor în timp real ale grafului se face ţinând cont de relaţiile de
execuţie fundamentale care există între nodurile producătoare/consumatoare şi nu depind de
modelul de execuţie. Se definesc mai întâi restricţiile asupra execuţiei nodului. În
concordanţă cu PGM, modelul de execuţie cere ca toate marginile de intrare la un nod să fie
cu prag depăşit înainte ca nodul să fie ales pentru execuţie.
Practica standard în implementarea sistemelor de flux de date, dificilă pentru
specificaţia PGM, constă în a nu permite două execuţii cu depăşire ale aceluiaşi nod iar
datele trebuie citite de la marginea de intrare a nodului care urmează să intre în execuţie la
începutul fiecărei execuţii. Datele sunt consumate după ce nodul a trimis rezultatele finale
ale execuţiei sale către marginile de ieşire, ceea ce arată că, un nod cere simultan spaţii de
stocare atât pentru intrare cât şi pentru ieşire.
Pentru ca nodul să aibă execuţii valide, se presupune că nu se pierde nici o dată în
timpul execuţiilor sale.
Definiţiile care urmează conduc la o bază formală pentru analiza execuţiei
nodurilor, precum şi a proprietăţilor ce stau la baza circulaţiei datelor între nodurile
producătoare şi cele consumatoare, prin canalele de transmisie.
a. Nodul N1 este eligibil (este pregătit pentru execuţie, poate fi ales) pentru execuţie
atunci când toate marginile sale de intrare sunt cu prag depăşit.
b. Execuţia unui nod este validă dacă şi numai dacă :
- nodul execută doar atunci când este ales pentru execuţie şi nu se suprapun două execuţii
ale aceluiaşi nod,
- fiecare margine de intrare are datele sale consumate atomic şi
- datele sunt produse cel mult o dată pe marginea de ieşire în timpul fiecărei execuţii a
nodului.
c. Execuţia unui graf este validă dacă şi numai dacă toate nodurile din secvenţa de
execuţie au execuţii valide şi nu se pierde nici o dată.
Relaţia de execuţie dintre nodurile producătoare/consumatoare se determină
folosind porţiunea de două noduri din lanţul prezentat în figura 13.4.
Ni Ni+1
Fig. 13.4 Lanţ între un nod producător şi un nod
consumator
Qi-1 Qi Qi+1
p=4 s=7,
c=3
208
Lanţul are o margine ale cărei valori de produs, prag şi consum sunt relativ începute
- acest lucru se face pentru a ilustra relaţiile generale între atributele fluxului de date şi
execuţia nodului.
Conform valorilor numerice prezentate în figura 13.4, nodul Ni produce 4 simboluri
de fiecare dată când execută. Nodul Ni+1 are un prag egal cu 7 şi consumă 3 simboluri după
ce execută. În consecinţă, nodul Ni trebuie să execute de două ori înainte de a avea
marginea Qi cu prag depăşit iar nodul Ni+1 să execute pentru prima dată. După ce nodul Ni+1
execută, el consumă doar 3 simboluri, lăsând 5 simboluri pe marginea Qi. A treia execuţie a
nodului Ni produce încă 4 simboluri (pentru un total de 9 simboluri pe marginea Qi) şi nodul
Ni+1 execută din nou, consumând încă 3 simboluri. Următoarea execuţie a nodului Ni
produce încă 10 simboluri pe Qi şi nodul Ni+1 este capabil să execute de două ori - lăsând 4
simboluri pe Qi, care reprezintă acelaşi număr de simboluri care erau pe Qi după prima
execuţie a lui Ni. În acest mod, execuţiile ulterioare ale nodurilor Ni şi Ni+1 vor urmări
acelaşi model.
Latenţa Latenţa, ca o definiţie generală, reprezintă întârzierea în timp măsurată între
momentul eşantionării unui semnal şi momentul prezentării semnalului procesat la
dispozitivele de ieşire (care pot fi un ecran, un difuzor sau alt computer). Latenţa este o
funcţie a algoritmului de programare. În cazul modelelor de graf, latenţa are de asemenea o
componentă structurală. Latenţa unui eşantion al semnalului depinde de atributele fluxului
de date ale grafului şi numărul de simboluri aflate pe fiecare margine sa grafului în
momentul sosirii eşantionului. Se poate calcula mărimea latenţei eşantionului calculând
numărul de eşantioane cerute înainte ca un nod Nn din graf să înceapă să execute.
209
CAPITOLUL 14
PROTOCOLUL SPI
14.1 Introducere
SPI (Serial Peripheral Interface – Interfaţă serială pentru periferice) este un
standard de comunicaţie sincron (asemeni lui I2C) dezvoltat de Motorola, care operează în
mod full-duplex (transferul de date poate avea loc în ambele direcţii simultan).
Dispozitivele interconectate astfel comunică folosind o relaţie de tipul master –
slave, master-ul fiind cel care iniţiază şi controlează fluxul de date care circulă pe
magistrală, indiferent de direcţie. În cadrul acestui protocol sunt suportate mai multe
dispozitive de tip slave, însă nu sunt suportaţi mai mulţi masteri.
SPI se mai numeşte şi "four wire" serial bus pentru al deosebi de celelalte standarde
ce folosesc 1, 2 sau 3 fire. Cele 4 fire sunt (vezi figura 14.1):
SCLK — Serial Clock (semnal de tact provenit de la dispozitivul principal - master)
MOSI/SIMO — Master Output, Slave Input (ieşire de date, semnal generat de
dispozitivul master)
MISO/SOMI — Master Input, Slave Output (intrare de date, semnal generat de
dispozitivul slave)
SS — Slave Select (semnal de ieşire a master-ului utilizat pentru selecţia
dispozitivului slave – de obicei activ pe 0 logic)
Fig 14.1: Semnalele SPI
210
14.2 Transferul datelor
Transferului datelor este întotdeauna iniţiat şi controlat de dispozitivul primcipal
(master). Pentru a porni comunicatia masterul trebuie sa aibă setat generatorul de tact la o
frecvenţă cel mult egala cu frecvenţa suportată de slave.
Masterul selecteaza apoi dispozitivul slave dorit (cel mai adesea acest lucru
realizându-se prin punerea pe 0 logic a liniei se semnal SS corespunzătoare acestuia).
In timpul unui ciclu SPI, transmisia este full-duplex:
masterul trimite un bit pe linia MOSI, iar slave-ul il citeste de pe aceeasi linie;
slave-ul trimite un bit pe linia MISO, iar master-ul il citeste de pe aceeasi linie;
Comunicatia pe SPI implica de obicei existenta a doi registri de shiftare (Shift Registers),
unul fiind inclus în dispozivitul master iar altul făcând parte din dispozitivul slave.
Realizând conexiunile dintre cele două dispositive aşa cum s-a prezentat anterior, aceştia
vor deveni conectaţi aşa cum rezultă din următoarea figură:
Fig 14.2: Transferul datelor prin deplasarea biţilor
De obicei primul bit shiftat pe liniile de MISO/MOSI este bitul cel mai semnificativ
(MSB – bitul 7), în timp ce un nou bit este adăugat pe poziţia cea mai puţin semnificativă
din registru (pe locul bitului de pe poziţia 0).
Dupa ce întregul cuvânt a fost trimis prin deplasare, masterul şi slave-ul au
interschimbat valorile din cei doi regiştri. Dacă mai există date de transmis, procesul este
reluat.
Când nu mai există date de transmis, masterul întrerupe generarea clock-ului şi, în
general, pune 1 pe linia de SS asociată slave-ului.
Întregul transfer de date se realizează doar pe fronturile semnalului de tact (fie
acestea pozitive – tranziţii din 0 logic în 1 logic, fie negative – tranziţii din 1 logic în 0
logic). Datorită acestui lucru, sunt tolerate situaţiile în care perioada semnalui de tact nu
este constantă pe durata transferului de date, timpul dintre două fronturi succesive nefiind
(în general) contabilizat de nici unul din dispozitivele implicate în transferul de date.
Totodată, transferul de date pe frontul semnalului de tact aduce un mare beneficiu:
limitarea superioară a semnalului de tact (stabilirea fracvenţei sale maxime) se face doar în
funcţie de rapiditatea de prelucrare a semnalului şi de capacitatea fizică de la capetele
211
liniilor de date, aceasta intervenind la deformarea semnalului de tact. De regulă, frecvenţele
maxime impuse de componenta slave sunt cuprinse între 1 Mhz şi 100 MHz.
Atenţie!
Dispozitivele slave care nu au fost selectate ca fiind „ţinta” datelor trimise de master
vor ignora semnalele de pe SCK si MOSI si nu vor genera nici un fel de semnal pe linia
MISO.
Observaţie!
În figura de mai sus sunt prezentaţi regiştri având o lungime a cuvântului de 8 biţi,
însă această lungime nu este standard. Pot exista situaţii în care, datorită reprezentării
cuvintelor într-un sistem de calcul, protocolul SPI să fie implementat cu 16 sau 32 biţi sau
chiar situaţii în care numărul de biţi să fie stabilit din alte considerente şi sa nu fie o putere
a lui 2.
14.3 Modurile semnalului de tact
Pe lângă setarea privind frecvenţa de funcţionare a comunicaţiei, dispozitivul
mnaster trebuie sa cunoască şi particularităţile privind modul de scriere şi citire sincronă a
informaţiilor pe magistrala SPI. Aceste informaţii suplimentare se referă la polaritatea şi
faza semnalului de tact cu referinţă la modul (sau mai exact momentul) în care sunt
prezente informaţiile pe liniile de date. Aceste două caracteristici au devenit cumva
standardizate şi se regasesc în descrierile producatorilor având urmatoarele denumiri:
CPOL – polaritatea semnaluui de tact
CPHA – faza semnalului de tact
Din combinaţii ale acestor doi parametri, vor rezulta următoarele moduri de lucru a
semnalului de tact:
Mod CPOL CPHA
0 0 0
1 0 1
2 1 0
3 1 1
În figura următoare (14.3) se pot observa diferenţele dintre modurile de lucru ale
semnalului de tact pentru a putea citi sau scrie date pe magistrala SPI. Utilizând linii
verticale albatre şi roşii s-au marcat fronturile pozitive şi negative ale semnalului de tact.
Sincron cu aceste fronturi se pot observat pentru diferite moduri ale tactului fie citirea sau
scrierea de date valide, fie operaţiunea de deplasare a biţilor de la un dispozitiv la altul.
212
ciclu
ciclu
Fig 14.3: Modurile de lucru ale semnalului de tact
Pentru o mai bună înţelegere a acestor concepte, cele patru moduri vor fi descrise
explicit în ceea ce urmează:
La CPOL = 0 valoarile de start şi stop ale semnalului de tact precum şi valoarea de
stand-by sunt zero, totodată funcţionarea se va realiza în următoarul mod:
o Pentru CPHA = 0 data este considerată validă pe tranziţia pozitivă a
semnalului de tact (0 logic → 1 logic) şi este deplasată (propagată) pe
tranziţia negativă a ceasului (1 logic → 0 logic).
o Pentru CPHA = 1 data este considerată validă pe tranziţia negativă a
semnalului de tact (1 logic → 0 logic) şi este deplasată (propagată) pe
tranziţia pozitivă a ceasului (0logic → 1 logic).
La CPOL = 1 valoarile de start şi stop ale semnalului de tact precum şi valoarea de
stand-by sunt unu logic, totodată funcţionarea se va realiza în următoarul mod:
o Pentru CPHA = 1 data este considerată validă pe tranziţia negativă a
semnalului de tact (1 logic → 0 logic) şi este deplasată (propagată) pe
tranziţia pozitivă a ceasului (0logic → 1 logic).
o Pentru CPHA = 0 data este considerată validă pe tranziţia pozitivă a
semnalului de tact (0 logic → 1 logic) şi este deplasată (propagată) pe
tranziţia negativă a ceasului (1 logic → 0 logic).
213
Se poate observa că informaţia oferită de CPOL poate să inverseze semnificaţia
fronturilor pozitive cu ale celor negative. Mai mult, CPOL permite setarea nivelului logic
staţionar dinainte, respectiv de după efectuarea operaţiilor cu date.
De regulă semnalele MOSI şi MISO sunt stabile cel puţin pe o jumătate de perioadă
a semnalului de tact. Acest lucru va putea permite unor dispozitive să eşantioneze valoarea
semnalului chiar atât sincron cu tactul cât şi în diverse momente pe o semiperioadă a
tactului, până la următoarea propagare (deplasare). Acest lucru aduce un plus de
flexibilitate comunicaţiei dintre master şi slave.
Atenţie!
În momentul conectării de dispozitive care vor trebui să comunice utilizând
protocolul SPI, trebuie cunosctut de la început şi setat ca atare dispozitivul master. De
asemenea vor trebui cunoscute cerinţele dispozitivului slave referitoare la modul/modurile
acceptate ale tactului şi la frecvenţa maximă de funcţionare.
14.4 Adresarea dispozitivelor slave
Aşa cum am văzut anterior, pentru ca un dispozitiv master să poată transfera date
către sau de la unul slave este nevoie ca cel din urmă să fie selectat, acest lucru realizându-
se într-un mod simplu, hardware. Aşadar, nu putem vorbi de o adresare logică, utilizând
secvenţe de date vehiculate prin SPI, prin adresare înţelegând in cazul acestui protocol
simpla selecţie.
Cu toate acestea, s-au conceput diverse metode de a facilita adresarea către mai
multe dispozitive SPI. Mai jus sunt prezentate două dintre cele mai folosite metode de a
realiza adresarea (selectarea) specifică protocolului SPI.
14.4.1 Adresarea independentă
După cum sugerează denumirea acestui tip de adresare, pentru fiecare dispozitiv
care trebuie selectat va exista o linie de Slave Select unică (independentă). Acesta este
modul standard de folosire a protocolului atunci când se utilizează o configurţie multi-
slave. Folosirea acestui tip de adresare va presupune, datorită faptului că toate semnalele de
tip MISO sunt conectate împrenuă, ca această linie să fie tri-state în cazul dispozitivelor
neselectate.
După cum se poate obseerva în figura următoare, această metodă are dezavantajul
existenţei unui număr mare de ieşiri de selecţie, atâtea ieşiri câte slave-uri sunt.
Însă, principalul avantaj al adresării directe este faptul că master-ul comunică direct
cu fiecare dispozitiv slave în parte, beneficiind astfel de întreaga viteză disponibiă pentru
transferul de date.
214
Fig 14.4: Adresarea independentă
14.4.2 Adresarea înlănţuită
Unele dispozitive echipate cu protocolul SPI sunt realizate pentru a suporta un mod
de adresare înlănţuit, care presupune ca ieşirea primului dispozitiv slave să devină intrare
pentru cel de-al doilea dispozitiv şi aşa mai departe. Portul SPI al acestor dispozitive slave
este conceput astfel încât, pe durata selecţiei slave-ului respectiv, acesta primind un număr
de impulsuri de tact mai mare decât cel necesar, să deplaseze informaţia de la intrarea lor
(MOSI) către ieşirea lor (MISO), fără a fi prelucrată (modificată). Tot acest lanţ se
comportă asemeni unui registru de deplasare extins de n ori, unde n reprezintă numărul de
dispozitive slave inlănţuite.
Pentru acest tip de adresare este nevoie doar de o singură linie de selecţie pentru
toate slave-urile existente însă dezavantajele metodei de selecţie sunt cele care fac acest tip
de adresare rar utilizat:
Timpul de propagare al unui mesaj de la master la ultimul slave din lanţ creşte
proporţional cu numărul de slave-uri, îngreunându-se astfel transferul datelor;
De asemenea, pentru a citi mesajele emise de primul dispozitiv slave, vor trebui să
fie citite şi eventual prelucrate, mesajele celorlalte dispositive aflate mai aproape de
master, viteza de lucru fiind iarăşi afectată.
215
Fig 14.5: Adresarea înlănţuită
14. 5 Comparaţie între protocoalele I2C şi SPI
Ambele standarde sunt folosite cu succes pentru comunicaţia cu periferice cu viteză
de lucru relativ mică ce sunt accesate intermitent (EEPROM-urile, diferiţi senzori, ceasuri
de timp real, etc.). Totusi, SPI se mulează mai bine decât I2C pe aplicaţiile care folosesc
fluxuri (mari) de date (spre deosebire de aplicaţiile unde se citesc/scriu diverse locaţii din
slave).
Un exemplu de aplicaţie care foloseşte fluxuri mari de date este comunicaţia dintre
două micropocesoare sau DSP-uri (digital signal processors). SPI poate atinge rate de
transfer semnificativ mai mari decât I2C – interfeţele SPI putând funcţiona la sute de MHz.
SPI este eficient mai ales în aplicaţii care îi folosesc capacitatea de a realiza conexiuni full
duplex, ca de exemplu comunicarea dintre un "codec" (coder-decoder) şi un DSP, ce
presupune trimiterea de eşantioane în ambele direcţii.
Datorită faptului că nu există suport logic pentru adresarea dispozitivelor slave, SPI
necesită mai mult efort şi mai multe resurse hardware decât I2C, atunci când avem mai
multe slave-uri. Pe de altă parte, SPI este mai simplu şi mai eficient în aplicaţii point-to-
point (comunicarea dintre master şi un singur slave) din aceleaşi motive: lipsa adresării
device-urilor presupune mai puţină încărcare a mesajelor trimise pe magistrală, din
conţinutul lor lipsind adresa slave-ului.
Rezumând, pot fi identificate următoarele avantaje ale protocolului SPI:
Comunicaţie full-duplex;
Cantitate de informaţie pe unitatea de timp este semnificativ mai mare;
Flexibilitate pentru biţii transferaţi:
o nu există limitarea la cuvinte de 8-biți;
o se pot trimite mesaje de orice lungime;
216
Se interfaţează uşor, uşurinţă în folosire;
Mai eficient în comunicarea point-to-point;
Dispozitivele slave nu au nevoie de adrese logice unice (cum se întâmpla la I²C);
În cadrul configuraţiei multi-slave, liniile de date şide tact sunt folosite la comun;
Nu există o limitare introdusă de specificaţiile protocolului privind frecvenţa
maximă a semnalului de tact, acest lucru venind în sprijinul aplicaţiilor de mare
viteză.
Protocolul prezintă însă şi următoarele dezavantaje:
Nu are suport pentru adresarea dispozitivelor; este necesar cate un semnal de Slave
Select pentru fiecare slave
Foloseşte mai multe fire, numărul linilor de adresare (selecţie) trebuie mărit
corespunzător cu numărul de slave-uri;
Nu există controlul datelor (flow control) şi răspunsul venit de la slave (slave
acknowledgement), astfel dispozitivul master poate "vorbi în gol" fără să realizeze;
Suportă numai un singur master;
Nu există un protocol de identificare a erorilor de transmisie;
Există multe variaţii ale protocolului, acest lucru făcând dificilă realizarea de
dispositive gazdă generice care să suporte toate aceste variaţii.
Astǎzi, la extremitatea inferioarǎ a protocoalelor de comunicaţie, gǎsim I²C (protocol
pentru Circuite Inter-Integrate) şi SPI (pentru Interfaţǎ Serialǎ Perifericǎ). Ambele
protocoale sunt indicate pentru comunicaţii între circuite integrate, pentru transmisii lente
cu periferice pe placa de bazǎ. La baza acestor douǎ protocoale foarte cunoscute se aflǎ
numele a douǎ companii – Philips pentru I²C şi Motorola pentru SPI – şi douǎ istorii
diferite despre cum, când şi de ce au fost create aceste protocoale.
Protocolul I²C a fost dezvoltat în anul 1982; scopul sǎu principal era sǎ asigure o
modalitate uşoarǎ pentru conectarea unui CPU cu chip-urile periferice într-un ansamblu
TV. Dispozitivele periferice din sistemele embedded sunt adesea conectate la
microcontroller ca dispozitive I/O de memorie mapate. O modalitate uşoarǎ pentru a realize
acest lucru este conectarea perifericelor la adresele paralele ale microcontrollerului şi
magistralele de date. Aceasta înseamnǎ însǎ o mulţime de legǎturi pe PCB (printed circuit
board) şi o logicǎ adiţionalǎ pentru decodarea magistralei de adrese pe care sunt conectate
toate perifericele. În scopul economisirii pinilor de la microcontroller, logicii adiţionale şi
pentru a face PCB-urile mai simple – cu alte cuvinte, pentru a reduce costurile –
laboratoarele Philips din Eindhoven (Olanda) au inventat Circuitul Inter-Integrat, IIC sau
protocolul I²C care recunoaşte doar douǎ fire pentru conectarea tuturor perifericelor la un
microcontroller. Specificaţia originalǎ a definit o vitezǎ a magistralei de 100 kbps (kilo biţi
pe secundǎ). Specificaţia a fost ulterior revizuitǎ de câteva ori, introducând vitezele de 400
kbps în 1995 şi – din 1998, vitezza de 3.4 Mbps pentru perifericele şi mai rapide.
Protocolul Serial Periferic (SPI) a fost introdus mai întâi cu primul microcontroller
derivând din aceeaşi arhitecturǎ ca şi microprocesorul Motorola 68000, în 1979. SPI a
definit magistrala externǎ a microcontroller-ului, folosit pentru conectarea perifericelor cu 4
fire la microcontroller. Spre deosebire de I²C, este greu de gǎsit o specificaţie formalǎ a
magistralei SPI – pentru o descriere detaliatǎ, trebuie citite datele de catalog ale
microcontroller-elor şi notele aplicaţiilor asociate.
217
SPI este chiar mai puternic – el defineşte trǎsǎturi la care s-ar gândi orice inginer
electronist dacă ar trebui sǎ defineascǎ rapid un mod de comunicare între douǎ dispozitive
digitale. SPI este un protocol pe 4 linii (figura 14.6):
- un semnal de clock numit SCLK, trimis de la masterul magistralei la toate
slaver-urile; toate semnalele SPI sunt sincrone cu acest semnal de clock;
- un semnal de selecţie a slave-ului pentru fiecare dispozitiv slave, SSn, folosit
pentru a selecta slave-ul cu care comunicǎ master-ul;
- o linie de date de la master la slave-uri, denumitǎ MOSI (Master Out-Slave In);
- o linie de date de la slave-uri cǎtre master, denumitǎ MISO (Master In-Slave
Out).
SPI este un protocol de comunicaţie cu un singur master. Aceasta înseamnǎ că un
dispozitiv central iniţiază toate comunicaţîile cu dispozitivele slave.
Atunci când masterul SPI doreşte să trimită date unui dispozitiv slave şi / sau cere
informaţii de la acesta, el selectează dispozitivul slave trăgând jos (LOW) linia SS
corespunzătoare şi activând frecvenţa de clock utilizată de master şi slave. Dispozitivul
Fig. 14.6 Două topologii de magistrale SPI. Figura de sus indică o magistrală SPI
conectată la un singur dispozitiv slave (topologia punct – la – punct). Figura de
jos indică o magistrală SPI conectată la mai multe circuite slave.
218
master generează informaţii pe linia MOSI în timp ce eşantionează această linie (figura
14.7).
Pentru modurile de comunicaţie se folosesc (MODE 0, 1, 2, 3) – care, de fapt,
definesc frontul SCLK pe care comută linia MOSI, frontul SCLK pe care masterul
eşantionează linia MISO şi nivelul stabil al semnalului SCLK (care reprezintă nivelul de
clock, High sau LOW, atunci cănd clock-ul nu este activ)).
Fiecare mod este definit formal cu ajutorul unei perechi de parametri numiţi
polaritate de clock (CPOL) şi fază de clock (CPHA), figura 14.8.
O pereche master / slave trebuie să folosească acelaşi set de parametric – frecvenţa
SCLK, CPOL şi CPHA pentriu a face posibilă comunicaţia. Dacă sunt folosite mai multe
slave-uri şi acestea sunt fixate în configuraţii diferite, masterul va trebui să reconfigureze
singur fiecare timp de care are nevoie pentru comunicaţia cu fiecare slave în parte.
Aceasta reprezintă, de fapt, tot ceea ce reprezintă protocolul SPI. SPI nu defineşte o
viteză maximă de date, nici o schemă particulară de adresare; protocolul nu are un
mecanism de confirmare a recepţionării datelor şi nu oferă nici un control al fluxului de
date. Masterul SPI nu are cunoştinţă despre locul în care există un slave decât dacă “ceva”
adiţional se întâmplă în afara protocolului SPI. De exemplu, un simplu codec nu va avea
nevoie de mai mult decât un SPI, în timp ce un răspuns – comandă control va avea nevoie
de un protocol de nivel mai înalt, construit la vârful interfeţei SPI. De asemenea, protocolul
SPI nu ţine cont de caracteristicile interfeţei fizice cum ar fi tensiunile de I/O şi standard
folosite între dispozitive.
Fig. 14.7 O comunicatie SPI simplă. Biţii de date pe MOSI şi MISO comută frontul
căzător al SCLK şi sunt eşantionaţi pe frontul crescător al SCLK. Modul SPI defineşte
care front SCLK este folosit pentru transferul de date şi care front este folosit pentru
eşantionarea de date.
219
Iniţial, majoritatea implementărilor cu protocolul SPI folosesc un clock discontinuu
şi o schemă byte-by-byte. În multe variante însă, protocolul existent foloseşte un semnal de
clock continuu şi o lungime de transfer arbitrară.
- Topologie / resurse: I²C necesită 2 linii şi atât, în timp ce SPI formal defineşte cel puţin 4 semnale şi
chiar mai multe, dacă se adaugă slave-uri. Unele variante neoficiale ale protocolului SPI
necesită doar 3 fire, SCLK, SS şi o linie bi-direcţională MISO/MOSI. Încă, această
imlementare va avea nevoie de o linie SS pentru fiecare slave. SPI necesită o muncă
suplimentară, logică şi / sau pini dacă trebuie construită o arhitectură de tip multi-master
bazată pe acest protocol. Singura problemă la protocolul I²C este atunci când vrem să
construim un system; spaţiul de adresare pe 7 biţi poate fi extins la adresarea pe 10 biţi.
Din acest punct de vedere, I²C este mai bun decât SPI în ceea ce priveşte numărul de
pini, placa de bază şi uşurinţa implementării unei reţele.
- Viteza de transfer: Dacă datele trebuiesc transferate la viteză înaltă (‘high speed’), protocolul SPI este
cel mai indicat, faţa de protocolul I²C. Protocolul SPI este full-duplex; I²C nu este. SPI nu
defineşte nici o limită de viteză; implementările merg adesea peste 10 Mbps. Protocolul I²C
este limitat până la 1Mbps în modul Fast Mode+ şi la 3.4 Mbps în modul High Speed –
acesta din urmă necesită bufere specifice de I/O, care nu sunt întotdeauna disponibile
Fig. 14.8 Modurile SPI sunt definite cu ajutorul parametrilor CPOL – polaritatea
clock-ului, CPHA – faza clock-ului, care în mod explicit dfinesc trei parametric:
fronturile folsite pentru eşantionarea şi comutarea datelor şi nivelul de mers în gol
(idle) al semnalului de clock – care este nivelul SCLK convenţional ce reprezintă
magistrala atunci când aceasta nu face comunicaţii.
220
- Eleganţa: Se spune adeseacă protocolul I²C este mult mai elegant decât protocolul SPI,
deoarece acesta din urmă este mai rudimentar. In present, înclinăm să credem că aceste
două protocoale sunt la fel de elegante şi comparabile ca şi robusteţe.
I²C este elegant deoarece oferă caracteristici foarte avansate – cum ar fi susţinerea
automată a conflictelor multi-master şi managementul adresării. Poate fi foarte complex, în
funcţie de structurile din schemă.
SPI, pe de altă pate, este foarte uşor de înţeles şi de implementat şi oferă un grad
mare de flexibilitate pentru extensii şi variante. Este caracterizat de o mare simplitate. SPI
ar rebui onsiderat o foarte bună platformă pentru construcţia protocoalelor de bază pentru
comunicaţi între circuitele integrate. Deci, în accord cu necesităţile inginerilor, folosirea
protocolului SPI poate avea nevoie de mai multă muncă însă, oferă un transfer de date mult
mai rapid şi o mare libertate de variante.
Ambele protocoale, SPI şi I2C reprezintă un support ideal pentru comunicaţiile între
dispozitivele de viteză scăzută (low-speed devices), însă SPI este mai potrivit pentru
aplicaţii în care dispozitivele transferă fluxuri de date, în timp ce I²C este mai indicat în
aplicaţiile multi-master cu acces la register.
Folosite în mod adecvat, cele două protocoale oferă acelasi nivel de robusteţe şi au
acelaşi success printer furnizori.
EEPROM (Electrically-Erasable Programmable Read-Only Memory), ADC
(Analog-to-Digital Converter), DAC (Digital-to-Analog Converter), RTC (Real-time
clocks), microcontrollere, senzori, LCD (Liquid Crystal Display) sunt disponibile într-o
mare varietate cu I²C, SPI sau cele două interfeţe.
Concluzii
În lumea protocoalelor de comunicaţii, I²C şi SPI sunt considerate adesea “mici”
protocoale de comunicaţii în comparaţie cu Ethernet, USB, SATA, PCI-Express şi altele
care au rate de transfer în zona x100 megabiţi/secundă sau chiar gigabiţi/secundă. Totuşi,
nu trebuie să uităm pentru ce a fost construit fiecare protocol. Ethernet, USB, SATA sunt folosite pentru comunicaţii în afara schemei şi schimburi
de date între sisteme întregi. Atunci când este necesară implementarea unei comunicaţii
între circuite integrate cum sunt microcontrollerele şi un set de pefiferice relativ lente, nu
are sens să folosim protocoale foarte complexe. De aceea, I²C şi SPI se potrivesc perfect in
aceste aplicaţii.
221
BIBLIOGRAFIE
[1] G.J. Holzmann, ''Design and Validation of Computer Protocols'', Chapter on Protocol
Validation, Prentice Hall, London, U.K., 1991, pp. 217-244.
[2] P. Godefroid, ''Partial-Order Methods for the Verification of Concurrent Systems''; Vol.
1032 of LNCS, Springer Verlag, 1996.
[3] D. Paret, “The I2C-bus from theory to practice”, Publisher: Wiley, ISBN: 0-471-96268-
6
[4] *** “80C51 microcontroller selection guide”
[5] *** “User manual of Microsoft Pascal I2C-bus driver”
[6] *** “User's guide to I2C-bus control programs”
[7] *** “The I2C-Bus Specification – Vrsion 2.1”, Philips Semiconductors, January, 2000.
[8] *** BOSCH ''CAN Specification - Version 2.0'', Robert Bosch GmbH, 1991, Stuttgart.
[9] U. Adler (Editor-in-Chief), ''BOSCH Automotive Handbook'', Robert Bosch GmbH,
1993, Stuttgart.
[10] M. Schofield, ''Controller Area Network - How CAN Works''; www.mjschofield.com
[11] *** ''Stand - Alone CAN-Controller PCA82C200''; Philips Semiconductors
Microcontroller Products, pp. 914-953.
[12] M. Schofield, ''Control Area Network and NMEA''; www.mjschofield.com
[13] Ey. Horst, ''Controller Area Network''; Philips Components, Electronic Components
and Applications, 1990, Vol. 9, no. 3, pp. 155-160.
[14] M. Schofield, ''Control Area Network - Background Information'';
www.mjschofield.com
[15] M. Schofield, ''Control Area Network - Available Devices''; www.mjschofield.com
[16] M. Schofield, ''Control Area Network - CAN Application Layers'';
www.mjschofield.com
[17] M. Schofield, ''Control Area Network - Error Handling''; www.mjschofield.com
[18] M. Schofield, ''CAN time - Bit- Timing Calculation''; www.mjschofield.com
[19] M. Schofield, ''Control Area Network - Bit Timing and Syncronisation'';
www.mjschofield.com
[20] M. Schofield, ''Control Area Network - Implementation''; www.mjschofield.com
[21] D. Ferrari, ''Client Requirements for Real Time Communications Services''; Technical
Report TR-90-007, International Computer Science Institute, Berkeley, March, 1990.
[22] R.K. Jurgen, "Automotive Electronics Handbook"; McGraw-Hill, Inc, New York,
1995.
[23] *** ''Inter Controller Area Network for In-Vehicle Aplications''; SAEJ1583.
[24] *** ''Chrysler Collision Detection''; SAEJ1567.
[25] *** ''Class B Data Communications Network Interface''; SAEJ1850.
[26] *** ''Chrysler Sensor and Control''; SAEJ2058.
[27] *** ''Token Not Slot Network for Automotive Control''; SAEJ2106.
[28] H. Kopetz, G. Grunsteidl, ''A Time Triggered Protocol for Automotive Applications'';
Research Report No. 16/1992, Institute for Technical Information, University Wiencan -
Austria, October, 1992.
[29] L. Vornicu, L. Dimitriu, ''A Method for Reducing Latency in Serial Transmission
Systems'', Buletinul Institutului Politehnic din Iaşi, Secţia III - Electrotehnică, Energetică,
Electronică, 1999.
222
[30] *** ''Vehicle Area Network: VAN Specification, Version 1.2''; ISO/TC22/SC3/WG1.
[31] U. Adler, Editor in Chief, "Automotive Handbook", Robert Bosch GmbH, Stuttgart,
1993.
[32] *** "Philips' Fault-Tolerant CAN Transceivers Set the Standard", Philips
Semiconductors World News, Vol. 6, no. 5, November/December , 1997, p. 5.
[33] *** "Glossary of Vehicle Networks Multiplexing and Data Communication",
SAE J1213 Part1
[34] *** "Architecture Strategies", SAE J2057 Part 4
[35] *** "Network Access Methods", SAE J2056 Part 4
[36] *** "Media Choices", SAE J2056 Part 3
[37] Fred Miesterffeld, Rick Halter, "Survey of Encoding Techniques for Vehicle
Multiplexing", SAE 910715.
[38] *** "Detailed Header Formats and Physical Address Assignments", SAE J2178
Part : "Network Architectures and Header Selection", Apendix A
[39] Multiplexed Networks for Embedded Systems CAN, LIN, FlexRay, Safe-by-Wire...,
Dominique Paret, Ed. Wiley, 2007 John Wiley & Sons, Ltd.
[40] Le Bus CAN - Applications - Dominique Paret, Dunod.
[41] CAN - W. Lautenz, John Wiley & Sons.
[42] CAN - Controller Area Network - Grundlagen, Protocolle, Bausteine, Anwendungen -
K. Etschberger, Editeur Hanser.
[43] CAN - Grundlagen und Praxis - W. Laurenz, Editeur Huthig.