Curs Sist Aut Fabricatie

8/16/2019 Curs Sist Aut Fabricatie

1/125

SISTEME AUTOMATE

DE FABRICAŢIE

- curs master -


2/125

Capitolul 1. 1

CAPITOLUL 1.

STRUCTURI TIPICE DE AUTOMATIZARE

A FABRICAŢIEI UTILIZATE ÎN CADRUL

SISTEMELOR CIM

1.1. Noţiuni introductive

Prin fabrica ţ ie se înţelege totalitatea activităţilor – umane sau automate

– care concur ă la realizarea unui produs de o anumită concepţie şi o anumită

destinaţie dată, pornindu-se de la starea de semifabricat şi până la starea de

produs finit. În acest context, prin automatizarea fabrica ţ iei se înţelege “au-

tomatizarea” activităţilor enunţate mai sus. Ca rezultat al automatizării,

aceste activităţi vor putea fi efectuate în mod automat, adică f ăr ă intervenţia

operatorului uman. O fabrica ţ ie complet automatizat ă este caracterizată

prin efectuarea în mod automat, a tuturor activităţilor legate de realizarea

produsului.

Structura de bază a fabricaţiei automatizate este celula de fabrica ţ ie. O

celulă de fabricaţie este destinată în general pentru fabricarea în mod auto-

mat a unor piese care fac parte dintr-o familie tipodimensională. Astfel ele

se constituie pe grupuri de operaţii tehnologice cum sunt: prelucr ări prin aş-

chiere piese prismatice, prelucr ări prin aşchiere piese de revoluţie, deformări

plastice, tratamente termice, montaj, vopsire, sudur ă etc.


3/125

Capitolul 1. 2

O celul ă de fabricaţ ie automatizat ă conţine unu sau mai multe

mijloace de producţie automatizate (de exemplu maşini unelte cu

comandă numerică), depozite tampon pentru semifabricate şi piese

finite respectiv unu sau mai multe sisteme de transfer automat al pie-

selor între depozite şi mijloace de producţie, fig.1.1. Aceste sisteme

de transfer automat a pieselor pot fi realizate prin intermediul unor

“instalaţii aducătoare/ de evacuare” (IA/E) - în cazul mişcărilor simple

de transfer şi poziţionare – şi/sau prin intermediul roboţilor industriali

(în cazul în care sunt necesare mişcări complexe de manipulare).

Toate activităţile de fabricaţie din cadrul unei celule sunt sub coordonareaautomată a unui “calculator central ”. Această coordonare automată necesită

existenţa unor legături informaţionale între echipamentele de comandă din

cadrul celulei şi calculatorul central.

Fig.1.1. Componentele principale ale unei celule de fabricaţie


4/125

Capitolul 1. 3

Integrarea cu “calculatorul” într-o întreprindere atât a activităţilor

de fabricaţie, cât şi a activităţilor legate:

• de concepţia (proiectarea) constructivă şi tehnologică a produse-

lor,

• de planificarea, programarea şi urmărirea producţiei,

• de logistică, financiar ă, aprovizionare şi de desfacere,

• respectiv de conducere (management) a întreprinderii

este cunoscută sub numele de CIM (Computer Integrated Manufacturing).

Astfel termenul CIM se refer ă la integrarea “informaţională” a activităţilor

de producţie iar fabricaţia este de fapt doar una dintre activităţile producţiei.

Observa ţ ii:

1. Conform celor de mai sus, mai potrivită ar putea fi denumirea “Compu-

ter Integrated Production” - Producţie Integrată cu Calculatorul (CIP).

2. Termenul de Hipersistem CIM , este utilizat în general pentru indicarea

integr ării informaţionale a “subsistemelor” de producţie, într-un sistem

complex şi unitar.

1.2. Structura de comandă DNC a maşinilor unelte

Acest tip de structur ă este utilizată pentru Comanda Numerică Directă

(Direct Numerical Control – DNC) a maşinilor-unelte din cadrul unei celule

de fabricaţie. În esenţă, această structur ă de comandă, numită şi structur ă

DNC , ofer ă posibilitatea introducerii programelor de prelucrare, în memoria

echipamentelor de comandă numerică a maşinilor respective în mod “di-


5/125

Capitolul 1. 4

rect”, de pe un calculator central (pe care sunt stocate), în locul introducerii

manuale sau de pe bandă perforată de către operatorul uman.

Între calculatorul central (denumit şi calculator DNC ) şi echipamentelede comandă numerică din cadrul celulei există o legătur ă informaţională bi-

direcţională (de obicei legătur ă serială RS232c). Astfel calculatorul DNC,

pe lângă transferul către echipamentele de comandă numerică a programelor

de piesă (respectiv a unor date, cum sunt corecţii de scule), are acces la date

(informaţii) referitoare la starea de funcţionare a maşinilor şi în consecinţă

poate iniţia comenzi pentru efectuarea anumitor operaţii.

Fig.1.2. Exemplu de structur ă de comandă de tip DNC

În fig.1.2. s-a prezentat un exemplu de conectare informaţională a echi-

pamentelor de comandă numerică, într-o structur ă de comandă de tip DNC,

aşa cum există la firma REMEX Corp., SUA. Pe baza figurii, legătura in-


6/125

Capitolul 1. 5

formaţională între calculatorul DNC şi echipamentul de comandă numerică

NC (Numerical Control) este realizată prin intermediul unor Interfe ţ e de

Maşină (MIU – Machine Interface Unit).

Fig.1.3. Modelul de interconectare a echipamentelor de

comandă numerică într-o structur ă de tip DNC

În unele cazuri aceste “interfeţe de comunicaţie” sunt instalate în in-

teriorul echipamentelor, caz în care au denumirea de “interfa ţă DNC ”. În al-

te cazuri aceste interfeţe sunt sisteme cu memorii proprii, cu ecran (display)


7/125

Capitolul 1. 6

şi panou operator pentru recepţionarea, stocarea şi transmiterea mai departe

a programelor de prelucrare (fig.1.2.) În acest ultim caz, programul poate fi

transmis către interfaţa MIU a echipamentului NC chiar în timpul execuţiei programului curent de prelucrare. Programul transmis este stocat în memo-

ria interfeţei MIU până la terminarea execuţiei programului curent, respectiv

până la încărcarea în memoria internă a echipamentului NC.

Trebuie menţionat faptul că interfeţele MIU nu sunt necesare în cazul

echipamentelor de comandă numerică de “tip nou”: CNC (Computer Nume-

rical Control) care de regulă au deja încorporate interfe ţ e DNC .

Observa ţ ie:• Diferenţa esenţială între un echipament de comandă numerică de tip NC

(Numerical Control) şi unul de tip CNC (Computer Numerical Control),

este faptul că până când la primul funcţiile de comandă sunt implemen-

tate exclusiv prin mijloace hardware, la echipamente CNC ele sunt im-

plementate prin mijloace software, adică au la bază un calculator nume-

ric (Computer), format dintr-un sistem cu microprocesoare.

Modul tipic de interconectare a echipamentelor de comandă numerică

(NC, CNC), în cazul unei structuri de tip DNC, este prezentat în fig.1.3. Se

poate observa că în general lipsesc legăturile informaţionale cu alte structuri

funcţionale (proiectare, urmărirea producţiei) din cadrul întreprinderii. Ast-

fel r ămân modalităţile tradiţionale de încărcare pe calculator a unor progra-

me de prelucrare: de pe bandă perforată (prin utilizarea unui cititor de ban-

dă) sau de pe unităţi de stocare magnetică a datelor (disk floppy). De ase-

menea, deservirea calculatorului DNC (introducere date şi programare) se

realizează prin mijloace manuale.


8/125

Capitolul 1. 7

1.3. Structuri tipice de automatizare a fabricaţiei la nivelul celulelor

de fabricaţie

Pentru realizarea coordonării tuturor activităţilor de fabricaţie la nivelul

unei celule este necesar ă conectarea la un calculator central, nu numai a

echipamentelor de comandă numerică (NC şi/sau CNC), dar şi a echipamen-

telor de comandă robot (ROC – Robot Controller) respectiv a automatelor

programabile (PLC - Programable Logic Controller). Acesta din urmă este

utilizat în general pentru supravegherea proceselor discrete, legate de fluxulde piese din cadrul celulei, respectiv a instalaţiilor IA/E. Calculatorul cen-

tral, având func ţ ia de coordonare a tuturor echipamentelor de comandă

(NC, CNC, ROC, PLC) din cadrul celulei, este numit Controler de Celul ă

(CC- Cell Controller). În funcţie de modul de conectare informaţională a

echipamentelor de comandă la controlerul de celulă, distingem mai multe

variante pentru structura de comandă a unei celule de fabricaţie:

1. Structur ă de comandă cu conectare direct ă la controlerul de celul ă,

2. Structur ă de comandă cu interconectare printr-o reţea locală LAN.

1.3.1. Structură de comandă cu conectare directă la controlerul de

celulă

Această structur ă de comandă derivă din structura de tip DNC, în care

fiecare echipament NC şi/sau CNC este conectat separat la un calculator

central prin intermediul unor legături seriale RS232c, aşa cum a fost prezen-

tat în fig.1.3.


9/125

Capitolul 1. 8

În plus faţă de structura DNC se conectează la acest calculator central,

numit în continuare controler de celul ă, şi celelalte echipamente de coman-

dă (ROC, PLC) din cadrul celulei de fabricaţie, tot prin leg ături seriale dardistincte, fig.1.4.

Controlerul de celulă îndeplineşte func ţ ia de comand ă /coordonare a

activităţilor de fabricaţie din cadrul celulei, prin:

• Încărcarea echipamentelor de comandă (NC, CNC, PLC, ROC)

cu programe şi cu date, aferente procesului curent de fabricaţie;

• Iniţierea unor comenzi pentru intrarea în funcţiune/oprirea maşi-

nilor de lucru, a dispozitivelor instalaţiei aducătoare/de evacuare,a roboţilor respectiv a modulelor de fabricaţie flexibilă;

• Monitorizarea stărilor de funcţionare ale fiecărui echipament de

fabricaţie;

• Gestionarea fluxului de materiale din cadrul celulei flexibile de

fabricaţie.

Analizând fig.1.4. poate fi observat uşor caracterul ierarhic al acestei

structuri: controlerul de celulă este pe post de “calculator central” (numit şi“master”) iar echipamentele de comandă conectate la el sunt pe post de

“slave” (subordonat). Aceasta înseamnă că deşi în general echipamentele de

comandă pot deţine iniţiativa comunicaţiei, în situaţii de concurenţă contro-

lerul de celulă are prioritate.

Dezavantajele acestei structuri de comandă sunt legate de caracterul

centralizat al comunicaţiilor. Nici un echipament nu poate să comunice cu

altul, numai prin intermediul controlerului de celulă.


10/125

Capitolul 1. 9

Acesta din urmă însă trebuie să coordoneze singur toate activităţile de fabri-

caţie din cadrul celulei, cea ce este o sarcină extrem de mare. Datorită vite-

zelor (relativ) mici de transfer, utilizate la transmisia serială RS232c, coor-donarea în timp real a activităţilor de fabricaţie, de multe ori este imposibilă.

Fig.1.4. Modelul de conectare directă la controlerul de celulă a echipa-

mentelor de comandă din cadrul unei celule de fabricaţie


11/125

Capitolul 1. 10

Comanda celulei este îngreunată de foarte multe ori şi de faptul că fieca-

re tip de echipament (NC, CNC, ROC, PLC) utilizează în general limbaje

diferite de comandă.1.3.2. Structură de comandă cu interconectare printr-o reţea LAN

Fig.1.5. Modelul conectării la Reţeaua de Celulă prin

intermediul unor “calculatoare de interfaţă”


12/125

Capitolul 1. 11

În această variantă atât controlerul de celulă cât şi fiecare echipament de

comandă din cadrul celulei este conectat la o reţea locală LAN (Local Area

Network). Având în vedere că aceasta din urmă se află în cadrul unei celulede fabricaţie, este numită Re ţ ea Local ă de Celul ă (Cell Local Area

Network) sau simplu Re ţ ea de Celul ă (Cell Network).

Pentru conectarea controlerului de celulă respectiv a echipamentelor de

comandă la Reţeaua de Celulă, ele trebuie să fie dotate cu aşa numite in-

terfe ţ e LAN .

Fig.1.6. Modelul conectării “directe”, la Reţeaua de Celulă (f ăr ă calculatoare de interfaţă)


13/125

Capitolul 1. 12

Observa ţ ie:

• O interfaţă LAN are ca funcţie principală, codificarea informaţiilor

transmise prin mediul fizic al reţelei LAN, respectiv decodificareainformaţiilor recepţionate.

Dacă din motive constructive, echipamentele de comandă dintr-o celulă

nu pot fi dotate cu interfeţe LAN, atunci ele trebuie să fie conectate (serial)

la aşa numite “calculatoare de interfa ţă cu re ţ eaua” care la rândul lor sunt

dotate cu aceste interfeţe, fig.1.5.

Noile echipamente de comandă (CNC, ROC şi PLC) sunt dotate, în ge-neral încă din fabricaţie, cu interfeţe LAN. Ca urmare, aceste echipamente

pot fi conectate la Reţeaua de Celulă direct, adică f ăr ă acele calculatoare de

interfaţă, fig.1.6. Singura condiţie este ca interfeţele LAN să fie identice sau

compatibile d.p.d.v. hardware şi software.

În cazul în care Controlerul de Celulă este conectat şi la aşa numită Re-

ţ ea Coloană de Fabrică (Factory Backbone Network), atunci există posibi-

litatea integr ării a activităţilor de fabricaţie, nu numai la nivelul unei celule

de fabricaţie, ci şi la nivelul halei industriale.

Observa ţ ii:

• Reţeaua Coloană de Fabrică str ă bate, sub forma unei “coloane ver-

tebrale”, întreaga hală industrială a fabricii, realizând astfel interco-

nectarea informaţională a reţelelor de celulă, fig.1.7., respectiv co-

nectarea lor la Controlerul Principal de Uzină (Host Plant Contro-

ler).


14/125

Capitolul 1. 13

F i g . 1 . 7 .

E x e m p l u d e i n t e r c o n e c t a r e a R e ţ e l e l o r d e C e l u l ă

p r i n R e ţ e a u a C o l o a n ă

d e F a b r i c ă ,

[ 4 8 ]


15/125

Capitolul 1. 14

• Conectarea reţelelor de celulă la reţeaua coloană de fabrică se poate rea-

liza fie direct prin controlerul de celulă, fie prin utilizarea unor echipa-mente speciale de interconectare (Bridge, Router, Gateway etc.).

Fig.1.8. Ilustrarea conectării directe a echipamentelor la reţeaua de celulă

Avantajul utilizării reţelelor locale LAN pentru efectuarea schimburilor

informaţionale derivă din faptul că aceasta ofer ă viteze de comunicaţie mult

mai mari decât interconectarea serială RS232c, respectiv ofer ă posibilitatea

efectuării unor schimburi directe de informaţii (nu neaparat prin intermediul

controlerului de celulă).

Utilizarea unei reţele de celulă, proiectată corespunzător, este condiţia

esenţială pentru realizarea coordonării în timp real a activit ăţ ilor de fabri-

ca ţ ie din cadrul celulei de fabricaţie.


16/125

Capitolul 1. 15Capitolul 1. 15


17/125

Capitolul 1. 16

În fig.1.8. s-a încercat ilustrarea conectării directe a echipamentelor de

comandă la Reţeaua de Celulă de tip LAN.

În fig.1.9. s-a prezentat un exemplu de interconectare a echipamentelorde comandă din cadrul unei celule de fabricaţie. Acesta conţine în plus, pe

lângă echipamente de comandă numerică (CNC), echipamente de comandă

robot (ROC), automate programabile (PLC) şi respectiv controlerul de celu-

lă şi o sta ţ ie de lucru (workstation) formată dintr-un calculator PC. (În

fig.1.9. nu s-a reprezentat legătura cu reţeaua coloană de fabrică.)

Staţia de lucru este utilizată uneori pentru monitorizarea şi respectiv

urmărirea activităţilor de fabricaţie din cadrul celulei, de către un operatoruman. Eventualele intervenţii sunt efectuate în scopul optimizării programu-

lui de fabricaţie. De asemenea, operatorul uman obţine rapid informaţii refe-

ritoare la situaţia producţiei neterminate.

1.4. Structuri tipice de automatizare a fabricaţiei la nivelul compar-

timentelor de execuţie al unui sistem CIM

În fig.1.10. s-a încercat reprezentarea modelului unei întreprinderi, din

domeniul construcţiilor de maşini, care este organizată conform principiilor

sistemului CIM. Pe baza figurii pot fi distinse uşor patru nivele de activitate:

• Nivelul 1. Conducere strategică.

• Nivelul 2. Compartimente funcţionale (servicii).

• Nivelul 3. Compartimente de concepţie.

• Nivelul 4. Compartimente de execuţie.


18/125

Capitolul 1. 17

Activităţile de fabricaţie din cadrul întreprinderii, respectiv mijloacele

de automatizare ale acestora fac parte din nivelul 4., adică din nivelul com-

partimentelor de execu ţ ie. Compartimentele de execuţie care sunt strâns le-gate de automatizarea fabricaţiei sunt următoarele:

• compartimentele de debitare, de fabricaţie respectiv de finisare,

care au în componenţa lor una sau mai multe Celule de Fabrica-

ţ ie Flexibil ă (Flexible Manufacturing Cells - FMC);

• compartimentul de montaj, cu una sau mai multe Celule de

Asamblare Flexibil ă (Flexible Assembling Cell – FAC);

• compartimentul de control şi testare, respectiv Celula de M ăsu-

rare şi Control de Calitate (Measuring and Quality control Cell);

• compartimentul de depozitare cu un Sistem Automat de Depozi-

tare şi Reg ăsire (Automated Storage & Retrieval System –

AS&RS);

• transportul uzinal, format dintr-un Sistem de Vehicule Ghidate

Automat (Automated Guided Vehicle System - AGVS).

Celulele de Fabrica ţ ie Flexibil ă (Flexible Manufacturing Cells –

FMC), sunt destinate operaţiilor tehnologice de debitare, fabricaţie şi

respectiv finisare a semifabricatelor. Ele fac parte din compartimentele de

debitare, fabricaţie respectiv de finisare. În cadrul acestor celule, modulele

componente sunt organizate în jurul unor maşini de lucru, care sunt

prevăzute cu sisteme de transfer automat a pieselor sau sunt servite de roboţi

industriali.


19/125

Capitolul 1. 18

F i g . 1 . 1

0 .

M o d e l u l u n e i î n t r e p r i n d e r i o r g a n i z a t p e b a z a p r i n c i p i i l o r s i s t e m u l u i C I M


20/125

Capitolul 1. 19

Structurile tipice de automatizare legate de comanda celulei au fost

prezentate în paragraful 1.3. Astfel comanda celulei (adică coordonarea ope-

raţiilor de fabricaţie din cadrul celulei), se realizează prin intermediul unuicontroler de celul ă, la care se conectează direct sau prin intermediul unei

reţele locale LAN celelalte echipamente de comandă.

Celulele de Asamblare Flexibil ă sunt destinate operaţiilor de montaj

respectiv de asamblare automată a componentelor executate. Organizarea şi

respectiv comanda celulei de asamblare flexibilă este similar ă cu cea a celu-

lei de fabricaţie flexibilă, adică se realizează tot prin intermediul unui con-troler de celulă, însă modulele componente sunt organizate în jurul unor

posturi de asamblare (în locul maşinilor de lucru). Mijlocul de producţie

principal în aceste celule este robotul industrial . Acesta, sau un grup de ro-

boţi sunt utilizaţi pentru efectuarea unor mişcări de manipulare complexe

care au ca rezultat final montajul componentelor produsului finit.

Celulele de M ăsurare şi Control de Calitate sunt destinate operaţiilor

de control şi/sau de testare a componentelor/ansamblurilor executate. În ca-

drul acestor celule, controlul automat este de tip postoperaţie (postcelulă), el

se realizează după efectuarea unei operaţii din cadrul procesului tehnologic.

Pentru controlul automat se utilizează în general robo ţ i de măsurare sau

maşini de măsurare cu comand ă numerică . Aceştia determină în mod au-

tomat de regulă dimensiuni dar pot fi utilizate şi pentru controlul calităţii

suprafeţei obiectului de lucru, incertitudinea de execuţie a unor operaţii de

asamblare (spre exemplu suduri) sau pentru verificarea existenţei/inexisten-

ţei unor defecte de material (spre exemplu fisuri).


21/125

Capitolul 1. 20

Operaţiile de control automat pot fi realizate şi prin intermediul unor

sisteme de vedere artificial ă, utilizând în acest scop camere video (CCD).

Prin intermediul acestora este preluată imaginea obiectului controlat şi com- parată cu imaginea obiectului etalon. Aşezarea obiectelor sub camera video

se realizează tot automat, fie prin intermediul unui sistem de transfer auto-

mat al obiectelor fie prin intermediul unui robot industrial.

Fig.1.11. Componentele principale ale celulelor

de măsurare şi de control de calitate

În cadrul acestor celule pot fi realizate şi operaţii de testare automat ă.

Aceste operaţii presupun efectuarea unor funcţii specifice de către obiectele

de lucru, prelevarea unor date care descriu modul cum se realizează funcţiileîn cauză, compararea acestor date cu cele memorate, corespunzătoare unei


22/125

Capitolul 1. 21

funcţionări corecte şi tragerea de concluzii favorabile/defavorabile cu privire

la calitatea obiectului testat.

Structura sistemului de comand ă este similar ă cu cea a celulei de fa- bricaţie flexibilă, fig.1.11. Însă controlerul de celulă, prin coordonarea ope-

raţiilor de control respectiv de testare automată realizează şi funcţia de Asi-

gurarea Calit ăţ ii Asistat ă de Calculator .

Sistemul Automat de Depozitare şi Reg ăsire (Automated Storage and

Retrieval System – AS&RS) este destinat operaţiilor de:

• depozitare a materiei prime, materialelor, pieselor, subansambluri-

lor, componentelor necesare pentru începerea procesului de fabrica-ţie,

• depozitare intermediar ă între fazele de intrare/operaţii ale

semifabricatelor,

• depozitare final ă .

Fig.1.12. Exemplu de sistem automat de depozitare şi regăsire


23/125

Capitolul 1. 22

Depozitul automat (care poate fi organizat ca depozit cu rafturi înalte,

cu compartimente denumite “cuşete” sau ca depozit cu “casete autoportan-

te”), este servit de robo ţ i de depozit . În “cuşete”, respectiv “casete” sunt depozitate materii prime, materiale, semifabricate, componente, subansam-

bluri, depozitate individual sau aşezate în palete şi containere. Evidenţa

acestora (natura, cantitatea/”cuşetă” sau “casetă”) este memorată de “calcu-

lator” denumit controler AS&RS . Acesta, pe lângă gestiunea depozitului,

mai are şi funcţia de coordonare a roboţilor de depozit prin legături informa-

ţionale cu echipamentele de comandă ale acestora. Structura sistemului de

comand ă poate fi asemănătoare celor prezentate la celule de fabricaţie, însă lipsesc echipamentele NC/CNC, iar locul controlerului de celulă este preluat

de controlerul AS&RS.

Fig.1.13. Elementele componente ale sistemului de vehi-

cule ghidate automat AGVS


24/125

Capitolul 1. 23

Transportul uzinal al obiectelor de lucru între depozit şi celule de

fabricaţie, de asamblare respectiv de măsurare se realizează prin sistemul de

transfer (transport) automat, materializat în majoritatea cazurilor prin Siste-mul de Vehicule Ghidate Automat (Automated Guided Vehicle System –

AGVS). Acesta este format din vehiculele ghidate automat (AGV), calea de

ghidare, staţii de încărcare/descărcare, staţii de încărcare acumulatoare, sis-

tem de comandă.

Vehiculele ghidate automat (robocare) sunt vehicule acţionate electric,

conduse de un calculator îmbarcat, care este în legătur ă informaţională (în

anumite puncte de comunicaţie de pe traseu) cu un calculator central de sis-tem numit Controler AGVS , fig.1.13. Vehiculele sunt prevăzute cu acumu-

lator de energie şi cu dispozitive de încărcare/descărcare automată a piese-

lor/paletelor.

Ghidarea automată a vehiculelor se realizează de regulă prin intermediul

unui fir de ghidare îngropat, prin care este vehiculat un curent electric de

înaltă frecvenţă. Câmpul magnetic generat de fir este detectat de două bobi-

ne de dirijare, situate în faţa vehiculului. Semnalele induse în bobine sunt

amplificate, filtrate şi comparate între ele, obţinându-se un semnal de eroare

propor ţional cu deviaţia vehiculului în raport cu traseul. Acest semnal este

folosit pentru comanda sistemului de direcţie al vehiculului în vederea reve-

nirii automate pe traseu. Ciocnirea vehiculelor cu obstacole de pe traseu este

prevenită prin intermediul unor senzori ultrasonici. Aceşti senzori realizează

un ecran de protecţie la circa 1,5m distanţă de vehicul, determinând reduce-

rea vitezei, urmată de oprire dacă obstacolul nu dispare. Dacă acesta este în-

lăturat, pornirea vehiculului se face automat.


25/125

Capitolul 1. 24

Fig.1.14. Principiul fundamental al dirijării automate a vehiculelor AGV

Vehiculele ghidate automat realizează încărcarea/descărcarea obiecte-

lor/paletelor la posturile de încărcare/descărcare fixe ale depozitului

AS&RS, ale celulelor de fabricaţie, de asamblare respectiv de măsurare.Comanda sistemului de vehicule ghidate automat se realizează de către

Controlerul AGVS . Acesta este în legătur ă informaţională cu vehiculele,

staţiile de încărcare/descărcare respectiv cu staţia de încărcare acumulatoare

prin intermediul unui echipament numit Concentrator .

Controlerul AGVS comandă încărcarea/descărcarea vehiculelor ghidate

automat în anumite posturi cu semifabricate, piese, subansambluri, ansam-

bluri, separate sau aflate pe palete, traseele pe care circulă, staţionarea lor,încărcarea acumulatoarelor la posturi de alimentare cu energie electrică.

Schimbul de informaţii între calculatorul îmbarcat pe vehiculul ghidat şi


26/125

Capitolul 1. 25

Controlerul AGVS se realizează în posturi speciale de schimb de informaţii

(puncte de comunicaţie) sau prin legături radio.

Coordonarea activit ăţ ilor de fabrica ţ ie din cadrul aceluiaşi atelier sausecţii se realizează în general prin intermediul unor “calculatoare” numite

Controlere Locale (Area Controler). La acesta sunt conectate informaţional,

toate controlerele de celulă din cadrul atelierului sau secţiei.

Coordonarea tuturor activităţilor de fabricaţie de la nivelul 4. al între-

prinderii (nivelul compartimentelor de execuţie), este realizată prin interme-

diul Controlerului Principal de Uzină (Host Plant Controler). La acesta

sunt conectate informaţional, controlerele locale, controlerul AS&RS respectiv controlerul AGVS. Interconectarea controlerelor de celulă, locale,

AS&RS, AGVS respectiv a controlerului principal de uzină se realizează în

general prin intermediul Reţelei Coloană de Fabrică. Tot la această reţea

sunt conectate şi sta ţ iile de lucru de la nivelul halei industriale a fabricii

(Factory Workstations), care pot fi formate din mini-calculatoare (Mini-

Computers) cu mai multe terminale şi/sau din Calculatoare Personale (PC).

O parte din aceste staţii pot fi situate chiar şi în interiorul unor celule de fa-

bricaţie (Cell Workstations) caz în care ele sunt conectate direct la re ţeaua

de celulă (Cell Network).

Pe baza celor de mai sus, în figura 1.15. s-a reprezentat schematic mo-

delul general al structurii de comand ă aferent nivelului 4 al sistemului

CIM .

Totalitatea activităţilor de comandă/coordonare, realizate prin interme-

diul echipamentelor de comandă (CNC, ROC, PLC), controlerele de celulă,

de AS&RS, de AGVS, de controlerele locale respectiv de controlerul prin-

cipal de uzină este realizată prin participarea activă a “calculatorului”.


27/125

Capitolul 1. 26

F i g 2 . 1

5 .

M o d e l u l g e n e r a l a l s t r u c t u r i i d e c o m a n d ă

a f e r e n t n i v e l u l u i 4 a l s i s t e m u l u i C I M


28/125

Capitolul 1. 27

Astfel totalitatea acestor activităţi de comandă/coordonare formează modu-

lul funcţional de Fabrica ţ ie Asistat ă de Calculator (Computer Aided Manu-

facturing - CAM) al sistemului CIM.Cu cât este mai mare nivelul tehnic de implementare a funcţiilor de co-

mandă/coordonare din cadrul acestui modul CAM, cu atât este mai mare

gradul de automatizare a fabrica ţ iei din cadrul sistemului CIM.


29/125

Capitolul 2. 28

CAPITOLUL 2.

ECHIPAMENTE DE COMANDĂ

CU ARHITECTUR Ă DESCHISĂ

DIN CADRUL SISTEMELOR CIM

2.1. Necesitatea introducerii în sisteme CIM a echipamentelor de

comandă cu arhitectură deschisă

Dezvoltarea şi introducerea în sisteme CIM, a unor echipamente de co-

mandă cu arhitectur ă deschisă (open controller), este o solicitare formulată

de integratorii de sistem.

Observa ţ ie:

• Integratorii de sistem sunt firme specializate în proiectarea, implemen-

tarea fizică şi dezvoltarea structurilor de fabricaţie din cadrul sistemelor

CIM. În cazul unor comenzi din partea unei întreprinderi, ei achiziţio-

nează de la producători echipamentele de fabricaţie şi după caz le inte-

grează în structurile de fabricaţie existente sau creează noi structuri (de

exemplu noi celule de fabricaţie) în cadrul întreprinderii respective. De

asemenea ei realizează la cerere şi adaptarea structurilor existente la noi-

le cerinţe ale procesului de fabricaţie.


30/125

Capitolul 2. 29

În cazul echipamentelor de comandă (în continuare: controlere) cu arhi-

tectur ă “închisă” (adică specifică firmei producătoare), integratorii de sistem

au posibilităţi limitate în adaptarea acestora la cerinţe noi ale procesului defabricaţie.

Dacă această adaptare, necesită dotarea controlerelor respective cu une-

le componente (interfeţe) hardware şi/sau software noi, integratorul de sis-

tem este nevoit să apeleze la fabricantul controlerului. Acesta din urmă însă,

efectuează modificările cerute numai dacă interfeţele noi, rezultate în urma

dezvoltării, vor aduce beneficii şi fabricantului, adică ulterior vor putea fi

vândute şi la alţi “clienţi”. În aceste condiţii, integratorii de sistem solicită de la fabricanţi elaborarea controlerelor în variant ă cu arhitectur ă deschi-

să (open controller).

Fig.2.1. Tehnologia PC – un exemplu pentru o arhitectur ă deschisă


31/125

Capitolul 2. 30

Trebuie menţionat faptul că termenul de controler “deschis” nu se refer ă

la un controler “universal”, ci se refer ă la un controler care are la bază speci-

ficaţii cunoscute sau publicate. În schimb prin controler universal se înţelegeun controler care poate fi utilizat pentru comanda mai multor tipuri de echi-

pamente de fabricaţie. De fapt fiecare producător interpretează altfel acest

termen. O definiţie a unui controler deschis ar putea fi următorul:

“un controler cu hardware şi sistem de operare standard respectiv cu spe-

cifica ţ ii deschise pentru interfe ţ e”.

În domeniul sistemelor de calcul, calculatorul PC este un bun exemplu pentru un sistem cu arhitectur ă deschisă, fig.2.1. Având la bază calculatorul

personal original IBM, arhitectura hardware a PC-ului este considerată a fi

un standard “de facto” în rândul calculatoarelor comerciale. Din acest motiv

stă la baza realizării a multor tipuri de controlere deschise. La fel şi sistemul

de operare Windows, elaborat de firma Microsoft şi utilizat în milioane cal-

culatoare PC, este considerat a fi un standard “de facto”.

Controlerele brevetate (proprietary controllers), adică a căror arhitectu-

r ă este specifică numai unei anumite firme producătoare, deşi sunt perma-

nent îmbunătăţite, au o serie de dezavantaje faţă de un controler cu arhitec-

tur ă deschisă. Astfel, majoritatea controlerelor brevetate sunt considerate a

fi “insule de automatizare” datorită caracterului “închis” al acestora respec-

tiv datorită compatibilităţilor şi conectivităţilor reduse cu alte sisteme.

Multe controlere brevetate utilizează unu sau mai multe microprocesoa-

re de uz general (de exemplu Intel 8088, Motorola 68000) dar specificaţiile

pentru restul hardware-ului şi interfeţelor au la bază standarde brevetate

(respectiv sunt inaccesibile altora). Îmbunătăţirea performanţelor hardware


32/125

Capitolul 2. 31

(prin introducerea unui procesor mai rapid sau prin extensia memoriei

RAM), chiar dacă este posibilă totuşi este limitată. Configuraţiile interfeţe-

lor I/O sunt de asemenea standarde brevetate şi contribuie la generarea pro- blemelor de compatibilitate a sistemelor închise.

De exemplu, în cazul în care un controler utilizează o unitate floppy

pentru înregistrarea datelor pe dischetă, dar formatul utilizat este unul breve-

tat (adică nu se utilizează formatul standard oferit de sistemul de operare

DOS) atunci un operator va fi în imposibilitatea citirii datelor de pe aceasta,

prin utilizarea unui simplu calculator PC.

În cazul utilizării în cadrul sistemelor CIM a controlerelor deschise,toate aceste probleme pot fi rezolvate. Mai mult, hardware-ul şi sistemul de

operare fiind standard, în primul rând se creează posibilitatea ca mai mulţi

producători independenţi, să ofere componente/module hardware şi respec-

tiv software pentru dezvoltarea lor prin “upgrade”. Astfel va rezulta în timp

(aşa cum s-a întâmplat şi în cazul calculatoarelor PC) o scădere semnificati-

vă a preţurilor de vânzare. Şi aceasta este un interes al integratorilor de sis-

tem: adică ob ţ inerea unor controlere cu pre ţ scă zut respectiv posibilitatea

dezvolt ării şi adapt ării lor în func ţ ie de necesit ăţ ile procesului de fabrica-

ţ ie. În final se obţine o reducere a costurilor de integrare în sisteme CIM.

2.2. Dezvoltarea echipamentelor de comandă robot (ROC) cu

arhitectură deschisă

Controlerele robot fac parte din rândul acelor echipamente de comandă

a căror arhitectur ă deschisă contribuie la obţinerea unor costuri reduse de in-

tegrare în sisteme CIM.


33/125

Capitolul 2. 32

În prezent există mai multe variante de structur ă, pentru controlere robot

cu arhitectur ă deschisă. În fig.2.2. s-a reprezentat o anumită variantă, în care

sistemul mecanic, sistemul de acţionare, intr ările şi ieşirile (I/O) respectiv panoul de instruire sunt considerate componente care au la bază standarde

de firmă (standarde brevetate). Sistemul de comandă şi hardware-ul contro-

lerului de comunicaţie respectiv specificaţiile aferente sunt componentele

deschise ale arhitecturii.

Fig.2.2. Exemplu de diagramă bloc a unui controler robot cu ar-

hitectur ă deschisă

Eticheta de controler “deschis” (“open” controler) se refer ă în general la

arhitectura deschisă a sistemului de comandă. Acesta din urmă este conside-

rat deschis dacă este dotat cu un hardware standard, utilizează un sistem de

operare uzual şi permite accesul la software-ul intern de comandă printr-o

serie de libr ării şi module standarde.


34/125

Capitolul 2. 33

2.2.1. Evoluţia echipamentelor de comandă robot către o arhitectu-

ră deschisă

În funcţie de tipul arhitecturii utilizate, controlerele robot moderne pot fi

grupate în 5 mari categorii:

1. Controler cu hardware şi sistem de operare brevetat;

2. Controler cu hardware de PC şi sistem de operare brevetat;

3. Controler cu hardware de PC şi sistem de operare Windows şi

VxWorks într-o soluţie dubluprocesor;

4. Controler cu hardware de PC şi hardware brevetat, cu sistem de

operare specific şi adiţional Windows într-o soluţie dublupro-

cesor;

5. Controler cu hardware de PC cu sistem de operare Windows şi

VxWorks într-o soluţie monoprocesor.

Cele mai “închise” sunt acele controlere de robot, care au la bază un

hardware şi un software de sistem de operare brevetat (categoria 1). Ele

sunt caracterizate prin faptul că atât hardware-ul precum şi software-ul utili-

zat pentru conducere (comandă şi acţionare) au la bază specificaţii închise,

care sunt utilizate numai de un anumit fabricant.

În majoritatea cazurilor ele sunt considerate secrete de firmă. În aceste

condiţii orice modificare hardware sau software a controlerului, în vederea

dezvoltării sau adaptării, poate fi f ăcută numai de firma producătoare.


35/125

Capitolul 2. 34

Fig.2.3. Exemplu de controler de robot cu hardwareşi sistem de operare brevetat

La aceste controlere, protocolul de comunicaţie utilizat la legătura cu al-

te echipamente, este în general deschis. Astfel ele permit conectarea la un

calculator PC adiţional, pe care este rulat un sistem de operare deschis (de

exemplu Windows). Pentru acest calculator PC pot fi realizate, o serie de

pachete software pentru programarea limitată a aplicaţiilor, în mod text sau

în mod grafic. Însă accesul la software-ul intern, legat de modul de realizarea conducerii, este imposibil pentru un utilizator. În general display-ul con-

trolerului de robot nu are capabilităţi grafice, fig.2.3.

În a doua categorie intr ă acele controlere care au la bază un hardware

standard de PC şi un software de sistem de operare brevetat (categoria 2).

Trebuie subliniat că foarte mulţi utilizatori agreează idea utilizării controle-

relor deschise bazate pe tehnologia PC. Motivul este performanţele ridicate

ale microprocesoarelor şi faptul că preţurile “chip”-urilor, respectiv ale in-terfeţelor de conectare la reţea, sunt relativ mici.


36/125

Capitolul 2. 35

Fig.2.4. Exemplu de panou de programare cu display

cu grafică limitată

Aceste controlere însă, deşi hardware-ul de PC ofer ă o platformă des-

chisă pentru realizarea conducerii, datorită software-ului brevetat, capătă un

caracter închis. Ca avantaj, hardware-ul de PC asigur ă un preţ mai scăzut

pentru controler, respectiv asigur ă posibilitatea unui “upgrade” cu compo-

nente standarde. La aceste controlere, în general există o anumită

capabilitate grafică a panoului de programare, însă aceasta este restricţionată

de sistemul de operare care este puţin dezvoltat în acest sens, fig.2.4.


37/125

Capitolul 2. 36

Pentru a avea o platformă de operare într-adevăr deschisă, la controlere-

le noi a fost introdus, pe o arhitectura de PC, sistemul de operare Windows.

Însă trebuie menţionat faptul că Windows nu este sistemul de operare celmai potrivit pentru realizarea controlului în timp real. În schimb ofer ă o

capabilitate ridicată pentru integrarea f ăr ă probleme a unor module hardwa-

re şi software adiţionale. În aceste condiţii a fost promovată o soluţie cu do-

uă sisteme de operare rulate împreună: un sistem de operare în timp real şi

un sistem de operare care ofer ă o platformă deschisă: Windows.

Un adevărat sistem de operare în timp real este VxWorks realizat de

firma Wind River System. Acesta din urmă este utilizat alături de sistemulde operare Windows în două variante:

• cu dublu procesor , caracteristic controlerelor din categoria 3 şi

• cu monoprocesor , caracteristic controlerelor din categoria 5.

În variant ă cu dublu procesor (categoria 3), se utilizează practic o arhitec-

tur ă hardware de PC cu două pl ăci de baz ă, fiecare fiind echipată cu câte un

microprocesor. Astfel sistemele de operare Windows şi VxWorks sunt rula-

te separat, pe câte o placă de bază care însă comunică între ele prin protoco-lul TCP/IP sub Ethernet, fig.2.5.

Fig.2.5. Comunicaţia între VxWorks şi Windows în varianta biprocesor


38/125

Capitolul 2. 37

VxWorks este utilizat pentru prelucrarea tuturor task-urilor de timp real

(de exemplu generarea traiectoriei etc.) iar Windows este utilizat ca bază a

funcţiilor de operare şi programare. Aceste funcţii sunt realizate prin utiliza-rea unei tastaturi şi a unui monitor standard. La aceste controlere nu este uti-

lizat separat un panou de programare.

De asemenea, controlerul în general este oferit f ăr ă o interfaţă utilizator

concretă. În schimb fabricantul furnizează o serie de libr ării şi module sof-

tware deschise pentru sistemul de operare Windows, care pot fi utilizate de

integratorii de sistem pentru crearea unor interfeţe utilizator adecvate aplica-

ţiei.Având în vedere că într-o soluţie biprocesor, platforma deschisă este

oferită doar de sistemul de operare Windows, pentru partea de control în

timp real în esenţă poate fi folosit şi un hardware respectiv sistem de operare

brevetat. Aceasta este caracteristică controlerelor din categoria 4. Aceste

controlere deşi ofer ă o capabilitate grafică ridicată, legată de operare şi pro-

gramare, totuşi utilizează pentru conectarea informaţională la alte echipa-

mente respectiv pentru integrarea în sisteme interfeţe speciale, nestandarde.

O soluţie ideală, din punctul de vedere al preţului de cost, este imple-

mentarea celor două sisteme de operare, de exemplu VxWorks şi Windows,

pe un singur hardware de PC (categoria 5), adică într-o soluţie monopro-

cesor.

Practic pe aceeaşi platformă PC (adică prin utilizarea unui singur mi-

croprocesor), sunt rulate simultan două sisteme de operare. Ele comunică

prin intermediul unui “driver” TCP/IP utilizând o zonă de memorie comună

(shared memory).


39/125

Capitolul 2. 38

Fig.2.6. Comunicaţia tipică între VxWorks şi Windows

în varianta monoprocesor

Pentru garantarea unui control în timp real, VxWorks are prioritate de

execuţie faţă de Windows. Practic când un task de VxWorks este activ (de

exemplu un task legat de generarea traiectoriei) timpul de execuţie procesoreste disponibil doar pentru VxWorks. Cu alte cuvinte, task-urile Windows-

ului sunt executate numai în acele perioade de timp, când nici un task

VxWorks nu este activ.

Aceste controlere posedă toate avantajele tehnologiei PC. Oricând per-

mit integrarea unui hardware adiţional prin utilizarea magistralei ISA/PCI.

De asemenea ofer ă posibilitatea utilizării interfeţelor standarde de conectare

la reţea.


40/125

Capitolul 2. 39

F i g . 2 . 8 .


41/125

Capitolul 2. 40

Fig.2.7. Panoul de programare al controlerului KUKA KR C1

Un exemplu pentru o arhitectur ă cu VxWorks şi Windows pe o singur ă

platformă PC, este controlerul KR C1 al robotului KUKA. În fig.2.7. s-a re-

prezentat panoul de programare al acestui controler. În fig.2.8. s-a încercat

reprezentarea evoluţiei controlerelor de robot către o arhitectur ă deschisă.

2.2.2. Exemple de echipamente de comandă robot cu arhitectură

deschisă

În continuare se prezintă două exemple pentru controlere de robot cu

arhitectur ă deschisă: un controler Bosch IQ200 al robotului Turboscara

SR6/SR7 şi un controler KR C1 al unui robot KUKA.


42/125

Capitolul 2. 41

2.2.2.1. Controler Bosch IQ200 al robotului Turboscara SR6/SR7

Fig.2.9. Sistemul robot Bosch – Turboscara


43/125

Capitolul 2. 42

Fig.2.7. Arhitectura calculatorului industrial “rh04” din

cadrul controlerului IQ200


44/125

Capitolul 2. 43

Bosch IQ200 este un exemplu tipic pentru un controler robot cu arhitec-

tur ă deschisă. Este utilizat la familia de roboţi TurboScara SR6/SR8. La ba-

za controlerului stă un PC industrial numit “rh04”, cu un procesor Pentium.Pentru conectarea la controler a modulelor de conducere nemijlocită ale ce-

lor 4 axe de robot, se utilizează o magistrală de câmp (fieldbus) de tip CAN.

O altă magistrală (CAN2) este utilizată pentru conectarea la controler a dis-

pozitivelor periferice: senzori, actuatori, module I/O etc. Pentru operare,

poate fi utilizat panoul de instruire PHG2000, ecranul de “atingere” (touch-

screen), BF200T sau un calculator PC extern.

Pe calculatorul rh04 este rulat simultan sistemul de operare de timp realVxWorks şi sistemul de operare Windows. Pe magistrala PCI este instalat

un modul de extensie denumit PCI_RHO, fig.2.10. Acesta include: interfeţe

pentru magistrala CAN către acţionări (cele 4 axe ale robotului) şi către dis-

pozitivele periferice (senzori, actuatori) respectiv o interfaţă către panoul de

instruire PHG2000.

O altă funcţie cheie a calculatorului rh04 este utilizarea protocolului

TCP/IP pentru conectarea la o reţea standardă. Aceasta permite atât schim-

burile de date între modulele software interne cât şi comunicaţia externă cu

aplicaţii standard sau aplicaţii utilizator. De asemenea este implementată o

capabilitate de diagnosticare de la distanţă via TCP/IP.

Prin utilizarea funcţiilor noi de bibliotecă (library) este posibilă ini ţ ierea

mi şcărilor la axe, de la o aplica ţ ie Windows. Pentru programarea robotului

poate fi utilizat calculatorul industrial rh04 din interiorul controlerului

IQ200 sau un calculator PC extern. În acest caz din urmă, datele şi/sau pro-

gramele pot fi introduse în memoria controlerului printr-o interfaţă serială

sau printr-o legătur ă Ethernet sub TCP/IP. Panoul de instruire este utilizat în


45/125

Capitolul 2. 44

prima fază pentru instruirea/învăţarea robotului şi pentru diagnosticarea ero-

rilor. De asemenea permite şi modificarea sau editarea programului robot de

aplicaţie.Programele de “mişcare” robot sunt scrise într-un limbaj asemănător

PASCAL-ului numit BAPS. Programele robot BAPS pot fi create cu un edi-

tor de texte sau cu un utilitar de programare grafică: BAPSplus. Pentru rea-

lizarea funcţiilor de automat programabil (PLC) se utilizează un software

WIN-PLC.

În cadrul calculatorului industrial rh04, se utilizează un procesor

Pentium de mare performanţă. Acest microprocesor este sec ţ ionat în două procesoare virtuale P1 şi P2. Procesorul P1 este procesorul de limbaj

BAPS. Interpretează comenzile şi planifică desf ăşurarea acţiunilor şi traiec-

toria pentru mişcare (calculează în avans până la 11 “puncte”). În mod adiţi-

onal, procesorul P1 este responsabil de legătura cu sisteme vision respectiv

cu calculatoare Host, asigur ă funcţiile PLC respectiv asigur ă realizarea

schimburilor de informaţii cu un operator, printr-o interfaţă Windows.

Task-ul procesorului P2 este generarea punctelor prescrise, separat

pentru fiecare axă, respectiv realizarea transformărilor de coordonate. Moni-

torizează limitele spaţiului de lucru sau limitele de cursă pentru axe.

De fapt calculatorul rh04 poate controla simultan până la 16 axe. Funcţi-

ile extinse, cum sunt interconectarea cu alte sisteme prin TCP/IP, comunica-

ţia cu operatorul prin interfeţe standarde DDE şi DLL şi utilizarea tehnolo-

giei PC pentru realizarea conducerii, asigur ă o veritabilă arhitectur ă deschi-

să.


46/125

Capitolul 2. 45

2.2.2.2. Controler KR C1 al unui robot KUKA

Controlerul KR C1 este realizat de firma KUKA Roboter GmbH. Are la bază un hardware de PC cu sistem de operare Windows (realizat de firma

Microsoft) şi VxWorks (sub formă de LP-VxWin realizat de LP Elektronik

GmbH), într-o variantă monoprocesor.

Fig.2.11. prezintă arhitectura întregului sistem robot. D.p.d.v. hardware,

utilizează o placă de bază PC cu microprocesor Pentium. Cele două sisteme

de operare sunt rulate pe acelaşi procesor, schimbul de date între ele (cum

sunt valori de variabile, comenzi, încărcare/descărcare programe robot) serealizează prin utilizarea protocolului TCP/IP. Funcţiile de operare, afişare

şi gestiune date sunt implementate sub Windows (este disponibilă o interfaţă

utilizator completă). VxWorks este utilizat pentru toate task-urile de timp

real cum sunt: generarea traiectoriei; procesarea comenzilor şi procesarea

informaţiilor provenite de la interfeţe periferice (senzori).

Pentru comanda acţionărilor respectiv cuplarea magistralelor şi intr ări-

lor/ieşirilor (I/O) digitale, se utilizează o placă multifunc ţ ional ă MFC

(Multi-Function Card) care se introduce pe magistrala PCI a plăcii de bază.

Placa MFC este prevăzută cu un procesor de semnale digitale DSP (Digital

Signal Procesor) care transformă PC-ul într-un controler industrial. Această

placă de asemenea conţine un circuit de “accelerator de timp real” (Real-

time Accelerator Chip).

Pentru comunicaţia cu echipamente/dispozitive periferice, în configura-

ţia standard, un modul de magistral ă CAN (care suportă protocolul

DeviceNet), este integrat în placa MFC.


47/125

Capitolul 2. 46

F i g . 2 . 1

1 .

A r h i t e c t u r a c o n t r o l e r u l u i d e r o b o t K R C 1


48/125

Capitolul 2. 47

Cuplarea altor sisteme de magistrale de câmp (Interbus, Profibus, FIP, etc.)

este posibilă prin utilizarea unor plăci de extensie adiţionale. Pentru comu-

nicaţie prin Ethernet (utilizând protocolul TCP/IP) există două soluţii:1. o legătur ă cu placa MFC, realizând astfel un acces direct la sis-

temul de operare VxWorks;

2. o legătur ă prin placa de bază, realizând astfel accesul la schimbul

de date între Windows şi VxWorks.

2.3. Dezvoltarea echipamentelor de comandă numerică (CNC) cu

arhitectură deschisă

În cazul echipamentelor de comandă numerică (CNC) au fost dezvoltate

mai multe variante, care ofer ă soluţii cu arhitecturi mai mult sau mai puţin

deschise.

2.3.1. Clasificarea echipamentelor CNC cu arhitectură deschisă

Fig.2.12. Clasificarea echipamentelor CNC “deschise”


49/125

Capitolul 2. 48

Echipamentele CNC “deschise” fabricate recent, pot fi clasificate în 3

mari categorii, fig.2.12.:

1. echipamente CNC dotate cu interfe ţ e utilizator deschise,2. echipamente CNC cu acces limitat la “kernel” ,

3. echipamente CNC cu arhitectur ă deschisă de comand ă.

1. Trebuie ar ătat faptul că, deja aproape fiecare CNC nou este prevăzut cu

o interfa ţă utilizator deschisă (varianta a., din fig.2.12.), ceea ce a de-

venit o cerinţă minimală la vânzarea acestor echipamente. Această vari-

antă de sistem, în anumite condiţii, ofer ă posibilitatea modifică-

rii/adaptării libere a interfeţei respective, prin modificarea componente-lor/modulelor software afe-

rente. Însă “nucleul” sof-

tware-ului de comandă

(numit “ Kernel NC” ), prin

care se realizează funcţiile

principale de control nume-

ric (de exemplu interpolare,

comanda mişcărilor la axe

etc.) este “închis”. Accesa-

rea acestui nucleu este po-

sibilă pentru un utilizator,

doar prin intermediul unei

interfeţe speciale de pro-

gramare, oferit de producă-

tor.

Fig.2.13. CNC Fanuc din seria 150i-MConform firmei GE


50/125

Capitolul 2. 49

Fanuc (care este cel mai mare producător de CNC pe lume), un CNC

“deschis” este de fapt un CNC integrat într-un PC . GE Fanuc ofer ă

mai multe soluţii unde, CNC-ul este practic un modul de extensie intro-dus într-un PC, pe care este rulat Windows. Un exemplu este CNC-ul

din seria 150i-M, (fig. 3.13.). Utilizatorul sau fabricantul de maşină-

unealtă, poate rula pe acest sistem şi programele proprii, care pot accesa

resursele CNC dar f ăr ă posibilitate de modificare/ adaptare a acestora.

2. Pe lângă existenţa unei interfeţe utilizator deschise, la unele CNC-uri

(varianta b.), există posibilitate şi pentru “completarea” func ţ iilor nu-cleului Kernel respectiv schimbarea/înlocuirea limitat ă a unor algo-

ritmi . Acest lucru însă este foarte puţin sprijinit de marile firme produ-

cătoare de CNC-uri.

Un exemplu este echipamentul SINUMERIK 840C al firmei Sie-

mens, format din următoarele elemente funcţionale: MMC (legătur ă om-

maşină), NCK (Kernel NC) şi PLC (automat programabil). Caracterul des-

chis se manifestă la nivelul MMC, prin posibilitatea rulării software-elor

OEM pe o platformă Windows, adică este aceeaşi soluţie ca şi în cazul fir-

mei GE Fanuc. Suplimentar însă, cu licenţă OEM (adică cu contract direct

cu producătorul), există posibilitatea integr ării limitată a unor funcţii specia-

le NCK, legate de interpolator, controlul de poziţie.

Pe lângă “cei mari”, din ce în ce mai multe firme mici ofer ă soluţii

complete pentru echipamente CNC pe bază de PC, cu arhitectur ă “par ţial”

deschisă. D.p.d.v. al arhitecturii există 3 configura ţ ii tipice:


51/125

Capitolul 2. 50

• Configuraţie în care, pe lângă placa de bază a PC-ului, nucleul

Kernel este rulat pe un modul de extensie, cu conectare directă la

acţionări şi module I/O. De exemplu familia XMP a firmeiMotion Engineering, la care task-urile de timp real pot fi accesa-

te prin intermediul unei interfeţe C/C++.

• Configuraţie cu două sau mai multe procesoare unde pe un pro-

cesor este rulat nucleul Kernel de timp real, iar pe altul este rula-

tă interfaţa utilizator sub sistemul de operare Windows. Acest

model este utilizat de Siemens şi Fanuc.

• Configuraţie în care pe un singur procesor este rulat atât siste-mul de operare Windows cât şi Kernelul de timp real, în mod

asemănător controlerului de robot KUKA KR C1. Un exemplu în

acest sens este sistemul OpenCNC al firmei MDSI, unde pe un

singur procesor este rulat Windows şi sistemul de operare RTX.

Pe fig.2.14. se poate observa faptul că sistemul are atât interfaţă

utilizator NT cât şi de timp real.

Fig.2.14. Arhitectura modular ă a sistemului OpenCNC


52/125

Capitolul 2. 51

3. Echipamente CNC complet deschise (varianta c.), sunt acele care au

fost dezvoltate prin proiecte majore de cercetare internaţională. În cadrul

acestor proiecte de cercetare s-a urmărit obţinerea unor solu ţ ii indepen-dente de producător , cu o arhitectur ă modular ă, care să permite integra-

rea, modificarea, înlocuirea şi interschimbabilitatea modulelor software

atât în partea de utilizator, cât şi în partea de timp real.

2.3.2. Proiecte majore de cercetare legate de dezvoltarea unor echi-

pamente CNC cu arhitectură deschisă

Dezvoltarea unor echipamente CNC cu arhitectur ă deschisă a fost obi-

ectul a mai multor proiecte de cercetare la nivel internaţional. Cele mai im-

portante sunt următoarele:

1. proiectul OSACA (Open System Architecture for Controls

within Automation systems),

2. proiectul OMAC (Open, Modular Architecture Controller) şi

3. proiectul OSEC (Open System Environment for Controllers).

2.3.2.1. Proiectul OSACA (Open System Architecture for Controls

within Automation systems)

Proiectul OSACA (Open System Architecture for Controls within

Automation systems) a fost lansat în anul 1992 cu finanţare ESPRIT. Până

în anul 1998, cu un buget de 12,3 milioane de Euro, a dezvoltat prima oar ă

în lume o arhitectur ă deschisă, independentă de furnizori. În consor ţ iul

OSACA au participat: mari întreprinderi producătoare de echipamente de


53/125

Capitolul 2. 52

comandă din Europa (Siemens, Bosch, NUM, Fagor, etc., ), întreprinderi

producătoare de maşini-unelte (Homag, Comau, Trumpf), instituţii de cerce-

tare (ISW, WZL, IWB, INTEC etc.) şi întreprinderi utilizatoare (BMW,DaimlerChrysler).

Prin proiectul OSACA s-a urmărit dezvoltarea unei arhitecturi modulare

de control pentru maşini unelte. S-a pornit de la arhitectura de bază a siste-

melor de control modular, care este formată dintr-o platformă de sistem

(hardware-ul şi software-ul de sistem) şi dintr-un set de module ale softwa-

re-ului de aplicaţie, care au implementate funcţiile specifice de control,

fig.2.15.

Fig.2.15. Structur ă de baza a unui sistem modular de control

Fig.2.16. Principiul arhitecturii OSACA


54/125

Capitolul 2. 53

Meritul cel mare al proiectului OSACA, este definirea unei interfeţe de

programare aplicaţie API (Application Programming Interface) care este in-

dependentă de furnizori. API asigur ă integrarea standardă a diferitelor mo-

dule (AO – Application Object) şi legătura lor la software-ul de sistem.

Acesta din urmă este format din sistemul de operare, sistemul de comunica-

ţie şi sistemul de configurare, fig.2.16. Arhitectura de referinţă OSACA,

grupează obiectele de aplicaţie AO în cinci categorii:

1. Control Om-Maşină (MMC – Man-Machine Control) care repre-

zintă maşina sau o parte din maşină către entităţi externe, cum este

un operator uman, sisteme de supervizare prin reţea LAN şi sisteme

CAD/CAM pentru maşină etc., respectiv permite acestor entităţi rea-

lizarea unui control prin operare.

2. Control Mişcare (MC – Motion Control) permite realizarea unor

mişcări relative de-a lungul a mai multor grade de mobilitate, mate-

rializate prin axele maşinii. În urma controlului, mişcările rezultate

trebuie să fie precise, continue şi sincronizate.

3. Controlul Logic (LC – Logic Controls) este responsabil pentru fun-

cţionarea actuatoarelor şi pentru preluarea informaţiilor de la senzo-

rii montaţi pe maşină.

4. Control Axe (AC – Axis Control) include toate acele elemente care

sunt necesare pentru activarea axelor în vederea execuţiei comenzi-

lor de mişcare în condiţiile prevăzute.

5. Control Proces (PC – Process Control) reprezintă - atunci când suntutilizate - sistemele auxiliare ale maşinii. Este responsabil pentru

gestiunea şi procesarea datelor aferente acestor sisteme.


55/125

Capitolul 2. 54

Fig.2.16. Elementele arhitecturii de referinţă OSACA

În general, modulele software corespunzătoare acestor grupuri de obiec-

te sunt rulate pe mai multe platforme OSACA interconectate. Un exemplu

tipic este cazul unui echipament CNC cu arhitectur ă OSACA, la care panoul

operator (având la bază un calculator compatibil PC) este conectat prin legă-

tur ă Ethernet sub TCP/IP la controlerul de mişcare (care are la bază magis-trală VME), fig.2.17.

Fig.2.17. O configuraţie tipică OSACA


56/125

Capitolul 2. 55

Sistemul deschis de control aferent, realizat pe baza arhitecturii

OSACA, este constituit din două platforme: o platformă care are la bază un

PC respectiv ca sistem de operare este utilizat Windows şi o altă platformă cu procesor propriu, cu sistemul de operare în timp real VxWorks. Sistemul

de comunicaţie permite modulelor AO, un schimb transparent de date prin

legătura TCP/IP.

Fig.2.18. Arhitectura OSACA a sistemului

Existând deci o platformă API deschisă şi bine definită, fiecare utiliza-

tor de echipament CNC (realizat pe baza arhitecturii OSACA), are acces la

toate resursele acestuia, chiar şi până la nivelul conducerii nemijlocite (de

exemplu control şi reglare poziţie). Obiectele AO pot fi modificate, înlocui-

te sau pot fi integrate altele, suplimentare.

Astfel, prin proiectul OSACA a rezultat o arhitectur ă de comand ă

complet deschisă, independentă de furnizori.


57/125

Capitolul 2. 56

Primul sistem complet de comand ă, cu structur ă OSACA, a fost reali-

zat la institutul de cercetare WZL din Aachen. Structura de principiu a sis-temului de comandă este prezentat în fig.2.17. Acesta utilizează 3 platforme

OSACA interconectate: o platformă cu Windows pentru operare, una cu

VxWorks 5.2 pentru parte de control în timp real, şi una cu Solaris 2.4. pen-

tru partea de CAM.

Fig.2.17. Structura de principiu a sistemului de comandă realizat la WZL

Prototipuri ale sistemelor cu arhitectur ă OSACA au fost prezentate la

mai multe universităţi şi expoziţii, chiar şi în uzinele BMW şi Mercedes.

Firma Siemens a prevăzut că va lansa pe piaţă un echipament de comandă

cu arhitectur ă OSACA. Însă datorită lipsei de finan ţ are, utilizatorii cei maiînsemnaţi au r ămas mediile universitare, unde aproape toate cercetările lega-


58/125

Capitolul 2. 57

te de CNC au loc prin utilizarea platformelor OSACA (de exemplu la WZL

din Aachen, sau ISW din Stuttgart).

2.3.2.2. Proiectul OMAC (Open Modular Architecture Controller)

Proiectul OMAC (Open Modular Architecture Controller) a fost lansat

în 1994, când trei întreprinderi constructoare de automobile din SUA, au

publicat un sistem comun de cerinţe legate de sistemele de comandă pe care

le vor achiziţiona în viitor. Scopul a fost creşterea flexibilităţii în cadrul sis-

temelor proprii de fabricaţie, prin urgentarea şi încurajarea furnizorilor încomercializarea controlerelor deschise respectiv modulare.

Trebuie ar ătat faptul că în cadrul proiectului nu s-a fixat o anumită arhi-

tectur ă de referinţă ci a fost dezvoltată o metodologie şi un sistem cadru ge-

neral.

Fig.2.18. Exemplu de interconectare a modulelor prin interfeţele aferente


59/125

Capitolul 2. 58

În schimb s-a definit o serie de clase de bază care rezultă din decompo-

ziţia arhitecturii unui controler general. Clasele de bază sunt grupate în mo-

dule, care sunt elementele de bază ale unui controler OMAC. Modulele suntconstruite dintr-o serie de elemente predefinite respectiv sunt prevăzute cu

nişte interfeţe de conectare. Modulele pot fi interconectate doar prin in-

termediul acestor interfeţe. În aceste condiţii, construirea unui anumit sistem

de comandă se reduce la selectarea, implementarea individuală şi interco-

nectarea diferitelor module OMAC. Având în vedere că au fost stabilite

numai câteva reguli generale, proiectantul are mână liber ă în stabilirea arhi-

tecturii sistemului de comandă.Din modulele OMAC poate fi construit orice echipament de comandă,

de la cel mai simplu (utilizat de exemplu pentru comanda unui sistem de ri-

dicare cu o singur ă axă), până la cel mai complex (utilizat de exemplu pen-

tru comanda unui centru de prelucrare cu mai multe axe).

Fig.2.19. Modulele OMAC ale unei maşini de găurit


60/125

Capitolul 2. 59

În fig.2.19. s-au reprezentat modulele OMAC aferente sistemului de

comandă al unei maşini de găurit, la care se poate sincroniza mişcarea axei

Z cu mişcarea arborelui principal. Asemănător proiectului OSACA, în pre-zent aplicaţiile practice ale proiectului OMAC există doar la nivel de labora-

toare de cercetare.

2.3.2.3. Proiectul OSEC (Open System Environment for

Controllers)

Firmele Toyota, Toshiba, Mazak şi Mitsubishi au format un grup de lu-cru sub numele de OSEC (Open Sytem Environment for Controllers) cu

scopul dezvoltării unei arhitecturi deschise de comandă specific japonez.

Mai târziu, împreună cu mai multe firme şi universităţi japoneze, care lucrau

la dezvoltarea unor sisteme deschise de automatizare (numit FA - Factory

Automation), au înfiinţat grupul JOP (Japan FA Open Sytem Promotion

Group).

În cadrul acestui proiect a fost dezvoltat modelul de referin ţă OSEC ,

care în mod asemănător nivelelor OSI este format din 7 nivele. Nivelele sunt

următoare: mecanică, electrică, comandă dispozitiv, comandă geometrie,

comunicaţie, operare precum şi CAD/CAM. În centrul atenţiei au stat

schimburile informaţionale între aceste nivele.

În mod asemănător proiectului OSACA, şi în cazul arhitecturii OSEC

resursele sistemului de comandă sunt grupate în module funcţionale. A fost

elaborată o interfaţa de programare aplicaţie (API), care presupune existenţa

între modulele funcţionale respective, a unei zone de coordonare mesaje,

fig.2.20.


61/125

Capitolul 2. 60

Fig.2.20.Arhitectura de referinţă OSEC

În cadrul interfeţei API sunt definite câteva obiecte generale, precum şi

modalităţile de acces la serviciile aferente acestor obiecte. Tot în cadrul

acestui proiect a fost elaborată o specificaţie cu numele PAPI care este in-

terfaţa programului utilizator, adică specifică legătura între partea de co-

mandă şi partea de afişare/reprezentare a echipamentului.


62/125


63/125

Capitolul 3.

Relativ la figura '# se spune că poziţia P' este !n amonte sau este o

intrare pentru tranziţia T' (arcul este orientat dinspre P' spre T')# Poziţia P+

este !n aval sau este o ieire a tranziţiei T'# O tranziţie fără poziţie de intrare

este o tranziţie sursă (generator)# O tranziţie fără poziţie de ieire este o

tranziţie !nfundată (ani"ilator)#

3.1.#. M"rc"$%l

O altă categorie folosită la studiul RP este marca/ul# 6iecare poziţie

conţine un număr !ntreg (pozitiv sau nul) de sim7oluri (puncte) care se

6ig#'## Reţea Petri: a) nemarcată; 7) marcată

62


64/125

Capitolul 3.

numesc mărci sau /etoane# &n figura '##a este prezentată o RP marcată, iar

!n figura '##7 o RP nemarcată#

6iecărei poziţii, funcţie de e1istenţa8 ine1istenţa punctului (!ngeneral a sim7olului), i se poate asocia un marca/# 9arca/ul unei poziţii P i se

notează cu 9(Pi) sau mi# 9arca/ele corespunzătoare poziţiilor reţelei din

figura '##7# sunt: m2 m4 m+ m , m m' , m* 2#

9arca/ul reţelei se notează cu 9# Pentru o RP cu n poziţii acesta este

definit prin vectorul 9 (mi, m2, ### mi, ### ml)# 9arca/ul reţelei din figura

'##7# este 9 (, , , , , 2, )#

Observaţie:

• acă m ∈ 3,l5, i l, n, RP face parte din categoria reţelelor Petri

7inare#

9arca/ul definete, la un moment dat, starea sistemului modelat cu a/utorul

RP# Pentru a e1emplifica această afirmaţie se consideră o celulă de

fa7ricaţie fle1i7ilă ca i cea reprezentată !n figura '#2#


65/125

Capitolul 3.

6ig#'#'# 9odelul cu RP al celulei de fa7ricaţie#

Prezenţa mărcilor !n poziţiile P (9= este li7eră) i P2 (R. are

o7iectul de lucru), figura '#'#a, semnifică faptul că sunt create condiţiile ca

9= să poată fi !ncărcată# upă ce evenimentul modelat de tranziţia T are

loc (s-a e1ecutat comanda de !ncărcare o7iectului de lucru pe 9=) starea

sistemului este cea descrisă !n figura '#'#7: poziţiile P i P2 nu sunt marcate,

iar poziţiile P' (9= este !ncărcată) i P4 (R. este li7er) conţin fiecare c%te omarcă#

>voluţia stării sistemului corespunde unei evoluţii a marca/ului#

3.1.3. E&ec%ţi" %nei tr"nziţii

&n ceea ce privete tranziţiile, o tranziţie este executabilă numai

atunci c%nd fiecare poziţie din amonte conţine cel puţin un marca/# &n acest

caz se spune că tranziţia este executabilă sau validată.

O tranziţie sursă este totdeauna validată.

64


66/125

Capitolul 3.

&n figura '#4 - secţiunea .. sunt prezentate tranziţiile e1ecuta7ile: T (6ig#

'#4#a) T2 (6ig# '#4#7), T' (6ig# '#4#c) i tranziţia nee1ecuta7ilă (6ig# '#4# d)#

6ig# '#4. >1ecuţia unei tranziţii

>1ecuţia unei tranziţii T/ constă !n a retrage c%te o marcă din fiecare

din poziţia din amonte (poziţie de intrare) i a pune c%te o marcă !n fiecare

poziţie din aval (poziţie de ieire)# Poziţiile din amonte i din aval se

consideră relativ la tranziţia T/#

>1ecuţia tranziţiilor T, T2 i T' duce la o7ţinerea marca/elor din

figura 2# 4- secţiunea ..#

65


67/125

Capitolul 3.

Observaţie:

•


68/125

Capitolul 3.

&n figura '#* este prezentată o RP care modelează ciclul stărilor unui

motor# $cesta este oprit, apoi pornit, apoi oprit etc# &n starea

corespunzătoare marca/ului din figura '#* motorul este oprit i singuratranziţie validată (e1ecuta7ilă) este T# >1ecuţia tranziţiei T este

condiţionată de producerea evenimentului e1terior: ? comanda de pornire?#

6ig#'#*# RP dependentă

&n acest caz sistemul este modelat cu a/utorul unei RP dependente#

O RP dependentă descrie funcţionarea unui sistem c%nd evoluţia acestuia

este condiţionată de evenimente e1terne sau de timp#

3.3. Pre)c%rtri (i e&ten)ii "le reţelelor Petri

Tipurile de RP care urmează să fie prezentate nu corespund e1act

regulilor de funcţionare definite anterior#

67


69/125

Capitolul 3.

Prescurtările (abrevierile) corespund unor reprezentări simplificate,

utile pentru a simplifica scrierea modelelor, acestora put%ndu-se, totdeauna,

asocia o RP ordinară (RP poziţie tranziţie). !xtensiile sunt reprezentări cărora li s-au adăugat reguli de

funcţionare suplimentare, care !m7ogăţesc modelul iniţial, ceea ce permite

a7ordarea unui număr mai mare de aplicaţii#

Toate proprietăţile RP ordinare se vor păstra, cu c%teva adaptări,

pentru prescurtări. e asemenea proprietăţile RP ordinare nu se păstrează,

!n totalitate pentru toate e1tensiile#

&n categoria prescurtărilor sunt următoarele tipuri de RP:• RP "eneralizate#

• RP de capacitate#

• RP colorate.

in categoria extensiilor fac parte:

• RP dependente (neautonome).

3.3.1. Reţele Petri *ener"liz"te

O RP "eneralizată, este o RP !n care arcelor le sunt asociate numere

naturale care poartă numele de $ncărcări# &n figura '# este prezentară o RP

generalizată !n diverse momente de funcţionare#

&n ceea ce privete RP generalizată din figura '# se remarcă faptul

că arcul P T are !ncărcarea ' i arcul T P4 are !ncărcarea 2

Toate arcele a căror !ncărcare nu este e1plicită au !ncărcarea #

' 2

68


70/125

Capitolul 3.

.n general dacă un arc Pi T / are o !ncărcare p, aceasta !nsea-

mnă că tranziţia T / nu va fi validată p%nă c%nd poziţia Pi va conţine mai

puţin de p marca/e# upă e1ecuţia tranziţiei T /, cele p marca/e nu se vor mairegăsi !n poziţia Pi#

6ig#'## Reţea Petri generalizată

acă un arc T / Pi are o !ncărcare p, e1ecuţia tranziţiei T /

presupune adăugarea a p marca/e poziţiei P /#

Proprietate:

Toate RP "eneralizate pot fi transformate !n RP ordinare (RP

poziţie tranziţie).

9odalitatea de transformare este prezentată !n figura '#@# &n figura

'#@#a# este prezentată o RP generalizată, !ncărcarea arcului T P fiind

2#

p

p

2

69


71/125

Capitolul 3.

6ig#'#@# Transformarea unei RP generalizate !n RP ordinară

9arca/ul prezent este 9 (, , ), singura tranziţie validată

(e1ecuta7ilă) este T# upă e1ecuţia tranziţiei T se o7ţine marca/ul 92 (2,

, )#

&n figura '#@#7 este redată o RP ordinară, ec"ivalentă cu RP

generalizată din figura '#@#a, !n care e1ecuţia secvenţei TA, TAA se su7stituie

e1ecuţie tranziţiei T# &n figura '#@#7# singura tranziţie e1ecuta7ilă este TA,

după e1ecuţia sa va e1ista o singură marcă !n P i o marcă !n PA, celelalte

poziţii răm%n%nd vide# Bingura tranziţie validată este atunci TAA, după

e1ecuţia sa vor fi două mărci !n P i o marcă !n P# Pentru poziţiile P, P2 i

P' se o7ţin aceleai marca/e ca i !n cazul RP ordinare din figura '#@#a#

70


72/125

Capitolul 3.

Poziţiile Po i PoA au fost adăugate pentru a asigura e1ecuţia

tranziţiilor TA i TAA# Poziţia P - poziţie de intrare i de ieire pentru T2-

opune e1ecuţia tranziţiei T2 i e1ecuţia tranziţiei TA i, acesteia din urmă,e1ecuţia tranziţiei TAA#

3.3.#. Reţele Petri 'e c"p"cit"te

O RP de capacitate este o RP !n care poziţiilor le sunt asociate

numere naturale numite capacităţi#

>1ecuţia unei tranziţii de intrare !ntr-o poziţie P i, c%nd capacitatea

acesteia este 1ecuţia

tranziţiei T duce la marca/ul din figura '#C#c# &n această fază nu se poate

e1ecuta T, c"iar dacă !n P e1istă o marcă, pentru că poziţia P2 a atins

capacitatea ma1imă#

Proprietate:

Toate RP de capacitate pot fi transformate !n RP ordinare.

Transformarea este simplă, fiind ilustrată !n figurile '#C# d, e, f# B-a

adăugat o poziţie complementară la P2, aceasta este poziţia P2A, al cărei

marca/ este complementar capacităţii poziţiei P2#

$dică:

9 ( P2A )


73/125

Capitolul 3.

6ig#'#C# RP de capacitate

$stfel dacă: 9 ( P2 )


74/125

Capitolul 3.

3.+. Reţele Petri 'epen'ente ,ne"%tono-e

Reţelele Petri dependente (neautonome) pot fi sincronizate i8sautemporizate. &n cazul RP sincronizate fiecărei tranziţii i se asociază un

eveniment, e1ecuţia tranziţiei urm%nd să ai7ă loc dacă tranziţia respectivă

este validată i dacă evenimentul asociat s-a produs# RP temporizate permit

modelarea unui sistem a cărui funcţionare depinde de timp#


75/125

Capitolul 3.

• R este o RP marcată;

• Tempo este o aplicaţie pe mulţimea P, a poziţiilor, !n mulţimea

numerelor raţionale pozitive sau nule, astfel !nc%t:

Tempo (Pi) di ('#2)

unde di este temporizarea asociată poziţiei Pi#

Principiul de &uncţionare

acă o marcă este depusă !ntr-o poziţie Pi, această marcă va răm%ne

!n poziţia Pi pe durata di, marca fiind indisponibilă pe această durată# upăce di s-a scurs, marca devine disponibilă.

isponi7ilitatea 8 indisponi7ilitatea unei mărci este descrisă !n figura

'## &n momentul iniţial marca/ul 9 este constituit din mărcile disponi7ile#

=a momentul t, marca/ul 9 este suma a două tipuri de mărci:

• 9d - marca/ul disponi7il;

• 9i - marca/ul indisponi7il#

eci:9 9d G 9 / ('#')

O tranziţie este validată pentru marca/ul 9, dacă este validată pentru

marca/ul 9d#

acă o marcă este depusă !ntr-o poziţie Pi, !n urma unei tranziţii

e1ecutate la momentul t, atunci această marcă este indisponi7ilă !n

intervalul (t, t G di)#

>voluţia unei reţele Petri P- temporizate este prezentată !n figura

'##

74


76/125

Capitolul 3.

6ig#'## Reţele Petri P- temporizate# Principiul de funcţionare

&n varianta a este prezentată evoluţia reţelei !n cazul general, c%nd 1,

H F , unde 1 i H sunt intervalele de timp care sunt cuprinse !ntre momentul

!n care tranziţiile T2, respectiv T, devin e1ecuta7ile (validate) i momentul

!n care mărcile devin indisponi7ile !n poziţiile P, respectiv P2# !n aceastăsituaţie reţeaua funcţionează cu viteză proprie.

75


77/125

Capitolul 3.

&n varianta 7 este prezentat cazul !n care 1 H , caz care corespunde unei

funcţionări cu viteză maximă a reţelei#

6ig#'#. >voluţia unei reţele Petri P- temporizate

Iraful marca/elor, corespunzător unei funcţionări cu viteză ma1imă,

este:

&n continuarea se va trata un e1emplu de sistem de fa7ricaţie modelat

cu a/utorul RP T- temporizată# Be consideră un sistem de fa7ricaţie compus

din mainile de lucru 9= i 9=2# 9ainile sunt deservite de două palete,

fiecare purt%nd c%te o piesă# Piesele trec succesiv la mainile 9= i 9=2

(6ig#'#2)#

76


78/125

Capitolul 3.

6ig#'#2# Bistem de fa7ricaţie

9aina 9= poate prelucra o piesă i timpul de serviciu este 2

Junităţi de timpK#

9aina 9=2 poate prelucra simultan două piese i timpul de serviciu

pentru o piesă este 2 ' Junităţi de timpK#

9odelarea sistemului cu a/utorul unei RP P- temporizate va tre7ui să

ţină seama de următoarele aspecte:

• 9aina 9=2 prelucr%nd două piese simultan, rezultă că !n BT2 nu vor

fi niciodată piese, deci nu este nevoie să se asocieze stocului BT 2 o

poziţie;• Be vor defini poziţii pentru:

P - piesele din BT;

P2 - piesa de pe 9=;

P2A - poziţie care indică faptul că maina 9= este ocupată cu

o singură piesă: 9(P2) G 9 (PA2)

P' - piesele de pe maina 9=2#

• Temporizările d2 2 i d' 2 ' sunt asociate poziţiilor P2,respectiv P'#


79/125

Capitolul 3.

9odelul sistemului este prezentat !n figura '#':

6ig#'#'# 9odel cu RP P- temporizată

Iraful marca/elor asociat modelului cu reţea Petri P-Temporizată este:

Pentru marca/ul iniţial 9, T este e1ecuta7ilă o singură dată# Be

atinge marca/ul 9# upă două unităţi de timp, mai t%rziu, se e1ecută T2 ide asemenea T redevine validată#

78


80/125

Capitolul 3.

Be atinge marca/ul 92# upă !ncă două unităţi de timp, T2 este din

nou e1ecuta7ilă# Be atinge 9'#

upă o unitate de timp prima marcă sosete !n P, T este imediate1ecutată, se atinge 94# ouă unităţi de timp, mai t%rziu, T2 i T' devin

simultan validate# Be e1ecută !ntr-o ordine oarecare, apoi T este imediat

e1ecuta7ilă#

urata ciclului: 9 → 9' → 94 → 92, este de + unităţi de timp#

3.+.1.#. Reţele Petri T/ te-poriz"te

%e&iniţie:

O reţea Petri ' temporizată este un du7let de forma ER, 'empo, unde:

• R este o reţea Petri marcată;

• 'empo este o aplicaţie a mulţimii tranziţiilor T !n mulţimea

numerelor raţionale sau nule, definită prin relaţia:

Tempo (/) / ('#4)

unde / este temporizarea asociată tranziţiei /#

.n cazul RP T- temporizate, o marcă poate fi !ntr-unui din

următoarele două stadii:

• rezervată pentru e1ecuţia tranziţiei /;

• nerezervată.

$ceste ipostaze ale unei mărci sunt ilustrate !n figura '#4#

79


81/125

Capitolul 3.

upă ce tranziţia T a fost e1ecutată, un marca/ a fost depus !n poziţia P #

in acel moment tranziţia T2 este validată, e1ecuţia acesteia put%nd !ncepe

oric%nd# Odată !ncepută e1ecuţia tranziţiei T2, marca nece

Date post:	05-Jul-2018
Category:	Documents
Upload:	florij
View:	237 times
Download:	3 times

Curs Sist Aut Fabricatie

Documents