UNIVERSITATEA TEHNICĂ GHEORGHE ASACHI DIN IAŞI FACULTATEA DE ELECTRONICĂ, TELECOMUNICAŢII ŞI TEHNOLOGIA INFORMAŢIEI

Transcription

1 UNIVERSITATEA TEHNICĂ GHEORGHE ASACHI DIN IAŞI FACULTATEA DE ELECTRONICĂ, TELECOMUNICAŢII ŞI TEHNOLOGIA INFORMAŢIEI

2 PROIECT DE DISERTAŢIE CONDUCĂTOR, CONFERENŢIAR DOCTOR INGINER, Luminiţa Scripcariu MASTERAND, Lungu Alexandru

3 Sistem de monitorizare şi stocare a parametrilor industriali 3

4 Sistem de monitorizare şi stocare a parametrilor industriali Cuprins I. Introducere 2 II. Modelare generală a soluției.. 4 III. Interfața electronică de intrare. 7 IV. Componeta software A. Mediul Reliance SCADA/HMI 10 B. Scripturile în Visual Basic C. Baza de date (Microsoft SQL Server) 19 V. Ieșirile din sistem A. Raportarea B. Semnalizarea audio/video VI. Concluzii VII. Bibliografie VIII. Anexe A. Cod Reliance B. Cod copie de siguranţă baza de date/sql

5 I. Introducere Modelarea realitații prin prisma electronicii şi a implementarilor software, reprezintă o soluţie tot mai puternică şi mai cautată, reprezentâd raspunsul la multe probleme complexe din mediul public sau privat. Mediile industriale necesită automatizări și sisteme de monitorizare tot mai performate odată cu cresterea cerintelor de calitate şi nevoie de scadere a costurilor de producție. Standardele ISO din mediul industrial auto şi nu numai impun restricții drastice privind monitorizarea proceselor și a parametrilor din producție şi salvarea pe termen lung a acestora. Pentru asigurarea trasabilitații și a istoricului, firmele sunt nevoite să stocheze informațiile pentru o perioada tot mai mare, uneori chiar ani. De cele mai multe ori, fluxul tot mai mare de informație necesită atât spații de stocare, cât și o forma eficientă de codare a informației. Bazele de date sunt o soluție fiabila de stocare/manipulare a datelor, dar acestea din urmă trebuie să fie structurate intro formă normalizată pentru a asigura atomicitatea şi consistența tabelelor stocate, astfel obtinându-se optimizarea dorita asupra spatiului de stocare, dar şi a timpului de executie al interogarii informației. Motorul bazei de date poate fi accesat prin rețea de catre roboții industriali, putându-se astfel face o interconectare şi un schimb de informații între diferite dispozitive (PLC-uri, periferice, etc). Se pot realiza diferite sincronizari între procesele 5

6 din fabrici, fiind posibilă implementarea de sisteme tip SAP pentru monitorizarea traficului de produse ce intră sau ies din diferite departamente, lucru necesar uneori pentru a avea un control/viziune generală asupra fluxului produselor/componentelor. Anumite materii prime/piese pot fi comandate automat cu ajutorul unei interfețe ce se conectează la baza de date. Toate datele parametrilor stocați (care reprezintă şi dovada respectarii specificațiilor clientului) sunt ulterior folosite pentru a genera diferite rapoarte și statistici ce fac subiectul unor analize ulterioare necesare pentru controlul sau îmbunătăţirea proceselor. Aceste rapoarte pot fi folosite şi la etichetare loturilor prin conversia informaţiei în cod de bare sau matrice de date (DataMatrix) dar și ca facturi sau ca elemente ajutătoare în cazul unor reclamații de la clienți cu privire la calitatea produselor livrate. Solutiile tip SCADA /HMI(Supervisory Control and Data Acquisition/Human Machine Interface) reprezintă implementari pentru controlul mediului industrial şi oferă o interfață prietenoasă între masină şi operator. Aceste sisteme sunt tot mai poplulare şi vin cu oferte tot mai diversificate pentru industrie. 6

7 II. Modelare generală a soluției Fluxul logic este structurat în trei parți :intrările, funcția de transfer și ieşirile. Schema generica este ilustrată în figura următoare: 7

8 Fig 2.1 Schema generică a soluţiei Intrarea reprezintă o interfață electronică ce face achiziția și conversia în format digital a datelor provenite de la senzori. Legatura este facută prin protocolul de comunicaţie specificat în aplicația Reliance. Funcţia de transfer este reprezentată de componenta software ce modeleaza procesele conform specificatiilor pentru obținerea funcţiei dorite. În componență se află softul Reliance, scripturile în Visual Basic, baza de date și modulul de raportare. Reliance SCADA/HMI reprezintă mediul IDE (Fig 2.2) ce construiește interfața grafică, care prin intermediul codului în VB (Visual Basic) din fundal monitorizează procesele industriale. Fluxul parametrilor, procesarea/conversia, salvarea acestora în baza de date alături de trimiterea unor valori spre componenta de raportare este guvernat de subrutinele și functiile construite în VB. Fig 2.2 Aplicaţia modelată în mediul SCADA/HMI în runtime Baza de date este dimensionată dupa specificațiile clientului, modelarea ei începe cu stabilirea tabelelor care trebuie să respecte minim cele trei reguli de normalizare a datelor iar ultimul pas este alegerea unui motor pentru DBMS (Data Base Management System) și o formă de licențiere. Ieșirile sunt reprezentate prin diferite moduri de semnalizare (vizual/auditiv), fiind comandate cu ajutorul unor module de ieșire (digitale 8

9 în cazul de faţă) conectate la sirene sau indicatori luminoși. Astfel se poate semnaliza diferite abateri ale proceselor de la valorile nominale, depasirea toleranțelor sau funcţionari defectuase ale sistemului. Rapoartele pot fi generate automat sau la comandă. Utilizatorul introduce datele ce reprezintă identificarile parametrilor din proces, după care programul va trunchia din baza de date informaţia necesară şi o va reprezenta tabelat sau grafic ( în cazul în care se doreste vizualizarea evoluției parametrilor specifici unei perioade de timp). Programul Reliance va afișa și în timp real evoluția parametrilor pentru situațiile ce impun acest lucru (un operator poate monitoriza și evalua situația parametrilor). Suita software respectă ciclul de viață al unui soft, pașii fiind ilustrați în figura 2.3. Testarea se face atât automat (prin scripturi) cât și manual, prin intermediul unor meniuri de test în care se pot simula conditiile din fabrică. Clientul vine cu cerintele sale (ce sunt mai mult sau mai putin concrete), echipa de specialiști vor genera niste specificații. Acestea sunt modelate matematic/logic şi rezultă o schiță sau blueprint. Programatorii creează codul ce să indeplinească specificatiile, după care urmează testarea softului. Aceasta se face prin rularea lui în condiții cat mai apropiate de mediul unde va fi rulat, se vor face teste de anduranță și de acceptanță, dupa care aplicația poate intra în producție. Ultima etapă este reprezentată de mentenanța softului care aduce mici ajustari care să crească productivitatea aplicației. Fig 2.3 Ciclul de viață al unui program software 9

10 III. Interfața electronică de intrare Modulele de achiziție date sunt soluții accesibile dar trebuie dimensionate corespunzator arhitecturii şi design-ului fiecărei soluții. Aplicația din această lucrare foloseste grupuri de module de achiziţie date cu o rezoluție de 15 biți (Fig 3.1) ce suportă pana la 8 senzori analogici ca intrare iar ieşirea digitală comunică prin protocol de comunicație modbus cu o interfată RS 485. Modulele sunt programate să comunice pe o anumită viteză (38400 bd), fără paritate și li se va seta și o adresă după care vor fi identificate mai apoi (se poate folosi softul producătorului sau prin setarea unor switchuri de pe modul). Modulele sunt conectate pe aceeași magistrală la convertorul 485 iar softul Reliance le va interoga pe fiecare după adresa setată inițial. Folosind un convertor RS 485 RS 232 ne putem conecta la portul serial al oricarui calculator. 10

11 Fig 3.1 Modulul pentru intrari analogice Senzorii de la intrare reprezentați de termocuple industriale ce vor converti temperatura din mediul industrial, în cazul de față fiind vorba despre monitorizarea unor cuptoare de tratament termic dotate fiecare cu 6 senzori de temperatură. Senzorii sunt pasivi şi se interconectează la modulul corespunzător. Figura 3.2 ilustrează configurarea canalului de comunicație și a portului COM atribuit de Windows la conectarea prin portul serial (în cazul de față COM1). Fig 3.2 Setari port/ adresa de comunicare Fiecare modul ce comunica prin modbus are atribuite la randul său taguri care aduc informația din registrii plăcilor de achiziţie. Aici senzorului bol1 (codificat dupa senzorul boltă de pe cuptorul cu numărul 1) i se citește valoarea din registrul cu numarul 5, poziție stabilită în funcție de conectarea senzorului în socket-ul modulului. Variabila în care se stochează valoarea are un tip definit de utilizator, în cazul de față, Word pe 16 biti (se poat selecta diferite tipuri de date, ce se regăsesc în majoritatea mediilor de programare). Unitatea de masură este lăsata liberă, urmând ca prin intermediul scripturilor, valoarea citită să fie procesată corespunzător. În figura 3.3 se observă cei șase senzori corespunzători modulului denumit modbus 10 (ce are adresa 10 pentru o localizare mai usoară). După cum se poate observa în imagine programului i se permite 11

12 doar să citească date de la acea adresă, nefiind necesară scrierea de informații din soft la acea adresă. Pentru iesirile digitale, perminiunea de scriere este bifată. Datele urmează să fie salvate în variabile globale de sistem după ce în prealabil a fost aplicată o corecţie. Fig 3.3 Setari asupra informațiilor citite din regiștrii modulelor 12

13 IV. Componeta software A. Mediul Reliance SCADA/HMI Mediul IDE reprezentat de Reliance oferă tansparență pentru programator, oferindu-i libertate în manipularea datelor. Variabilele declarate în aplicație se numesc taguri, sunt globale ca domeniu de existență fiind accesibile în toate elementele grafice. Acele variabile ce ce provin din regiștrii modulelor de comunicație sunt grupate separat față de cele definite de utilizator. Acesta controlează tipul lungimea lor (dacă este cazul), putându-se în același să se seteze manual o valoare inițială și eventual o formulă de corecție a informației citită dintr-un dispozitiv extern (aceste propietăti pot fi implementate dinamic cu ajutorul codurilor în VB). Programul oferă un set predefinit de forme grafice ce pot modifica valorile tagurilor asociate. Formele grafice conțin casete de dialog, vectori, grafice dinamice, zone pentru afisarea valorilor diferitelor taguri. Reliance manipulează datele în limita opțiunilor disponibile iar pentru a obține un control mai mare şi o formă de abstractizare superioară a datelor se folosesc scripturile în VB, acestea din urmă pot fi atașate formelor și sunt executate de evenimente (triggers), ex: click rile din diferite zone grafice sau pe un buton.figura ilustrează configurarea unui trigger de tip Click stanga ce are ca event-handler un cod VB (Visual Basic). Fig Asignarea scripturilor VB formelor grafice Formele grafice au propietați sau atribute ce pot fi atribuite unor taguri. Modificarea dinamică a unor atributelor poate fi implementată prin alterarea tagurilor de catre un dispozitiv extern, o logica interna a programului sau de scripturile VB. Figura ilustrează posibilitatea setarii atributelor visible (pentru vizibilitate în forma grafica) sau enabled (pentru validarea posibilitații de modificare a valorii) 13

14 Fig Setarea atributelor formelor grafice La pornirea aplicației în runtime, componentele sunt compilate şi toate mesajele de eroare vor fi semnalizate utilizatorului. Reliance are componentă specială de alarmare, triggger-ul acestora fiind reprezentat de diferite modificari alea unor taguri. Evenimentele generate de alarme se stochează într-o mini bază de date separată iar utilizatorul poate fi informat de diferitele modificari în comportamentul aplicației prin mesaje tip SMS (dacă se instalează un modul specific) sau pe . Adresa și coordonatele serverului de mail (setarile SMTP) se configurează din menul general. Aplicația foloseste o logică comandată de codul VB pentru activarea alarmelor audio/video, sectiune tratata în capitolul V. Aplicatia foloseste forme ce afișează valori în timp real de la senzori, acestea putând fi plotate automat pe un grafic. Pentru o imagine de ansamblu se poate folosi meniul tip histogramă care citeste şi plotează un time frame selectat de utilizator. Acest meniu suportă procesari dinamice ale graficelor (zoom, cursor). Pentru raportarea statica se folosește un sablon de raportare custom ce se generează în funcție de datele introduse de utilizator, sectiune tratată în capitolul V. Cadrul general de stocare a formelor grafice este reprezentat de ferestrele tip window, în cadrul acestora se poziționează elementele grafice. Pentru cazurile când este nevoie de a avea acelaşi grupuri de elemente în mai multe ferestre, pentru eliminarea redundanței se folosește forma de abstractizare tip container, în care se poate încapsula informația dorită. Pentru inițializarea tagurilor și a altor parametrii se utilizează secțiune tip rețetă. Încărcarea rețetei la inițializarea aplicației se face prin automatizarea acesteia utilizând un script în VB. Reliance are implementat politici de securitate ce pot fi atribuite utilizatorilor. Acestia se loghează și în funcție de privilegiile ce le deține iși poate exercita drepturile. Aplicația poate rula și de la distanță folosind ca client brownser-ul oricărui calculator sau dispozitiv tip smartphone conectat la internet. 14

15 B. Scripturile în Visual Basic Aplicația se bazează foarte mult ce scripturile în VB ce rulează în fundal. Partea de scripting se bazează pe taguri, funcții specifice mediului IDE, limbajul Visual Basic, alături de posibilitatea de a apela diferite metode API ale Windows-ului. Cu aceste resurse se pot modela procesele necesare îndeplinirii specificațiilor proiectului. Mediul Reliance suportă şase tipuri de scripturi : Time Event Key Data Change Condition Periodic Acestea caracterizează comportamentul scriptului, el putand fi activat: la o anumita dată/oră, fie generic (tip envent, fiind activat de un trigger din interfata grafica, ex: click pe un buton),sau să se activeze la apasarea unei taste/combinație de taste, starea unui tag poate activa un cod (prin comparație cu o constantă sau cu alt tag, ex: =0 ). Ultimul tip, cel periodic poate avea o frecvență de repetiție și poate fi folosit pentru execuția ciclică a codului. Nivelul de încapsulare al datelor este dat de structuri ca funcţiile şi subrutinele. Parcurgerea codurilor se face secvențial ceea ce poate introduce întârzieri în procesare (eventuale bucle, temporizări sau execuții lente ale unor coduri pot ține pe loc alte subrutine ). Soluția este reprezentată de posibilitatea de a avea fire multiple de executie (multi-threading fig 4.2.1), astfel se obține un acces concurent și o fideliate mai mare a codurilor ce rulează, utilizând resursele procesorul într-un mod mai eficient. Sincronizarea între thread-uri este transparentă faţă de programator, totul fiind executat în fundalul programului, fără a fi nevoie de alte intervenţii. Pentru un singur procesor rularea tip multi thread se obține printr-o multiplexare în timp. Astfel thread-urile (ale aceluiasi proces) se execută la timpi diferiți printr-o multiplexare în timp. Frecvența procesorului fiind mare utilizatorul percepe totul ca un multitasking (ex: ca și cum toate programele ar rula în același timp). Pentru procesoarele multi-core thread-urile pot rula separat. Sistemele de operare moderne pot îmbina aceste tehnici pentru a obține o programare paralelă și un acces concurent. Aplicația 15

16 de față beneficiază de aceste avantaje și modelarea soluției împarte codurile într-o ierarhie de execuție. Codurile ce au nevoie de timpi de execuție mici pe un thread, celelalte pe alte threduri. Prioritizarea threadului cu execuție rapida aduce beneficii în comportamentul softului în runtime. Fig Conceptul multi-threading Ierarhia thread-urilor este următoarea (în funcție de prioritate, numerele mai mici executându-se primele): Threadul 1 - Recepția și aplicarea corecției pe datele de la senzori + scripturile de bază Thread-ul 2 - Ieşirea digitală pentru hupă ce semnalizează depăsirea gradientului de temperatură critică Thread-ul 3 La oprirea tratamentului variabilele globale din reliance (specifice fiecarui cuptor) sunt resetați şi se pregatesc pentru un nou proces plus scrierea valorii zero în BD Thread-ul 4 Salvarea parametrilor de pe fiecare cuptor se face periodic (specificaţia impune 2 minute) și doar când acesta rulează un tratament Scripturile constau în subrutine şi funcții, amandouă putând fi apelate cu parametrii, diferența dintre cele două este dată de propietatea celei din urmă de a returna o valoare. Codurile au fost imparțite în doua categorii (pentru a fi conforme cu realitatea şi cu sistemul Reliance): Cele care definesc o subrutină ce acceptă parametrii şi sunt de tip event (cu propietatea run on thred initialization bifată) Cele care apelează subrutina definită în alt script, sunt de tip periodic 16

17 Prin apelarea periodică a subrutinelor de definiție dar cu alți parametri, am reuşit să simulez realitatea și pe acest proces se bazează logica și funcționarea aplicației. Codurile ce se afla sub incidența unui fir de execuţie (thread), trebuie să aibă setat acel fir de execuţie ( thread) atât în codul de definiție cât şi în codul ce face apelul. O abstractizare utilă asupra codului este reprezentată de folosirea parametrilor în execuţia evenimentelor (triggers,events). Astfel în loc să avem câte un cod separat pentru elemente asemanatoare dar multiple (ex: şiruri de ferestre de dialog, aceleaşi pentru mai multe pagini, acelasi buton pe pagini multiple, meniuri comune), m- am folosit de paramentrul transmis implicit (fig 4.2.2) diferit pentru fiecare element, dar acelasi cod. Acesta poate fi privit ca un proces ce se tratează acel eveniment (event-handler). Utilizand structuri pentru decizie logica tip dacă-atunci (if-then), sau cazuri (instrucţiunea select case pentru VB este echivalentul switch din C) putem avea un singur cod şi în funcţie de paramentrul Data.IntPar1 putem lua o decizie de unde provine acel eveniment. Scriptul este astfel optimizat şi programatorul poate urmari mai uşor liniile de cod putând să evite eventualele greşeli de sintaxă (în cazul scripturilor multiple). Fig Conceptul multi-threading Aplicaţia contine peste 2000 de taguri şi multe dintre acestea necesită o iniţializare-setare atunci când aplicaţia este pornită, astfel apare nevoia salvarii valorilor tagurilor şi a reiniţializării la repornirea softului (utilizatorul poate să greşească reintroducerea valorilor sau operaţiunea să dureze prea mult ). Reliance oferă suport pentru a reţine valorile din taguri într-o listă tip reţetă 17

18 (receipt) pe hard-disk. Pentru a automatiza acest proces, am setat propietăţile reţetei ( i se aloca un prefix şi o variabilă ce să valideze auto iniţializarea listei). Figura ilustrează setarile necesare. Tot ceea ce rămâne utilizatorului este să îşi seteze tagurile, dupa care va salva lista cu denumirea de config2. Scriptul VB va seta numele listei şi în urma validării tagului specific reţetei valorile tagurilor vor fi restaurate la fiecare instanţă de runtime. O raportare temporară şi dinamică este reprezentată de histograma Reliance, ce permite urmărirea în timp a valorilor şi plasarea unui cursor. Fiecare tratament termic este unic identificat printr-un id. Acest tag este de tip string (datorită specificaţiilor ce precizează necesitatea folosirii caracterelor numerice în formatul XXXX.XXX în baza de date ) şi interfaţa histogramei nu stie să ploteze pe axa Y ( Y= axa valorilor temperaturilor, X= axa timpului) aceste date. Soluţia a fost să trunchez acel string separat prin punct şi să îl regrupez într-un tag de tip float (fig 4.2.2). Am folosit funcţia split din VB, ce acceptă variabilă string, caracterul ce delimitează (aici punctul), constantele -1 pentru a returna toate substringurile şi parametrul 1 pentru a face o comparaţie tip text în cadrul procesului de analiză. Funcţia returnează un vector alcătuit de substringurile ce sunt delimitate de caracterul specificat. Am implementat o concatenare a valorilor vectorului şi scrierea acestuia într-un tag tip float (reliance va face automat conversia din string în float, ceea ce va face posibila afişarea lui în gafic). O altă utilizare frecventă a acestei funcţii este legata de decodarea fisierelor tip CSV (comma separated values= valori separate prin virgulă). Acestea stochează deseori valori provenite de la diverse dispozitive şi sunt utile datorită usurinţei de a fi decodate interpretate în softuri sau alte arhitecturi hardware. Fig Histograma pentru urmarirea dinamică a valorilor din baza de date 18

19 Toate softurile au probleme la rulare/compilare, un utilitar pentru depanare/urmarire a proceselor din spatele softului este de mare folos. Reliance suportă afişarea erorilorin meniul propriu de alarme, dar informaţia este insuficientă (mai ales în lucrul cu fire multiple de execuţie). Pentru depanare-monitorizare avansată am folosit componenta Debugging din mediul IDE Microsoft Visual Studio 6 (Fig 4.2.3). Activarea se face implicit la apariţia unei erori în Reliance, sau explicit în cod prin cuvantul rezervat Stop. În depanator se pot urmari valorile/evoluţia variabilelor/funcţiilor chiar pe firul de execuţie pe care rulează. Acest utilitar este indispensabil pentru codurile ce conţin fire multiple de execuţie. Fig Depanarea softului utilizând mediul IDE Microsoft Visual Studio 6 Pentru a evita greşeleile de sintaxă, Reliance oferă suport pentru autocompletarea metodelor/atributelor pentru obiectele proprii (ex: asemănator sistemului IntelliSense din Visual C++ v.6). Valorile recepționate prin modbus sunt salvate în taguri ale sistemului. Acestea suferă în prealabil un proces de corecție pentru scalare la domeniul dorit. În figura se ilustrează meniul de setare a parametrilor senzorilor și formula dupa care funcționează algoritmul de corecție. Aplicația se adresează unei fabrici ce tratează termic anumite componente pentru industria auto. Sunt monitorizate 20 de cuptoare ce au cate 5+1 senzori (tip termocupla). Un senzor este de rezervă şi poate fi activat din meniul de configurare al fiecărui cuptor. Când acesta este dezactivat, sistemul îi va atribui aceeaşi valoare ca penulimul senzor, adică spate 19

20 stanga. Utilizatorul are afișat pe meniul principal schematizat toare temperaturile din fabrică. Imaginea de fundal pentru fiecare cuptor se modifica dinamic, în funcție de indeplinirea condițiilor din specificații. Prin selectarea oricărui cuptor se accesează meniul principal al acestuia. Aici se poate introduce id-ul unic ce va identifica șarja, numele operatorului de pe schimb, se va seta durara/tipul tratamentului, termic, se vor introduce reperele pieselor și cantitatea acestora. Apoi pentru pasul următor este afișată o fereastră preliminară ce oferă utilizatorului posibilitatea să verifice pentru ultima dată corectitudinea datele introduse (în caz contrar el poate reveni la meniul anterior pentru a face corecțiile necesare). Fig Meniul pentru configurarea individuala a senzorului și a corecției După apasarea butonului de start, toate scripturile de monitorizare ale alertelor se activează iar baza de date incepe să stocheze valorile senzorilor. Aceştia au aplicată corecţia plus eroarea tolerată, esantionarea pentru salvarea valorilor facânduse la doua minute din clipa în care se atinge palierul. Senzorii comandă stânga (CS) şi comandă dreapta (CD) sunt prioritari în activarea alertelor sau în schimbarea culorii cupoarelor (fig 4.2.5) din pagina principală. Tot aceşti doi senzori vor seta flag-urile de enable pentru palier. Acesta este foarte importand deoarece el este componenta de referinţă pentru multe coduri şi se atinge când oricare dintre cei doi senzori CS sau CD ating temperatura specifică tratamentului care rulează (setată de utilizator 20

21 în pagina cuptorului). Odată setat, acest flag îşî păstreaza starea pană când utilizatorul opreşte tratamentul. Fig Culoarea cuptorului indica un status general al acestuia Culoarea cuptorului este interpretată de Reliance în funcţie de valoarea ce o are tagul denumit sugestiv culoare (fieacare cuptor are un asfel de tag) în sistem. Nuanţa de albastru este valoarea cu care se iniţializează variabila de tip integer (valoarea 0), culoarea albă (valoarea 1) indică un tratament pornit dar cu temperaturile pe senzorii CS sau CD neajunse în palier, cea verde (valoarea 3) simbolizează comportamentul nominal cu temperaturi ok. Culoarea galbenă (valoarea 4) anunţă terminarea tratamentului şi posibilitatea de a finaliza procesul ce rulează. Oricare cuptor pe rosu va activa alarmele vizuale, girofarul şî hupa (sirena), toate fiind conectate la ieşirile digitale. Codul pentru alarmele vizuale sunt pe firul 1 de execuţie, hupa de afla pe firul 2 de execuţie deoarece ea trebuie să ruleze pentru 3 secunde ceea ce introduce o întârziere în toate scripturile ce se afla pe acel thread. 21

22 Temporizarea este implementată cu ajutorul funcţiei timer din VB (ce returnează numărul de secunde scurse de la miezul nopţii) şi a unei bucle tip ciclu cu test final ( Do While ). Fig Culoarea cuptorului indică un status general al acestuia Legătura dintre firele de execuţie este realizată de variabilele globale ale sistemului. După introducerea datelor, validarea lor şi pornirea tratamentului (apasarea butonului start). Procesele ce au loc apoi sunt urmatoarele : Butonul de start activează o metodă ce setează true tagul scrie cx, acesta validează (Fig a.) salvarea în tabelul CX(ex cuptorul 1 are C1). Informaţiile stocate sunt coordonatele tratamentului, mai puţin reperele şi numarul de piese, după care sistemul Reliance ce administrează fluxul cu baza de date va restea acet flag (Fig b.). Se face apelarea funcţiei repere ce are ca argumente reperele introduse şi alti parametrii. Scriptul va verifica dacă campurile cu repere sunt completate şi va introduce datele în tabelul total alături de id-ul unic de identifică tratamentul. Urmează resetarea flagului ce blocheză salvarea datelor de la senzori. (Fig c.). Acest flag va indica prezenţa unui tratament pe un cuptor şi va permite execuţia subrutinelor ce intoduc în tebele datele senzorilor o dată la 2 minute. 22

23 Fig Pornirea procesului În meniul principal se ilustrează un status general al tuturor cuptarelor. Cele care rulează tratamente au indicat momentul atingerii palierului şi numarul de secunde scurs de la începerea tratamentului (Fig 4.2.8). Codul culoare ce se execută periodic (la 1 secundă), incrementează o variabilă globală (distinctă pentru fiecare cuptor), aceasta avînd mereu timpul scurs de la schimbarea flag-ului ce indică atingerea palierului. Data şi ora intrării în palier sunt setate de codul crono, folosind funcţia Now din VB (ce returnează data şi ora sistemului). Rezultatul l- am salvat într-o variabilă Reliance tip DateTime şi afişată ca în figură. Fig Cronometru pentru evoluţia tratamentului 23

24 O implementare nouă este scriptul finish_treatment, acesta fiind activat la terminarea timpului de tratament şi care salvează reperele şi anumite coordonate intr-un tabel separat, de unde mai târziu se vor genera rapoarte ce vor afişa piesele care au fost finalizate (exceptând cele în curs), lucru necesar administraţiei sau departamentului financiar al fabricii pentru a-şi crea o statistică despre fluxul de piese. La oprirea tratamentului utilizatorul este întrebat dacă este sigur că vrea să oprească procesul. Am implementat acest lucru folosind funcţia MsgBox şi am verificat ce returnează aceasta, în funcţie de opţiunea operatorului. Această posibilitate de prelungire a tratamentului satisface specificaţia proiectului. Procesul de oprire a tratamentului are două componente (aflate pe firul 2 de execuţie): Scriptul opreşte care va iniţializa scrierea unei lini cu zero în BD (baza de date), procedeu necesar pentru a afişa corespunzător în histograma evoluţia temperaturilor. Urmează resetarea tag-urilor din prima parte a meniului exceptand reperele, justificarea fiind numarul prea mare de argumente suportate de subrutină Scriptul reset ce resetează tag-urile reperelor şi activează starea flagului (în true) ce blochează salvarea în BD. Modul în care principalele scripturi depind unul de celalalt este ilustrat în fig Anumite taguri fac legătura între subrutine, făcând ca totul să se comporte ca un sistem. Fig Imaginea de ansamblu a scripturilor mai importante şi dependenţele dintre acestea 24

25 Orice script sau logică implementată într-un limbaj de programare mai trebuie şi validată. Prima verificare este de ordin sintactic şi este facută de catre compilatorul intern al Reliance, urmată fiind de către debuggger-ul Microsoft (Visual Studio 6). Pentru a identifica funcţionarea corectă în mod runtime, am creat meniuri (ascunse utilizatorului final) prin care pot testa comportamentul aplicaţiei. Caracterul ascuns al acestor meniuri are ca scop protejarea utilizatorului. Dacă acesta accesează accidental aceste zone poate induce aplicaţia în zone de funcţionare defectuasă sau în alterarea valorilor unor taguri ce să genereze erori. Orice implementare, înainte de a ajunge la client trebuie să treacă testele de acceptanţă şi cele de asigurarea calităţii (Quality assurance) în care se verifică dacă sistemul îndeplineşte cerinţele clientului. Respectând practicile standard de quality assurance, am creat un modul de testare manuală, altul pentru testare automată şi un buton de audit pentru funcţionarea ieşirilor. Auditul/testarea aplicaţiei am facut-o prin intermediul a trei interfeţe: Pentru testarea manuală am implementat o fereastra de test în mediul Reliance prin care se ajunge apăsând combinaţia de taste: Ctrl+Alt+Del. De aici se poate simula pornirea unui tratament şi funcţionarea sistemului de validare a datelor introduse. Aplicaţia are implementate sisteme anti-greşeală în mai multe etape din fluxul programului. (se foloseste programarea defensivă) Pentru testarea automată folosesc un script ce se se activează apăsând tasta F6, care după introducerea parolei va activa automat procese din spatele aplicaţiei. Auditul din partea utilizatorului îi permite acestuia să testeze integritatea sistemului de alarme audio/video. Pentru aceasta trebuie să acceseze butonul din pagina principala care trimite la ieşirile digitale un semnal de unu logic. Hupa este acţionată doar pentru doua secunde (zgomotul este foarte puternic), iar lămpile martor/ girofarul vor sta aprinse încontinuu cat butonul este activat. Astfel utilizatorul poate verifica dacă sistemul funcţionează. C. Database (Microsoft SQL Server) Reliance are componentă proprie de administrare a transferului de date între aplicaţie şi instanţa BD (bazei de date). Totuşi, programatorul trebuie să dimensioneze corespunzător informaţia în tabele, pentru a optimiza funcţionarea aplicaţiei şi a spaţiului de pe disc (dimensiunea BD poate atinge valori foarte mari). O bază de date se compune din tabele, acestea 25

26 conţin coloane( atribute, field ). Intersecţia coloanelor caracterizează un element, această linie/înregistrare reprezintă un record sau row aşa cum este întânit în literatura de specialitate.o implementare gresită poate duce la ingreunarea programului, a graficelor, a timpului de generare a rapoartelor şi în ultima instanţă poate bloca sistemul de operare. Astfel, în funcţie de specificaţii, de ciclul de arhivare/stergere, volumul de informaţie stocat, se pot lua decizii asupra structurii BD. Normalizarea unei baze de date elimină riscul redundantei şi oferă o structură optimă pentru valorile salvate în tabele. Din exterior procedura arată ca şi cum baza de date ar fi descompusă în cât mai multe tabele. La o privire mai atentă, fiecare dintre aceste tabele se supun urmatoarelor trei reguli de normalizare: Principiul atomicităţii şi al cheii primare nu există duplicate sau grupuri de linii redundante; sunt stabilite chei primare unice şi nu acceptă nuluri şi identifică înregistrările. Făra dependenţe parţiale faţă de cheia primară Fără dependenţe între atributele non-cheie şi alte atribute non-cheie. Integritatea datelor poate fi constânsă cu o cheie straină, opţiune la care nu a fost nevoie să apelez momentan la acest proiect. Fig ilustrează structura bazei de date normalizată, rezultatul este reprezentat de 42 de tabele. Fiecare cuptor are un tabel Cx (x este numarul cuptorului) care stochează informaţii despre id, schimb, tipul tratamentului, alt tabel pentru valorile senzorilor Cxs(x este numarul cuptorului). Tabelul total concatenează la atributul tag1 coordonata reperului pieselor, iar în atributul tag2 numarul acestora. În cadrul tabelului finish_treatmens se regăsesc coordonatele ce vor putea genera rapoarte pentru piesele ce şi-au terminat tratamentul terminc. Cheia ce leaga tabelele şi identifică atributele ale unui tratament/cuptor este dat de id-ul unic al unei şarje ce a fost introdus de către operator. 26

27 Fig Structura bazei de date normalizată Motorul bazei de date poate proveni de la orice producător (Oracle/Microsoft) şi poate fi salvat fizic pe hard disc în orice zonă, recomandarea fiind pe o altă partiţie decât cea a sistemului de operare (în cazul unui virus/corupere de fişiere ale sistemului, datele pot fi pierdute datorită securităţii fisierelor NTFS). Aplicaţia foloseste o instanţă de Microsoft SQL Server 2005, express edition. S-a ales această distribuţie datorită posibilităţii utilizării unei licenţe gratuite în limita a 4 Gb a BD pe discul fizic. Pentru comunicaţia între BD şi Reliance, în setările instanţei SQL am folosit autentificarea prin credenţialele sistemului de operare, securitatea este asigurată astfel de catre distribuţia Windows folosită. Specificaţiile proiectului mentionau o forma de back-up/restore a bazei de date. Am configurat fisierele.sql pentru ca serverul sql să poată executa copiile de siguranţă dar aveam nevoie de o interfaţă care să execute aceste fisiere sql. Am ales linia de comandă din Windows pentru această operaţiune şi am creat niste fişiere. bat care apoi le-am convertit în.exe şi am configurat Reliance-ul să acceseze executabilul când operatorul apasă butoanele specifice (fig Fig 4.3.2). Codul pentru back up este scris pentru linia de comandă a windows-ului şi compilat în format.exe cu un utilitar free, deoarece Reliance nu suportă execuţie de fisiere.bat (partea de scripting VB din nu suportă nici aplelarea funcţiei shell(), ce accepta ca argument orice cale spre un executabil sau fisier.bat ). Am folosit procesul sqlcmd pentru a rula interogarile ce trebuie să 27

28 execute backup-ul. Codul se paote observa în ultimul capitol la Anexa B. După generarea copiei de siguranţă, baza de date poate fi pastrată pe orice mediu de stocare (ea fiind un fisier.bak), revenirea se face punînd fisierul.bak în folderul restore şi activând btonul de restaurare din meniul aplicaţiei. Fig Meniul pentru copie de siguranţă DB Informaţia din BD este folosită în fabrică pentru sincronizări între roboţii industiali, monitorizarea stocurilor pentru piese, eventual chiar şi comandarea automată de piese la diferiţi provideri. Un alt avantaj al BD este trasabilitatea componentelor/loturilor în fabrică şi în timp, reprezentînd o arhivă digitală compactă. Atributele unui sistem de DB pot fi reprezentate de: dimensiunea ocupată de stocarea informaţiilor pe mediul fizic timpul de răspuns la interogari În funcţie de motorul bazei de date şi de propietăţile acestuia de a stoca/administra informaţia, se poatem avea dimensiuni mai mari sau mai mici a fişierelor fizice. În ziua de astăzi, cam orice distribuţie licenţiată de DBMS (exceptand versiunile Express care sunt gratuite) are ca limitare de stocare capacitatea discului fizic. Cum această capacitate nu mai este o problemă, discuţia se mută în partea de administrare. Un DBMS (Data Base Management Sistem) performant combinat cu o administrare/setare corespunzătoare a motorului bazei de date oferă un timp de răspuns bun interogarilor necesare obţinerii informaţiei sau pentru generarea rapoartelor. Volumele tot mai mari de informaţie şi timpii de răspuns tot mai lenţi ale interogărilor necesită o încapsulare (în sensul de abstractizarea datelor) optimizată. Soluţia este reprezentată de creearea indexilor (tip B-tree, Bipmap ). Aceştia necestită stocarea unei coloane suplimentare şi o 28

29 operaţie de refresh atunci când se execută modificări în tabele. Partiţionarea este o soluţie mai elegantă deoarece foloseşte pe post de index datele deja existente în BD. Procesul se face prin gruparea datelor în indexi tip lista, domeniu sau funcţii tip hash). Ambele soluţii oferă timp de execuţie mai buni pentr interogări, trebuie doar puse în balanţă avantajele/dezavantajele. Problemele de stocare/performanţă fiind rezolvate, mai rămane de tratat cazul în care arhitectura hard poate ceda (fail-over). Existe aplicaţii, în care continutul informaţiilor stocate este sensibil (ex: tranzacţii monetare) şi disponibilitatea informaţiilor trebuie să fie în proporţie de 99%. Soluţia vine prin înbinarea softului şi a componentelor hardware în asa manieră încat să fie asigurată scalabilitatea şi disponibilitatea la un preţ scăzut. Rezultatul este arhitectura tip cluster (Fig 4.3.3) care conţine mai multe calculatoare (noduri) ce au arhitecturi hardware asemănatoare. Din toate nodurile la un moment dat doar unul este activ (comunica cu dispozitivul de stocare partajat), celelalte sunt în aşteptare iar în cazul în care nodul activ se defectează din varii motive, unul din celelalte noduri se va activa. Un exeplu este solutia RAC (real application clustering) de la Oracle. Fig Arhitectura tip cluster 29

30 V. Ieșirile din sistem A. Semnalizarea audio/video Ieşirile digitale (Fig 5.1) îndeplinesc partea de comandă a semnalizărilor audio/video şi reprezintă ieşirile din aplicaţie. Modulele comunică prin protocol modbus şi setarea lor din Reliance în 1 sau 0 logic va aprinde lampile martor ce simbolizează alarmă depăşire temperatură. Dacă există cel putin o alarmă pe oricare dintre cuptoare, girofarul va rula încontinu, iar hupa va suna cu o temporizare de două secunde pentru fiecare iniţializare a alarmei lămpilor martor. Temporizarea hupei este plasată pe thread-ul doi de execuţie pentru a evita posibile întârzieri pe celelalte scripturi. Flag-ul ce activează codul pentru apelarea temporizării ( EnableHupaScriptCall ) face şi legătura între thread-uri şi este un parametru global. Auditul acestor ieşiri se face prin intermediul butonului din meniul principal. Cât timp este pornită această verificare toate lămpile martor sunt aprinse şi operatorul poate verifica dacă sunt becuri arse. Această procedura trebuie executată periodic pentu a asigura buna funcţionare a alarmelor şi evitarea semnalizărilor false sau inducerea în eroare a operatorului. Fig Modul pentru ieșirile digitale În cazul unor erori de comunicaţie sau alte probleme, fiecare modul are un led martor ce indică starea de eroare (fail). 30

31 B. Raportarea Raportarea este esenţială pentru procesele ce se derulează în fabrică şi fac obiectul dovezii (legale), conform căreia fabrica respectă cerinţele clientului, alte constrângeri fiind definite şi de certificarea ISO. Rapoartele pot face parte din eticheta loturilor, prin tipărire în clar a informatiilor, sau anumiţi parametrii pot fi codati într-o matrice de date (datamatrix), aceasta din urmă fiind folosită pentru identificarea piesei/lotului mai depate în fluxul tehnologic intern sau extern. Clienţii finali pot folosi la rândul lor acea identificare pentru alte asamblari/verificări. Raportarea datelor pentru a fi exportate din mediul Reliance are doua compente: rapoartele simple(care sunt rudimentare şi reprezintă un şablon standard oferit programatorului) şi rapoartele customizate. Acestea sunt superioare prin posibilitatea de a transfera valori ale parametrilor din Reliance în modulul de raportare, suportă execuţia scripturilor folosind limbaje ca VB, C++ (pentru obţinerea formatării dorite), interogari sql şi customizarea formei (layout) dupa cerinţa clientului. Pentru o flexibilitate ridicată am ales să trimit parametrii prin valoare din aplicaţia Reliance în modulul de raportare Fast Report (Fig a). Acest lucru este posibil prin crearea unei ferestre de dialog care va prelua informaţia în formatul necesar. Am selectat tagurile ce fac legătura între aplicaţie şi raport (Fig b). În cazul de faţă va fi tip DateTime. Urmează conversiile specifice pentru a obţine codarea datei în formatul suportat de Reliance (Fig c). Timpul este salvat în baza de date îin atributul TimeStamp formatul fiind dat de conversia internă a datei/orei (UTC) în format int64, astfel este nevoie de codarea/decodarea timpului pentru interogările SQL (structured query language limbaj de interogarare structural ). 31

32 Fig Fluxul informaţiei pentru obţinerea rapoartelor customizate Figura ilustează un raport ce reprezintă grafic evoluţia temperaturilor pentru un tratament termic. Imaginea este statică şi poate fi exportată în format PDF sau poate fi printată. 32