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.