Sunteți pe pagina 1din 39

Structura software a aplicatiilor de conducere in timp real

-

Raport

-

Cuprins:

1. Notiunea de timp real;

2

2. Structuri de aplicatii de timp real; (dependente de arhitectura hardware - sisteme mono si multiprocesor)

4

3. Sisteme de operare pentru aplicatii software de timp real;

16

4. Limbaje de programare/dezvoltare si implementare a Apl. Soft. de TR

17

5. Implementarea unor drivere de achizitie;

21

6. Implementarea unor sisteme distribuite de conducere. Functiile unui program de monitorizare (SCADA);

26

7. Implementarea unei aplicatii de conducere la distanta;

33

Bibliografie

37

1

1.

Notiunea de "Timp Real"

Diferenta esentiala dintre o aplicatie oarecare de calcul sau de proiectare si una de timp real este data de modul de utilizare a timpului pentru asigurarea functiilor de control in raport cu timpul in care evolueaza procesul [9], [27]. Un program de conducere implementaza o serie de algoritmi cum sunt cei de identificare, de calcul al comenzii ce depind in mod esencial de alegerea si utilizarea perioadei de esantionare Te in mecanismele sistemului numeric [8]. Nerespectarea cu strictete a valorii perioadei de esantionare duce la reducerea sau chiar anularea performantelor sistemului pe care se implementeaza acesti algoritmi oricat de complex si/sau performant ar fi acesta ! Pentru un program software perioada de esantionare este echivalenta cu lansarea in executie a procedurilor respective la un interval de timp bine precizat si respectarea acestuia indiferent de evenimentele care pot apare. Figura 1.1 prezinta acest aspect:

Lansare operatii de achizitie, calcul comanda etc. T e 2T e 3T e 4T e
Lansare operatii de
achizitie, calcul
comanda etc.
T e
2T e
3T e
4T e
5T e
t

Fig. 1.1 Lansarea in executie a operatiilor dependente de perioada de esantionare Te

In general, din punct de vedere cronologic, prima operatie care este declansata este cea de achizitie a datelor din proces, celelalte operatii, printre care se numara si cele de identificare, calcul de comanda etc. fiind dependente de datele furnizate de prima. Un aspect important ce nu trebuie scapat din vedere este timpul necesar executarii operatiilor dintre doua momente de “esantionare” si care reprezinta timpul total necesar operatiilor de achizitie, identificare, calcul de comanda etc. Acesta trebuie sa fie strict mai mic decat cel al perioadei de esantionare, depasirea sa ducand la nerespectarea conditiilor de functionare “in timp real”. Din punct de vedere grafic, acest aspect poate fi reprezentat conform figurii 1.2. Daca acest deziderat nu poate fi realizat este necesara o regandire a ansamblului hardware – software. Am accentuat acest aspect pentru a scoate in evidenta necesitatea utilizarii unor algoritmi rapizi din punctul de vedere al operatiilor efectuate. Realizarea unui mecanism de lansare a unor operatii la un interval de timp bine determinat depinde in general de sistemul de operare si de mediul de dezvoltare al aplicatiei.

2

Start operatii de achizitie, calcul comanda etc. Stop operatii de achizitie, calcul comanda etc. t
Start operatii de
achizitie, calcul
comanda etc.
Stop operatii de
achizitie, calcul
comanda etc.
t
nT e
(n+1)T e

Fig. 1.2 Durata procedurilor lansate la fiecare moment de esantionare comparativ cu cea a perioadei de esantionare

Alegerea unei perioade de esantionare se face in functie de constantele de timp ale procesului fizic si de semnalele achizitionale dun proces, corespunzatoare marimilor fizice urmarile – presiuni, temperatura, acceleratii, viteze, pozitii nivel etc.

3

2. Structuri de aplicatii de timp real; (dependente de arhitectura hardware - sisteme mono si multiprocesor)

In functie de complexitate sau/si de importanta, aplicatiile de timp real pot fi implementate pe mai multe tipuri de structuri hardware de conducere. Acestea au la baza unul sau mai multe procesoare. Pentru aplicatiile cu multe cicluri repetitive si care nu necesita algoritmi de conducere complicati pot fi utilizate structuri gen automat programabil (AP sau PLC), sau gen microcontroller (embedded). Structurile de acest gen au in general un singur procesor (logica de control). Pentru aplicatiile deosebit de complexe [10], [6] unde sunt necesari algoritmi deosebiti, resurse importante de memorie si de calcul, bazandu-ne pe descompunerea problemei in mai multe subprobleme interdependente – se poate alege o structura multiprocesor, intalnita in special, in cazul calculatoarelor de proces. Uneori, daca subproblemele pot fi separate total – total independente, din motive de fiabilitate se poate alege o structura compusa din mai multe PLC-uri sau microcontrollere, conectate intre ele intr-o retea. Structura aplicatiilor (software) este strict dependenta de arhitectuta hardware utilizata. Prezentam in continuare cateva din situatiile existente.

Structuri monoprocesor:

Automate programabile (AP sau PLC); Un AP sau PLC luceraza intr-o bucla continua (infinita). Pot fi diferentiati 3 pasi impotranti in aceasta bucla. In realitate sunt mai multi de 3 dar ne vom concentra pe acestia [29]. (Ca exemplu pentru alti pasi putem considera verificarea functionarii sistemului in sine, actualizarea counter-ului intern - ceasul de garda si a timpului/datei).

Pasul 1 - Verificarea starii intrarilor – se verifica fiecare intrare si se determina daca este ON sau OFF iar resúltatele sun scrise in memorie. Pasul 2 – executie program – in functie de valorile intrarilor sun executate instructiunile programului/programelor Pasul 3 – actualizarea iesirilor – contactele, tensiunile sau curentii iesirilor fizice sunt setate la valorile corespunzatoare celor setate din program

Dupa cel de-al treilea pas lucrurile se reiau de la pasul 1. O scanare completa este definita ca timpul necesar parcurgerii celor trei pasi. Figura 2.1 ilustraza schema unui ciclu pe un automat programabil.

Figura 2.1 ilustraza schema unui ciclu pe un automat programabil. Fig. 2.1 Desfasurarea unuei aplicatii pe

Fig. 2.1 Desfasurarea unuei aplicatii pe un AP sau PLC

4

Calculatoare de proces;

Principiile construirii si implementarii unor programe cu functionare in timp real Implementarea unui program cu functionare in timp real se bazeaza, in marea majoritatea situatiilor, pe doua elemente functionale: un mecanism de lansarea unor operatii ciclice la un inreval bine determinat de timp (perioada de esantionare) si o bucla program “infinita”.

Lansarea unor operatii ciclice Vom reveni la modul de realizare a unui mecanism de lansare a unor operatii la un interval de timp bine determinat si ne vom referi in special la metoda de realizare bazata pe intreruperi [8]. Aceasta abordare este preferata deoarece acesta este mai generala. Situatia este intalnita in cazul in care sistemul de operare lipseste sau este o versiune de MSDos. Daca in acest caz se poate realiza o aplicatie, trecerea la un echipament cu sistem de operare si de dezvoltare in care aceste facilitati sunt deja oferite nu poate fi decat o simplificare. Sintetic, intreruperile sunt “semnale” ce sunt trimise procesorului sau sistemului central, la aparitia unor evenimente hardware sau software si care, determina in functie de prioritatea acordata, suspendarea actiunilor curente ale procesorului sistemului si lansarea in executie a unor functii specifice – denumite functii de tratare a intreruperii.

Cea mai buna exemplificare de intrerupere pentru sistemele de tip PC sunt intreruperile de ceas (0x1C h) (0x08 h) ce apar la fiecare 55 de milisecunde. Aceaste fac parte din clasa intreruperilor rezervate utilizatorului si pot fi folosite cu usurinta la realizarea unui mecanism de lansare ciclica a unor operatii. In stadiul initial functia de tratere nu executa nimic fiind compusa dintr-o singura instructiune (scrisa in limbaj de asamblare) de tip iret. Realizarea mecanismul de lansare ciclica presupune pentru inceput scrierea unei noi proceduri de tratare a intreruperii, care in limbajul C standard de forma urmatoare:

void interrupt new_intr(void)

{

contor++;

}

Elementul central al acestei functii simple este constituit de variabila “contor” care este incrementata la fiecare aparitie a intreruperii. In realizarea clasica a unui program, anterior instalarii noii functii de tratare a intreruperii se salveaza continutul vechiului vector de intrerupere conform urmatoarei secvente, scrisa tot in limbajul C:

#define INTR 0x08 …………………… // declararea unui pointer catre un vector de intrerupere void interrupt(*old_intr)(void); // declararea noului vector de intrerupere

5

void interrupt new_intr (void)

{

contor++;

}

void main()

{

……………………

// salvarea vechiului vector de intrerupere old_intr =getvect( INTR); // instalarea noului vector de intrerupere setvect( INTR, new_intr); ……………………

}

In cazul unui echipament in care sistemul de operare impreuna cu mediul de dezvoltare sunt mai evoluate lucrurile se desfasoara similar si mult mai intuitiv. Spre exemplificare vom prezenta sectiuni dintr-un program de conducere dezvoltat in mediul LabWindows/CVI al firmei National Instruments [30] ce are sistem de operare Windows (NT, XP sau 2000). Ideea de baza consta in instalarea unui eveniment ce apare intr-un mod

asemanator unei intreruperi si a unei functii ce va fi apelate pentru tratarea evenimentului. Atat evenimentul cat si functia sunt instalate intr-un mod explicit si usor de inteles. …………………………. // declararea prototipului functiei de tratare a evenimentului int GetData( int panel, int control, int event, void *callbackData, int eventData1, int eventData2); …………………………. main()

{

char x; handle = LoadPanel (0, "ad_mm_30.uir", BI); //instalarea interfetei grafice DisplayPanel (handle); …………………………. // setarea perioadei de aparitie al evenimentului SetIdleEventRate (100); // instalarea functiei de // tratare al evenimentului InstallMainCallback (GetData,(void *)&x , 1); RunUserInterface(); } // end main

// declararea functiei de tratare a evenimentului

int GetData(int panel, int control, int event, void *callbackData, int eventData1, int eventData2)

{

………………………….

6

if(event==EVENT_IDLE)

{

// procedurile ciclice …………………………

}

}

Functia descrisa anterior pentru tratarea “evenimentului” poate fi apelata si cu alte evenimente, de aceea pentru a face distinctia intre acestea si cel periodic (EVENT_IDLE) care ne intereseaza, trebuie facut un test corespunzator

( if( event == EVENT_IDLE ) ).

Nu

voi

insista mult

asupra acestor aspecte

deoarece

ele tin

mai

mult

de

particularitatile mediului de dezvoltare LabWindows/CVI.

Implementarea programului principal Am vazut pana acum modalitatea de realizare si instalare a unei functii care este apelata la un interval de timp bine determinat. Aceasta nu este suficienta pentru realizarea unui program de conducere in timp real. Ceea ce lipseste este programul principal. Filozofia de constructie a acestuia este de a realiza si/sau lansa o bucla infinita din care iesirea se face la aparitia unui eveniment special sau la inchiderea aplicatiei. Figura 2.2 expliciteaza in mod grafic aceasta constructie:

Intrare in

“bucla infinita” Operatiuni ciclice Conditie de NU iesire din bucla
“bucla infinita”
Operatiuni
ciclice
Conditie de
NU
iesire din
bucla

infinita”

DA

“bucla

a programului

Iesire din

“bucla infinita”

Fig. 2.2 “Bucla infinita” a programului principal

7

Pentru

un

program

scris

in

C

standard

(Turbo

C

2.0) bucla infinita este

implemenata utilizand structurile de tip do-while sau while astfel:

char c; ……………………… void main()

{

……………………… do{

c='1';

if(kbhit())

c=getch();

………………………

}while(c!='q');

Dupa intrarea in structura do-while (care implementeaza bucla “infinita”) iesirea nu se poate realiza decat prin apasarea tastei q (quit). In interiorul buclei se testeaza daca s-a apasat cumva o tasta si daca da, se citeste valoarea acesteia. Fara acest test iesirea din program nu mai este posibila decat prin resetarea aplicatiei. In cazul unei aplicatii realizate in Lab Windows/CVI lansarea interfetei utilizator realizata prin apelarea functiei RunUserInterface() duce la intrarea automata intr-o bucla infinita din care se poate iesi doar prin incheiderea aplicatiei prin apelul functiei

QuitUserInterface(0).

Programul principal luat ca atare nu poate asigura facilitatile de timp real necesare. Principala cauza este timpul de executie al procedurilor ciclice (achizitie, calcul de comanda etc.) care este de foarte multe ori variabil si puternic dependent de structura hardware a sistemului. Prin combinarea facilitatilor oferite de intreruperi si a celor de bucla infinita se poate realiza un program care sa raspunda cerintelor. Legatura intre cele doua este realizata in modul urmator: in bucla infinita a programului principal este testata valoarea contorului incrementat in functia de tratare a intreruperii. In momentul in care valoarea acestuia devine egala sau mai mare decat o valoarea stabilita, se reseteaza contorul si se lanseaza in executie operatiile ciclice.

De exemplu, pentru un program ce ruleaza in sistemul de operare MSDos, utilizand intreruperea de ceas 0x1C H, daca se doreste o perioada de esantionare de o secunda, valoarea contorului va fi resetata atunci cand valoarea acestuia este mai mare sau egala cu 18 (18 x 55 ms = 1 s). Secventa de cod corespunzatoare testarii si resetarii contorului poate fi urmatoare:

if(contor>=18)

{

contor=0;

// lansare si executie operatii ciclice …………………………

8

}

Garantia ca perioada de esantionarea este respectata fara a exista pericolul modificarii in functie de complexitatea calculelor procedurilor ciclice este data de faptul ca functia de tratare a intreruperii are o prioritate mai mare decat programul principal.

Pentru un program scris in Lab Windows/CVI testarea si respective resetarea contorului pentru aceeasi perioada de 1 secunda se realizeaza astfel:

int GetData(int panel, int control, int event, void *callbackData, int eventData1, int eventData2)

{

 

if(event==EVENT_IDLE)

{

// incrementare contorTe

contorTe=contorTe+0.1;

// bucla de reglare if(contorTe>=Te)

{

// resetarea contorului

contorTe=0.0;

…………………………………

}

}

}

Concentrand toate aspectele prezentate, forma generala a unui program de conducere bazat pe intreruperi scris in pseudo-cod este urmatoarea:

// parte declarativa main()

{

//operatii de initializare init(); // salvare vechi vecror de intrerupere si instalare vector nou old_intr =getvect( INTR); setvect( INTR, new_intr); ………………………………… // intrare in bucla infinita do {

// tratare evenimente datorate apasarii unor taste etc. ………………………………… // test contor

if(contor>=18)

{

// resetare contor

9

contor = 0; // lansare proceduri ciclice achizitie(); comanda(); ………………………………… // afisare grafica afisare(); } // end test contor }while (conditie_de_iesire) //operatiuni de dupa iesirea din bucla infinita …………………………………… // restaurarea vechiului vector de intrerupere setvect( INTR, old_intr); } // end main()

Transformarea acestui exemplu intr-un program real este foarte rapida si facila.

Arhitecturile hardware recomandate pentru utilizarea programelor descrise pot fi de tipul urmator:

sisteme numerice dezvoltate in jurul unor procesoare de tip microcontroller (de exemplu familia 80xC552, INTEL XA3).

PC (eventual industrial) + placa/placi de achizitie;

Prima structura este adecvata in special, aplicatiilor de laborator, cu un numar redus de parametrii, iar a doua atat pentru aplicatiile de laborator, dar mai ales pentru cele industriale, unde numarul parametrilor nu depaseste 100.

Microcontrollere (& embedded systems)

Elementele prezentate pentru dezvoltarea aplicatiilor de timp real pentru sistemele de tip calculator de proces sunt valabile si pentru sistemele cu microcontrollere (embedded systems). Nu le vom mai relua.

Structuri multiprocesor:

Calculator de proces;

Si pentru acest tip de stuctura sunt valabile mecanismele prezentate mai inainte (cele pentru calculator de peroces). Suplimentar si an mod imperativ, pentru structurile multiprocesor [23], [324], [25] sunt necesare mecanisme specifice aplicatiilor multithread. Aplicatiile de tipmultithread sunt utilizabile si pe structuri monoprocesor sau in cazurile in care numarul de tascuri este mai mare decat nimarul de procesoare, insa rularea in paralel a thread-urilor este doar o iluzie (fog. 2.4), aceasta fiind reala doar in cazul multiprocesor. Vom detalia in continuare cateva din aceste aspecte.

10

Aplicatii multi thread. Introducere

Comparativ

caracteristici:

cu

programarea

secventiala

unde

se

intalnesc

urmatoarele

Nu se impun restrictii asupra timpului, resurselor etc.

Programul functioneaza ca un filtru (fig. 2.3);

Evolutia depinde doar de datele de intrate;

Date de

intrare

Program

secvential

Date de iesire

Date de intrare Program secvential Date de iesire Figura 2.3: Schema de evolutie a unui program
Date de intrare Program secvential Date de iesire Figura 2.3: Schema de evolutie a unui program

Figura 2.3: Schema de evolutie a unui program secvential

Aplicatiile multithread se caracterizeaza prin executia in paralel a doua sau mai multe fire de executie (thread-uri) [9]. Acestea pot fi independente insa, in majoritatea situatiilor, “comunicand” intre ele date.

Programare multi tasking (multi-thread)

intre ele date. Programare multi tasking (multi-thread) Figura 2.4: Schema de evolutie a unui program multi

Figura 2.4: Schema de evolutie a unui program multi task-ing (a) Efect macroscopic-dorit si obtinut pe o structura multiplocesor cu un nr. suficient de procesoare, (b) divizarea timpului procesorului (procesoarelor)

11

Elemente de baza

Stari ale task-urilor Removed – suspendat – este prezent pe disc, gata sa fie incarcat in RAM; Waiting – in asteptare – este in asteptarea unor evenimente externe (transfer de date I/O, introducere de date de la tastatura, intrerupere externa) sau interne (un anumit semnal de la alt task); Ready – gata- task-ul poate fi executat in orice moment in care procesorul este liber; Running – in executie – tascul curent ce este executat de procesor;

in executie – tascul curent ce este executat de procesor; Figura 2.5: Starile si tranzitiile unui

Figura 2.5: Starile si tranzitiile unui task

Tranzitiile sau operatiile posibile sunt urmatoarele:

1. Din removed in ready – procesul este incarcat de pe disc in memoria RAM, cu realocarea tuturor adreselor relative si atribuirea zonei de lucru (cod, date, heap, stiva);

relative si atribuirea zonei de lucru (cod, date, heap, stiva); Figura 2.6: Zona de lucru a

Figura 2.6: Zona de lucru a unui task (program)

12

2.

din ready in running – task-ul este selectat de planificator sa ruleze si este atribuit procesorului controlul asupra acestuia;

3. din running in ready - inversarea situatiei 2 – cand se face comutarea pentru ca un alt task mai prioritar in acel moment, sa aiba posibilitatea de a fi rulat;

4. din running in waiting – task-ul intra intr-o stare de asteptare fie a unui eveniment axtern, fie a unei operatii de I/O mai lenta, sau pentru a astepta o anumita perioada de timp, conform unei instructiuni specifice;

5. din waiting in ready – cand evenimentul asteptat s-a produs sau cand perioada de timp (de asteptare) a expirat, task-ul nu este imediat executat dar este pos in starea de ready. Planificatorul va determina mai tarziu cand procesul poate fi executat;

6. din ready in removed – cand apare o instructiune de tip end; sistemul de operare poate elimina task-ul din memoria centrala.

Alte elemente utlizate: Semafoare, Liste, Cozi, Buffere, Cutii postale etc [9].

Semafoare:

Sunt variabile intregi ce pot avea doar valoarea 0 sau 1 (sau o alta valoare pozitiva). Au o anumita stare initiala. Semafoarele care iau doar valorile 0 si 1 se mai numesc si semafoare binare. Au fost propuse de Dijkstra (1968) ca proncipiu de baza al sincronizarii.

Buffere (eventual circulare):

Elemente deosebit de importante (si elegante) utilizate in general pentru schimbul de date intre doua sau mai multe task-ri. Sunt de fapt niste zone finite de memorie. Aplicatii utilizand aceste elemente se gasesc in special in zona comunicatilor unde vitezele de transmitere pot fi variabile. Le sunt asociate notiunile de task producator si task consumator.

fi variabile. Le sunt asociate notiunile de task producator si task consumator. Figura 2.7: Schema unui

Figura 2.7: Schema unui buffer circular

13

Cutii postale (mailboxes):

Este o lata modalitate de a realiza schimbul de date si sincronizarea a doua sau mai multe procese. Sunt structuri de date orientate spre mesaje ce pot fi depozitate si ridicate.

date orientate spre mesaje ce pot fi depozitate si ridicate. Figura 2.8: Schema unei cutii postale

Figura 2.8: Schema unei cutii postale

Programarea multi-thread Un program multi-thread este un program in care sunt executate in acelasi timp mai mult de un thread. Un program single-thread are doar un singur thread, denumit si thread proncipal (main thread). Sistemul de operare creaza thread-ul principal atunci cand utilizatorul comanda respectivului sistem de operare inceperea executiei unui program oarecare (de ex. prin efectuarea unui dublu clik pe o iconita). In mod impicit, sistemul de operare cauta functia main sau WinMain, dupa care incepe executia efectiva a acesteia. In programarea multi-thread programul (in sine) comanda sistemului de operare sa creeze thread-uri suplimentare fata de main. Aceste thread-uri suplimentare se mai denumesc si thread-uri secundare. Diferenta majora intre thred-urile secundare si cel principal (main) este momentul in care acestea isi incep actiunea. Utilizatorul specifica momentul in care un thred secundar isi incepe actiunea, spre deosebire de thred-ul principal ce ce isi incepe actiunea, intotdeauna cu functia main. Intr-o aplicatie muti-thred sistemul de operare permite fiecarui thread executia sectiuni proprii de cod, dupa care este comutat cu alt thread. Perioda de timp pe care sistemul de operare o aloca unui anumit thread se numeste (time-slice) sectiune de timp. Operatia sistemului de operare de oprire a unui thred si de activare a altuia se numeste comutare de thred-uri thred-switch. In mod uzual, un sitem de operare ofera posibilitatea comutarii thred-rilor foarte rapid ceea ce da senzatia executiei concurente a mai multor thread-uri in acelasi timp.

Argumente pentru alegerea unei solutii multi-thread

Pot fi formulate patru argumente majore pentru alegerea unei solutii multi-thread in constructia unui program cu functionare in timp real.

14

A:

Cel mai intalnit motiv de separare a unei aplicatii in mai multe task-uri este acela in care timpul de executie al unor anumite operatii este o conditie critica a bunei functionari a intregii aplicatii.

De exemplu:

Un program ce realizeaza achizitia unor date si are si o interfata utilizator, este un bun motiv de a fi organizat astfel (multi-thread). In acest program, achizitia datelor este un task in care timplul este o resursa critica si poate fi influentat in mod negativ de actiunile asupra interfetei utilizator.

Utilizarea unei solutii ce se bazeaza pe un singur thread, in general executa:

operatie de extragere (call to pull) a datelor din buffer-ul placii sau dispozitivului de achizitie,

afiseaza grafic datele pe interfata utilizator,

proceseaza evenimetele ce permit modificarea parametrilor interfetei utilizator.

Daca utilizatorul doreste sa efectueze mai multe operatii asupra interfetei utilizator (de exemplu sa modifice pozitia cursorului pe graficul in care sunt afisate datele), thread-ul continua sa proceseze evenimentele ce tin de interfata si nu va permite citirea datelor din buffer-ul de achizitie ceea ce va duce la depasirea acestuia si in mod curent la poerderea unor date. Utilizarea unei abordari multi-thread presupune plasarea operatiunilor de achizitie in thread-ul secundar si a celor de afisare in interfata utilitor in cel principal. In acest mod daca utilizatorul efectueaza operatii asupra interfetei sistemul de operare face comutarea thred-rilor (de la cel principal la cel secundar) pentru a permite realizarea operatiilor de achizitie.

B:

Al doilea motiv intalnit ce indica alegere a unei structuri multi-thread, este existenta unor aplicatii in care se doreste realizarea simultana a unor operatii lente de intrare/iesire.

De exemplu:

O aplicatie foloseste o procedura (un instrument) pentru testarea unor circuite de pe o placa. Utilizand varianta cu un singur thread se executa:

pe un port (serial de exemplu) este trimisa trimisa o secventa de initializare a placii respective,

se asteapta sfarsitul operatiilor de initializare,

in final, se realizeaza operatiile de masura ale rezultatelor.

Aplicatia este foarte sensibila la timpii de asteptare si este foarte particulara, avand nevoie de dese reconfigurari. Utilizand o mult mai corecta abordare multi-thread, in thread-ul secundar se va face initializarea instrumentului de test.

15

In acest mod in thread-ul principal se va astepta incheierea initializarii placii respective si se vor citi rezultatele testelor. Rezulta astfel, executarea in paralel a operatiilor lente de intrare/iesire si scaderea timpului total de asteptare/functionare.

C:

Al treilea motiv de a construi un program in varianta multi-thread este acela de a mari performantele acestuia in cazul in care dispunem de o arhitectura harhware multiprocesor. Fiecare procesor al structurii poate executa un thread. Astfel, spre deosebire de arhitecturile cu un singur procesor unde se creaza doar impresia unei executii multi- thread, aici totul este corect si cu adevarat in paralel. De exemplu Un program mai complex executa achizitia unor date, afisarea acestora in cadrul unei interfete, scrierea unor fisiere istoric si o analiza conform unor algoritmi complexi, poate beneficia din plin de o astfel de arhitectura. Scrierea datelor pe disc si analizasi afisarea acestora impun in mod special thread- uri separate, executate pe procesoare separate.

D:

Ultimul din cele patru motive, este inalnit in situatiile in care se doreste testarea unui anumit task in paralel (simultan) pentru situatii diferite.

16

3. Sisteme de operare pentru aplicatii software de timp real

Rolul unui sistem de operare este de a gestiona resursele hardware (memorie, porturi, periferice etc.) ale sistemului de conducere si de a oferi functii de acces catre aceste resurse pentru programele care ruleaza. Sistemele de operare cele mai cunoscute din domeniul acestor aplicatii sunt Windows (>NT), MSDos, Linux, QNX. Sunt dese situatiile in care sistemul de operare lipseste, programul executabil al aplicatiei (intr-o forma adecvata – de exemplu binara) realizand in mod direct gestionarea resurselor hardware. Gestionarea directa a resurselor duce la o crestere a vitezei aplicatiei dar si a efortului depus la dezvoltarea aplicatiei deoarece cu cat partea harware este mai complexa cu atat mai multe sunt driverele necesare a fi scrise. In plus, scrierea unui astfel de driver necesita cunostinte deosebite si amanuntite legate de structura dispozitivului tinta.

Este bine de realizat un compromis pentru rezolvarea acestei probleme, existenta unui sistem de operare usurand mult lucrurile. In general sistemele hardware complexe cum sunt calculatoarele industriale au un astfel de sistem de operare.

17

4. Limbaje de programare/dezvoltare si implementare a ASTR; (Apl. Soft. De TR)

Pe piata mondiala exista in acest moment trei variante principale de dezvoltate a aplicatiilor de timp real:

Limbaje de uz general utilizand cod program (ASM, C++, Java, LabWindowsCVI

Real Time) [30], [31], . Limbaje de uz general utilizand elemente grafice (LabView Real Time)

Limbaje dedicate automatelor programabile (Function Blok Diagram (FBD),

Grafcet, Structured Cod) [20], [29], [33], [34.

In continuare vom prezenta implementarea unui filtru numeric in limbajele de uz general (C, C++, Java), precum si pentru Structured Text, Function Block Diagram, Sequential Function Chart, Horner Ledder Diagram si IEC Ledder Diagram pentru un automat programabil Horner [21], [22].

Forma filtrului vazut ca un sistem discret de ordinul II [10] este :

H

m

(

q

1

)

=

b

 

+ b

 

1 b

+

m

2

q

2

m

0

m

1

q

 

1

2

a

m

0

+ a

m

1

q

+

a

m

2

q

Exemplificare pentru limbajele de uz general (C, C++, Java etc.)

rdk=-am1*rdk_1-am2*rdk_2+bm1*rk_1+bm2*rk_2;

rdk_2=rdk_1;

rdk_1=rdk;

rk_2=rk_1;

rk_1=rk;

Exemplificare pentru atomatele programabile (AP):

Strucured Text :

rdk_2=rdk_1; rdk_1=rdk; rk_2=rk_1; rk_1=rk; Exemplificare pentru atomatele programabile (AP): Strucured Text : 18

18

Function Block Diagram:

Function Block Diagram: Sequential Function Chart: 19

Sequential Function Chart:

Function Block Diagram: Sequential Function Chart: 19

19

Horner Ledder:

Horner Ledder: Se observa ca varianta « structured text » se aseamana forte mult cu varianta

Se observa ca varianta « structured text » se aseamana forte mult cu varianta din limbajele generale de programare.

20

5. Implementarea unor drivere de achizitie;

Construirea sau adaptarea unui driver de achizitie pentru citirea/scrierea unei marimi analogice sau digitale – AI, AO, DI, DO este unul din primii pasi facuti in dezvoltarea unui sistem de achizitie si control. Un driver reprezinta un program sau o o procedura prin care este controlata o marime sau un dispozitiv. Structura acestuia este puternic dependenta de arhitectura hardware. Importanta utilizarii unui driver bine construit se reflecta in primul rand in viteza de achizitie si acuratetea datelor sistemului. O abordare generala a constructiei acestora nu poate fi data datorita multitudinii de structuri hardware existente. In cele ce urmeaza ne vom referi strict la constructia unor drivere pentru placile de achizitie si microcontrollere. Ideea ce sta la baza dezvoltarii unui driver o reprezinta faptul ca registrii corespunzatori controlului dispozitivului respectiv, sunt vazuti ca niste porturi ce pot fi citite sau scrise [35]. Aceste porturi au un numar limitat si incep de la o anumita adesa de baza. Ca orice locatie de memorie registrii au o lungimea de 8 biti (sau 16 biti) iar operatiile de baza utilizate pentru scrierea acestora sunt de tip inp(inport) si outp(outport). Figura urmatoare (figura 5.1) exemplifica pozitionarea a 16 (0x0F h) registri in memorie incepand cu adresa de baza 0x200 h.

Adresa de inceput denumita si “Baza” = 0x200 h

0x200 h. Adresa de inceput denumita si “Baza” = 0x200 h Reg. Baza+0 Reg. Baza+1 Zona

Reg. Baza+0

Reg. Baza+1

Zona porturilor sau registrilor de control a dispozitivului respectiv

Reg. Baza+2

Reg. Baza+F

Fig. 5.1 Dispunerea registrilor de control ai unui dispozitiv de intrare/iesire

In general, registrii pot avea functii diferite pentru citire si pentru scriere. Manualul de utilizare ce insoteste dispozitivul specifica functiile si adresa acestor registri. Pentru exemplificare prezentam in tabelul urmator adresele si functiile celor 16 registri de control ai placii de achizitie PCL 812 produsa de firma Advantec. Placa are 16 intrari analogice (AI), 2 AO, 16 DI, 16 DO, amplificare programabila a gamei de intrare a semnalului analogic.

21

Adresa

Functie la citire

Functie la scriere

Baza + 0

Contor 0 8253

Contor 0

Baza + 1

Contor 1

Contor 1

Baza + 2

Contor 2

Contor 2

Baza + 3

neutilizat

Registru de control 8253

Baza + 4

A/D octet low

D/A 1 octet low

Baza + 5

A/D octet high

D/A 1 octet high

Baza + 6

DI

octet low

D/A 2 octet low

Baza + 7

DI

octet high

D/A 2 octet high

Baza + 8

neutilizat

interupere placa

Baza + 9

neutilizat

neutilizat

Baza + A

neutilizat

Selectie canal multiplexor

Baza + B

neutilizat

Cuvant de control placa

Baza + C

neutilizat

Decl. soft a conv. A/D

Baza + D

neutilizat

DO octet low

Baza + E

neutilizat

DO octet high

Baza + F

neutilizat

neutilizat

Tab.5.2 Functiile porturilor placii de achizitie PCL 812

Am spus mai inainte ca arhitectura hardware a dispozitivului controlat determina modul de constructie software a driverului. Vom evidentia aceste aspecte pentru canalele de citire/scriere marimi analogice si digitale.

Structura unei cai de achizitie a marimilor analogice se compune in general din:

multiplexor – ce are rolul de a selecta canalul de intrare dorit. Cele mai intalnite variante sunt 32:1, 16:1, 8:1 etc. Numarul bitilor de control pentru selectarea canalului dorit este dependent de numarul acestora, astfel ca pentru 32 de canale este nevoie de 5 biti (2 5 = 32), pentru 16 canale 4 biti etc. amplificator – utilizat pentru adaptarea valorii semnalului la gama de lucru a convertorului analog-numeric (CAN). Utilizarea unui amplificator programabil permite ca lantul de achizitie sa accepte game diferite decat cea a CAN. Valorile intalnite ale gamelor de masura sunt 0-10 V, 0-5 V, 0-2.5 V – pentru tensiune si 4-20 mA, 2-10 mA – pentru curent. In general fata de gama de lucru a CAN celelalte valori reprezinta diviziuni ale acesteia, astfel ca valorile de amplificare sunt 1, 2, 4 etc. convertorul analog-numeric – ce include si elementul de esantionare si retinere. In functie de numarul de biti pe care se face conversia (8, 10, 16, 32) depinde numarul de registri rezervati in care este depus rezultatul conversiei. Incheierea operatiei de conversie este in general, semnalizata prin pozitionarea pe “1” a unui bit rezervat – DRDY (Data ReaAY).

22

Fara a impune neapaparat ordinea, iata pe scurt principalii pasi facuti in achizitia unui canal analogic:

selectie mod de functionare al dispozitivului respectiv: intreruperi, interogare, DMA; setarea amplificarii canalului de achizitie; alegerea canalului achizitionat; declansarea operatiei de conversie; asteptare a incheierii operatiei de conversie analog numerice; citirea rezultatelor din registrii corespunzatori; normarea datelor din gama CAN 0 – 2 n -1 (n nr. de biti pe care se face conversia) in unitati ingineresti.

Vom exemplifica cele de mai sus pentru aceeasi placa de achizitie (PCL 812 PG) dotata cu 16 AI, amplificare programabila si convertor analog numeric pe 12 biti. Datorita faptului ca registrii placii sunt pe 8 biti, rezulatul conversiei (pe 12 biti) este depus in 2 registrii in modul urmator: cei mai putin semnificativi 8 biti (b 7 -b 0 ) sunt depusi in registrul 4 (Baza + 4) iar cei mai semnificatifi 4 biti (b 11 -b 8 ) in primele 4 pozitii ale registrului 5 (Baza + 5) conform figurii urmatoare:

Registrul

Baza + 5

       

b11

b10

b

9

b

8

   

Partea ce mai

 
b10 b 9 b 8     Partea ce mai   semnificativa a conversiei   Registrul

semnificativa a conversiei

 

Registrul

Baza + 4

b 7

b 6

b 5

b 4

b 3

b 2

b

1

b

0

   

Partea ce mai putin

 
4 b 3 b 2 b 1 b 0     Partea ce mai putin  
 

semnificativa a conversiei

 

Fig. 5.3 Pozitionare rezultatului unei conversii analog numerice pentru placa de achizitie PCL 812 PG

Pentru driverul de schizitie a unei intrari analogice in care adresa de baza a placii de achizitie este 0x220 h sectiunea de cod corespunzatoare, scrisa in C este:

// definirea unor constante ce corespund adreselor // registrilor utilizati #define ADL 0x224 #define ADH 0x225 #define AMP 0x229 #define MPX 0x22A #define MOD 0x22B #define TRG 0x22C

23

// functia de achizitie a unei intrari analogice // – are ca parametru numarul canalului citit int ai(int canal)

{

 

unsigned char h,l; // setare a modului de lucru al placii

outp(MOD,0x01);

// setarea amplificarii

outp(AMP,0x02);

// selectarea canalului citit outp(MPX,canal); // pauza pentru stabilizarea oscilatiilor

delay(1);

// declansarea operatiei de achizitie

outp(TRG,0x00);

// testare a sfarsitului de conversie /* do{

h=inp(ADH); }while((h&0x10)==0x10); */

delay(1);

// preluarea rezultatului conversiei partea H x 256 + L

h=inp(ADH)&0x0F;

l=inp(ADL);

return(256*h+l);

}

Pentru partea de scriere a unei iesiri analogice lucrurile sunt in general similare, cu diferenta ca sensul de parcurgere este inversat. Lantul de prelucrare poate contine convertorul numeric-analogic (CNA), amplificarorul si multiplexorul. In unele cazuri anumite componente pot lipsi sau pot fi inlocuite cu altele: astfel pentru aceeasi placa de achizitie (PCL 812 PG) ce are doua iesiri analogice,

amplificatorul lipseste iar multiplexorul este inlocuit cu un al doilea convertor numeric- analogic, fiind preferata varianta cu doua CAN celei cu nu CAN si multiplexor. Aceasta solutie aduce o imbunatatire a vitezei de lucru. Pentru structura maximala a lantului de prelucrare principalii pasi facuti in scrierea unui canal analogic de iesire (AO) sunt:

denormarea datelor din gama unitatilor ingineresti in gama CNA 0 –2n-1 (n nr. de

biti din care se face conversia); separarea partilor High si Low ale datelor de convertit;

scrierea registrilor corespunzatori cu valorile dorite;

setarea amplificarii canalului de achizitie;

alegerea canalului achizitionat;

Driver-ul de scriere a unei iesiri analogice din sectiunea de cod urmatoare, este scris in C, iar adresa de baza a placii de achizitie este 0x220 h:

24

// definirea unor constante ce corespund adreselor // registrilor utilizati #define DAL0x224 #define DAH0x225 // functia de scriere a iesirii analogice 0 // – are ca parametru valoarea ce trebuie scrisa void ao0(int val)

{

unsigned char h,l; // separarea partii High de partea Low h=(unsigned char)(val/256); l=(unsigned char)(val%256); // scrierea registrilor corespunzatori partilor Low si High outp(DAL,l); outp(DAH,h);

}

In cazul in care echipamentul pentru care se dezvolta driverele este un sistem de tip microcontroller lucrurile sunt foarte asemanatoare. Pentru intrarile si iesirile numerice lucrurile stau mult mai simplu, operatiile respective fiind simple operatii de citire/scriere a unor valori in registri corespunzatori. Daca se doreste accesul doar la anumiti biti este utilizata inca o operatie suplimentara de “mascare”. Aceasta este efectuata ulterior citirii, respectiv anterior scrierii registrului respectiv. In general, orice firma producatoare de echipamente care se respecta ofera in pachetul ce contine dispozitivul achizitionat si un set de drivere si programe de test. In unele situatii pentru traductoate mai evoluate, driverele de achizitie sunt inlocuite cu drivere de comunicatie intr-un anumit protocol TCP/IP, Modbus etc [29], [30]. Aceste traductoare contin un echipament numeric (microcontroller) care face achizitia utilizand la nivel local utilizand un driver de tipul celor prezentate anterior.

25

6. Implementarea unor sisteme distribuite de conducere; Functiile unui program de monitorizare (SCADA);

SCADA reprezinta acronimul pentru Supervisory Control And Data Acquisition. In linii mari, termenul se refera la ansamblul sistemelor de achizitie, supervizare si control distribuite in cadrul unei vaste intinderi geografice sau spatiale si utlizate pentru conducerea unor instalatii sau procese fizice de mari dimensiuni. Exemple clasice de utilizare pot fi date din zonele sistemelor de distributie a apei, energiei electrice si termice, de prelucrarea a petrolului – rafinarii etc.

Strategia de programare prezentata in sectiunile anterioare este foarte utila in

dezvoltarea unor aplicatii de complexitate mica si medie pentru un numar mic de parametrii reglati si monitorizati. Pentru procesele industriale cu un numar mare de parametrii (>100, >1000) este necesara o structura hardware si software diferita. In general, functiile de baza al unui sistem de monitorizare si control pentru o aplicatie industriala complexa sunt urmatoarele:

achizitia semnalelor de la traductoare si trimiterea comenzilor catre elementele de

executie; reglare numerica a diferitilor parametrii;

afisarea valorilor instantanee ale diferitilor parametrii grupati in unul sau mai

multe sinoptice; alarmare la depasirea valorilor limita admise pentru fiecare parametru; inregistrarea evolutiei in timp a valorilor parametrilor; asigurarea facilitatilor de functionare in retea a sistemului; asigurarea sigurantei sistemului prin back-up-ul resurselor si structurilor critice; oprimizarea functionarii procesului.

asigurarea sigurantei sistemului prin back-up-ul resurselor si structurilor critice; oprimizarea functionarii procesului.
asigurarea sigurantei sistemului prin back-up-ul resurselor si structurilor critice; oprimizarea functionarii procesului.
asigurarea sigurantei sistemului prin back-up-ul resurselor si structurilor critice; oprimizarea functionarii procesului.
asigurarea sigurantei sistemului prin back-up-ul resurselor si structurilor critice; oprimizarea functionarii procesului.
resurselor si structurilor critice; oprimizarea functionarii procesului. Fig. 6.1 Exemplu de sistem SCADA simplu 26

Fig. 6.1 Exemplu de sistem SCADA simplu

26

Din punctul de vedere hardware exista foarte multe variante de realizare a unei astfel de structuri. Pe piata echipamentelor de automatizare exista o serie de firme cunoscute sau mai putin cunoscute ce ofera o multitudine de solutii in acest domeniu Siemens, ABB, Rockwell, Omron, National Instruments etc [33], [34], [30]. Exemple de sisteme SCADA mai simple sau mai complexe sunt prezentate in figurile 6.1 si 6.2:

sau mai complexe sunt prezentate in figurile 6.1 si 6.2: Fig. 6.2 Exemplu de sistem SCADA

Fig. 6.2 Exemplu de sistem SCADA complex

Componenta software a sistemului este in general, organizata pe doua niveluri:

nivelul de achizitie si reglare implementat pe microcontrolere/AP si nivelul consolelor operator. Vom detalia pentru cele doua niveluri cateva aspecte ale functiilor si constructiei acestora:

Software pentru nivelul de achizitie si control (microcontrolere/AP)

Adaptarea unui microsistem inteligent de achizitie la cerintele specifice aplicatiei de control si monitorizare se realizeaza printr-un software specializat care este conceput pentru a realiza urmatoarele operatii:

achizitia continua a semnalelor de la toate canalele de masura cu o rata de esantionare suficient de ridicata pentru a permite preluarea corecta si a zgomotelor care insotesc semnalul util pentru a evita fenomenul de «pliere» (aliasing) a spectrului zgomotului peste cel al semnalului util; calibrarea software a informatiei achizitionate pentru compensarea erorilor sistematice introduse de circuitele din sistemul de interfata analogica (offset-uri, erori de scala);

27

filtrarea numerica a semnalelor achizitionate in scopul eliminarii zgomotelor

utilizind filtre de tip trece-jos de ordin superior (in forma discretizata); realizarea calculelor de corectie asupra informatiei masurate de la traductoarele la

care sint necesare astfel de corectii;

inregistrarea informatiilor de la fiecare canal de achizitie intr-o baza de date locala pentru a evita pierderea de informatie la nivelul sistemului dispecer in cazul opririi accidentale a acestuia;

calculul unor marimi statistice (valorii medii, de virf, contorizare in vederea totalizarii consumurilor); comunicarea prin intermediul interfetei seriale cu sistemul dispecer adica asigurarea transmiterii la cerere a oricarei informatii din cele masurate, inregistrate sau calculate;

Se remarca faptul ca o serie din functiile enumerate mai sus sint prezente si in cadrul sistemului de conducere numerica (achizitia, calibrarea, filtrarea numerica, comunicatia) dar exista si o serie de functii noi specifice doar sistemului de monitorizare (calculul marimilor statistice si inregistrarea evolutiilor parametrilor).

Software pentru nivelul superior (consolele operador) Programul de baza al sistemului este conceput intr-un mediu de dezvoltare evoluat (Lab Windows/CVI [31], Borland C++ Builder, Visual C++ etc.) sau intr-un limbaj specific echipamentului utilizat (Simatic de la Siemens [34], RS View de la Rockwell [17], [18], [19] etc.). Acesta trebuie sa ofere utilizatorului implementarea unor functii de baza ca si orice alt limbaj de programare, precum si alte functii speciale ce implementeaza diverse protocoale de comunicatie, elemente de afisare grafica etc.

Functiile propuse pentru sistem sunt urmatoarele:

comunicatie cu sistemele microcontroller/AP realizand centralizarea datelor achizitionate;

aducerea datelor la un format stabilit si stocarea lor in baza de date;

setarea valorilor alarmelor pentru valori medii si instantanee;

determinarea situatiilor de alarma conform setarilor facute si stocarea acestora in baza de date;

vizualizarea valorilor instantanee, valorilor medii si a istoricelor;

semnalizarea situatiilor in care se constata probleme in functionarea sistemelor de tip microcontroller;

refacerea bazelor de date in cazul in care functionarea sistemului de gestiune a fost intrerupta.

Detaliem in continuare aceste functii:

Comunicatia cu microcontroller-ele Comunicatia se bazeaza pe interogarea echipamentelor aflate in camp sau in dulapurile speciale. Protocolul utilizat de programul de la nivelul PC-ului este de tipul comunicatiei seriale RS232/485, TCP/IP, FildBus, ModBus [17] etc. Programul are implementate functiile specifice acestui protocol.

28

Aducerea datelor la reprezentarea standard si stocarea lor

Este necesara aducerea datelor la un format care sa permita utilizarea lor cat mai usoara pentru rezolvarea necesitatilor utilizatorului. Trebuie specificat faptul ca formatul utilizat in comunicatie, din motive de optimizare, nu coincide cu formatul utilizat in PC in general si cu cel din baza de date, in special. In interiorul programului datele sunt reprezentate ca float sau double in functie de dimensiunea si precizia acestora. Operatie de normare se face conform formulei clasice:

v

UI

=

v

com

v

com _ min

v

com

_ max

v

com

_ min

(

v

UI

_ max

v

UI

_ min

)

+

v

UI

_ min

unde termenul “UI” – unitati ingineresti se refera la domeniul folosit pentru reprezentarea datelor pe consola, iar “com” – comunicatie respectiv, la domeniul folosit pentru transmiterea datelor. In general, domeniile de pe consola sunt cele reale (bari, m 3 /h, atm etc.) iar cele pentru transmitere sunt alese astfel incat pachetul de date sa aiba o dimensiune cat mai mica, pe de o parte, dar nici sa nu se piarda din precizia datelor.

Stocarea datelor Stocarea datelor se face in fisiere si/sau in baze de date in care, pe langa valorile respectivilor parametrilor sunt trecute data, ora si locul din care provin. Vizualizarea fisierelor poate fi facuta si cu alte produse software, de exemplu cu cele din cadrul pachetului Microsoft Office (Microsoft Excel). Din punctul de vedere al mecanismului de stocare al datelor (istorice) exista doua abordari:

doar atunci cand valoarea acestora se modifica cu cel putin o valoare de prag fata de valoarea anterioara.

stocarea acestora la intervale egale de timp – la fiecare perioada de esantionare sau,

Prima varianta este mare consumatoare de spatiu de memorie, uneori inutil deoarece se intalnesc situatii in care, pe un anumit interval de timp valoarea parametrului respectiv este constanta, insa ofera avantajul realizarii istoricelor fara nici o alta prelucrare. Cea de-a doua varianta nu consuma spatiu de memorie inutil, insa necesita calcule speciale (de tip extrapolare) la realizarea istoricelor pe intervale specificate. Un exemplu de astfel de fisier istoric este urmatorul:

3

PR_244 17:31:03 03-21-2001

4.949 barr

1 FR_244 17:31:08 03-21-2001

0.953 m3/h

2

PR_201 17:31:09 03-21-2001

7.486 barr

22

TE_274 17:31:31 03-21-2001

64.523 gr.C

3

PR_244 17:31:46 03-21-2001

6.509 barr

28

TI_274 17:31:50 03-21-2001 331.375 gr.C

29

Coloanele respective reprezinta codul numeric al parametrului, numele acestuia, amprenta de timp, valoarea respectiva si unitatea de masura.

Setarea si inregistrarea valorilor alarmelor Programul trebuie sa permite ca intr-o fereastra speciala sa poata fi fixate valorile de alarmare pentru un parametru dorit conform domeniului real de lucru utilizat. Depasirea in timpul functionarii a unei limite de acest tip, duce la deschiderea unei ferestre speciale pentru atentionarea personalului de supraveghere. In acelasi timp, in baza de date este inscrisa aceasta situatie pentru a permite realizarea ulterioara a unui raport privind functionarea sistemului. Setarea alarmelor se face de catre utilizator. Sesizarea situatiilor de depasire se face din punctul de vedere al programului, cu ajutorul unor structuri de tip if-then-else:

// depasire de limite if((marime[i].val>marime[i].alarma_max)||(marime[i].val<marime[i].alarma_min))

{

pozitie_alarma=1;

// schimbarea fondului controlului corespunzator marimii

SetCtrlAttribute

(hand_pan,

tab_coresp[i].control,

ATTR_TEXT_BGCOLOR, VAL_RED); if(marime[i].activare_al)

{

// scriere in fisierul de alarme ScriereAlarma(i, marime[i].val); ………………………………

}

}

Vizualizarea datelor Reprezentarea valorilor parametrilor se face in general, numeric si grafic. Afisarea numerica prezinta avantajul de a prezenta valorile lor exacte; Afisarea grafica are avantajul de a fi mai usor perceputa din punctul de vedere al domeniului de variatie, aceasta facadu-se in detrimentul preciziei. Parametrii sunt grupati in ferestre, in functie de tipul lor (de exemplu consumul de abur la nivelul grupurilor functionale), de grupurile functionale (exemplu consumul de energie electrica si utilitati la nivelului instalatiei respective).

Informatiile numerice sau grafice sunt dispuse pe sinopticele instalatiilor sau pe cele ale grupurilor functionale oferind posibilitatea unei perceptii rapide si clare a situatiilor curente. Un exemplu de sinoptic este oferit de figura urmatoare:

30

Fig. 6.3 Exemplu de sinoptic al unei instalatii petrochimice Asa cum s-a precizat anterior, aparitia

Fig. 6.3 Exemplu de sinoptic al unei instalatii petrochimice

Asa cum s-a precizat anterior, aparitia unei alarme este imediat semnalata prin deschiderea unei ferestre in care se specifica pe langa valorile respective, toate informatiile necesare localizarii parametrului in cadrul celorlalte ferestre sau sinoptice. Istoricele prezinta evolutia unui parametru selectat impreuna cu incadrarea acestuia fata de valorile alarmelor setate. Intervalul fereastrei de afisare este stabilit de utilizator. Sistemul trebuie sa ofere usurinta unei eventuale extinderi, dand posibilitatea atasarii de program a unor module care pot transmite informatiile centralizate si altor calculatoare conectate la aceeasi retea locala sau chiar pe Internet, pastrandu-se confidentialitatea datelor.

Semnalizarea situatiilor de functionare anormala Daca in cadrul comunicatiei, este depasit timpul maxim de raspuns al unui microcotroller se mai incearca inca o data contactarea echipamentului si daca nici de aceasta data nu se raspunde este semnalata functionarea defectoasa a acestuia. Un alt caz de functionarea defectoasa este primirea unor mesaje care nu mai respecta criteriile de integralitate impuse. Integralitatea mesajelor este in general, asigurata de sistemul de operare impreuna cu echipamentul hardware aferent canalului de comunicatie utilizat. Apar situatii in care datorita unor perturbatii, informatia este afectata in asa fel incat nivelele inferioare nu detecteaza acest lucru, din aceasta cauza fiind necesara unei verificari si din partea programului.

31

Generarea unor rapoarte statistice Functie importanta a sistemului dispecer, generarea de rapoarte ofera informatii sintetice referitoare la consumurile totale contorizate pe diferite perioade de analiza precum si la valorile medii si de virf ale acestora. Generarea acestor rapoarte se realizeaza prin efectuarea unor calcule statistice asupra informatiei inregistrate in intervalele de timp respective. Aceasta presupune fie existenta acestor inregistrari in sistemul dispecer, fie preluarea acestora din microsistemele de achizitie. Rapoartele se pot lista la imprimanta locala sau pot fi transmise unui sistem de gestiune superior pentru a permite efectuarea calculelor economice pe baza informatiilor referitoare la consumuri, productie si stocuri inregistrate la nivelul sistemului de monitorizare.

Sincronizarea informatiilor din reteua consolelor utilizator Unul din motivele existentei mai multor console utilizator este necesitatea asigurarii redundantei sistemului. Aceasta presupune ca aceleasi informatii pot fi gasite pe oricare din console, pentru ca in momentul in care una din acestea se defecteaza, intreaga instalatie sa ramana sub control. Nu se accepta situatii in care aceeasi stare a instalatiei este reprezentata pe console cu valori diferite. Situatii dramatice pot apare in cazul unor stari binare ON/OFF. Informatii critice ce trebuiesc sincronizate sunt: parametrii setati pentru regulatoare, regimul regulatoarelor (automat - manual) domeniile de variatie al parametrilor, limitele de alarmare etc. In general aceste informatii sunt tinute in fisiere speciale pe fiecare statie (fisiere de configurare) si in registii microcontrollerului (master). In momentul in care pe una din statii un parametru critic este modificat, cealalta statie trebuie sa isi actualizeze fisierele de configuratie si starea (de lucru) a programului.

32

7. Implementarea unei aplicatii de conducere la distanta;

Multe aplicatii ale controlului automat presupun utilizarea unor date aflate la distante foarte mari. Accesul la aceste date poate fi facut pe mai multe cai de comunicatie cum sunt: liniile telefonice, comunicatia radio, Internet, retele special dedicate etc. Fiecare din aceste cai ofera avantaje si dezavantaje din punctul de vedere al unor criterii cum sunt cele de pret, intretinere, viteza, cantitate de informatie transmisa in unitatea de timp, siguranta etc. Pentru aplicatii cu un grad relativ scazut de complexitate si responsabilitate tehnologica, in care timpul de raspuns nu este un factor critic, reteaua Internet reprezinta o cale de comunicatie ieftina si facila. Acest fapt este datorat extraordinarei intinderi a acesteia si a costurilor mici de exploatare si intretinere. Exemple de aplicatii cu o comunicatie bidirectionala din aceasta gama pot fi date din domeniul educational si din cel industrial. In domeniul educational principalele aplicatii intalnite sunt cele ce sustin mai noul concept de “ODL” – Open Distance Learning. Acest concept presupune accesul cursantilor atat la informatiile cursurlor si “laboratoarele” virtuale cat si la facilitatile de testare a cunostintelor. Este evident ca cea mai interesanta “laboratorul sau instalatia virtuala” ce presupune efectuarea de la distanta a unor lucrari ca si cum cursantul/operatorul s-ar afla langa echipamentul pe care se face experimentul. In general, datele vehiculate contin parametrii experimentului precum si valorile culese din acesta. In domeniul industrial exemplele pot contine preluari si setari de parametrii calitativi ai proceselor conduse (medii ale valorilor unor anumiti parametri, cantitati consumate, referinte etc.). Datorita faptului ca reteua Internet este o retea publica, in functie de importanta vitala a informatiilor vehiculate, de la caz la caz, se pot impune restrictii privind accesul, codificarea si criptarea informatiilor. Acest gen de aplicatii presupun comunicarea bidirectionala intre doua calculatoare personale sau mai general schimbul de mesaje intre doua adrese din retea. Protocolul de comunicatie disponibil in reteaua Internet ce ofera facilitatile cerute de aceste clase de aplicatii este TCP/IP [30]. Din punct de vedere istoric, protocoalele TCP (Transfer Control Protocol) si IP (Internet Protocol) au fost dezvoltate de in cadrul unor proiecte de cercetare ale Departamentului Apararii al SUA ce urmareau conectarea unui numar cat mai mare de retele dezvoltate de producatori diferiti. Initial au fost gandite pentru a asigura transferul de fisiere, preluarea postei electronice, conectarea si conducerea unor aplicatii de la distanta. Datorita robustetii si facilitatilor oferite pentru integralitatea mesajelor aceste protocoale s-au impus fiind azi o componenta de baza a comunicatiei in majoritatea retelelor de calculatoare. Nu vom insista asupra modului de functionare si constructie informatii amanuntite de acest gen existant in multe publicatii de profil. Mai mult, subliniem ca datorita importantei sale, acesta a fost inclus in anumite servicii ale sistemelor de operare

33

existente Windows, Unix etc. precum si in programele si mediile de dezvoltare ce ruleaza sub aceste sisteme. Fara a intra in amanunte, comunicatia utilizand TCP/IP presupune existenta unei aplicatii server si a uneia sau mai multor aplicatii client. La initializare, aplicatia server este activata si rezerva unul sau mai multe porturi (soket-uri) de comunicatie cu aplicatiile client. Aplicatiile client se conecteaza la aplicatia server si primesc sau transmit date pe porturile (denumite si soket-ti de comunicatie) pe care s-au conectat. Identificarea unui port rezervat de server pentru comunicatie se face dupa IP-ul (adresa de retea) echipamentului pe care ruleaza aplicatia server si numarul efectiv al portului. In general, mediile de dezvoltare cum sunt Visual C++, Borland Builder C++, LabWindows/CVI etc. ofera functii sau “obiecte” speciale pentru utilizarea acestui protocol. Fiecare din aceste medii de dezvoltare isi rezerva modul de proiectare al respectivelor functii si al parametrilor lor. In cele ce urmeaza ne vom referi la mediul de dezvoltare LabWindows/CVI [31] si la functiile aferente acestuia. Dialogul intre aplicatia server si cea client se face prin intermediul a doua functii, cate una inclusa in fiecare aplicatie. Din punct de vedere functional cele doua au un rol foarte apropiat cu cel al functiilor de tratare al intreruperilor. Ele tratazea avenimentele generate de protocolul TCP/IP. Numele generice ale celor doua functii sunt:

// pentru aplicatia client int ClientCallback(unsigned handleTCP, int event, int error, void *callbackData) // pentru aplicatia server int ServerCallback(unsigned handleTCP, int event, int error, void *callbackData)

Evenimentele de activare sunt:

TCP_DISCONNECT – ce atentioneaza serverul ca aplicatia client sa deconectat,

sau aplicatia client ca serverul a inchis conexiunea; TCP_DATAREADY – ce atentioneaza serverul ca a fost primit un mesaj de la un client, sau un client ca serverul a trimis un mesaj.

TCP_CONNECT – ce atentioneaza serverul ca un client s-a conectat;

Din punctul de vedere al serverului, primirea unui mesaj de tip TCP_CONNECT poate insemna inceperea transmiterii de pachete de date catre client, iar primirea unui mesaj TCP_DISCONNECT incetarea acesteia. Evenimentul TCP_DATAREADY este urmat in general, atat pentru aplicatia server cat si pentru cea client de citirea portului de communicate utilizat (denumit si soket de comunicatie). Citirea datelor se face cu urmatoarele functii:

// pentru aplicatia client int ClientTCPRead ( unsigned int Conversation_Handle, void *Data_Buffer, unsigned int Data_Size, unsigned int Time_Out);

34

// pentru aplicatia server

int ServerTCPRead ( unsigned int Conversation_Handle,

void *Data_Buffer, unsigned int Data_Size, unsigned int Time_Out);

Trimiterea datelor catre cealalta aplicatie este facuta cu ajutorul unor functii al caror prototip este urmatorul:

// pentru aplicatia client

int ClientTCPWrite ( unsigned int Conversation_Handle,

void *Data_Buffer, unsigned int Data_Size, unsigned int Time_Out);

// pentru aplicatia server

int ServerTCPWrite ( unsigned int Conversation_Handle,

void *Data_Buffer, unsigned int Data_Size, unsigned int Time_Out);

Pentru construirea unui program server, pasii principali sunt urmatorii:

declararea prototipului si construirea functiei de tratare a evenimentelor de comunicatie;

construirea functiei de trimitere a datelor catre clienti.

construirea functiei de declarare a aplicatiei server;

Construirea programului client va include in mod necesar pasii:

declarearea prototipului si construirea functiei de tratare a evenimentelor de comunicatie;

construirea functiei de trimitere a datelor catre server.

construirea functiei de conectare a aplicatiei client;

O atentie deosebita va fi acordata structurii datelor vehiculate intre aplicatiile

server si client. Proiectarea acestora incepe cu definirea cat mai clara a rolului ocupat de programele client si sever in cadrul scopului general urmarit. De exemplu: programul server ruleaza in cadrul unei aplicatii de reglare numerica in care referinta algoritmului de reglare si regimul de lucru (manual/automat) poate fi modificat atat de pe statia de lucru respectiva cat si de la distanta, de undeva de pe Internet.

In acest caz aplicatia server va trimite periodic catre client valorile marimii reglate

a procesului, referinta, comanda si regimul de lucru al algoritmului. La randul sau clientul va trimite catre server in caz de modificare, noile valori ale referintei, regimului de lucru

si

al comenzii manuale in caz de functionare in regim manual. Ambele structuri ale datelor trimise vor fi prezente atat pe server cat si pe client.

O

exemplificare pot fi si urmatoarele structuri:

// vector de date transmise de server si receptionate de client typedef struct

{

int regim;

float masura;

35

float comanda; float referinta;

} vector_tr_server;

// vector de date trimise de client si receptionate de server typedef struct

{

int regim; float referinta; float comanda_m;

} vector_tr_client;

Un alt aspect interesant ce trebuie avut in vedere la constructia aplicatiei client este evitarea fenomenului de repetare inutila a unei comenzi datorat faptului ca latenta comunicatiei impiedica actualizarea instantanee a datelor de pe ruta client-server-client. In general, tot datorita intarzierii in transmiterea pachetelor de date, trebuiesc luate precautii deosebite privind importante datelor vehiculate si prevazute si detectate situatiile in care linia de comunicatie este intrerupta. Cea mai utilizata solutie este cea in care pentru pachetele ce contin informatii vitale este ceruta confirmarea receptionarii acestora. Pachetul de confirmare poate contine chiar valorile receptionate pentru a fi comparate cu cele trimise. Lucrurile se complica in momentul in care este necesara criptarea datelor pentru a limita accesul la vehicularea lor. Exista solutii utilizate si alte domenii ce pot fi adoptate si in controlul automat.

36

Bibliografie

[1] Baribaud G. et al., "Recommendations for the Use of Fieldbuses at CERN in the LHC Era", Proceedings of the 1997 International Conference on Accelerator and Large Experimental Physics Control Systems, Beijing, 1997, p.285.

[2] Barillere R. et al., "Results of the OPC Evaluation done within the JCOP for the Control of the LHC Experiments", Proceedings of the 1999 International Conference on Accelerator and Large Experimental Physics Control Systems, Trieste, 1999, p.511.

[3] Daneels A., W.Salter, "Selection and Evaluation of Commercial SCADA Systems for the Controls of the CERN LHC Experiments", Proceedings of the 1999 International Conference on Accelerator and Large Experimental Physics Control Systems, Trieste, 1999, p.353.

[4] Daneels A., W.Salter, "Technology Survey Summary of Study Report", IT-CO/98-08- 09, CERN, Geneva 26 th Aug 1998.

[5] Dumitrache I., Buiu C., Ghica O. (2002). Sisteme numerice pentru conducerea proceselor. Editura Electra, Bucureşti.

[6]

Dumitrache

I.,

S.

Dumitriu,I.

Mihu,Fl.

Munteanu,Gh.

Musca,G.

Calcev,

Automatizari electronice, E.D.P., Bucuresti, 1993

[7] Khalil, Hassan K. (2001). Nonlinear Systems. Prentice Hall. ISBN 0-13-067389-7.

[8] Lazar C., O. Pastravanu, E. Poli, F. Schonberger, Conducerea asistata de calculator a proceselor tehnice – Proiectarea si implementarea algoritmilor de reglare numerica, Matrix Rom, Bucuresti, 1996

[9] Munteanu F., Musca Gh., Moraru F., C Tehnici de programare, Joint Printing House, Bucuresti, 1995.

[10] Popescu D., Lupu C., C. Petrescu, M. Alexandru, M. Mateescu, Sisteme de Conducere a Proceselor, Editura Printech, Bucuresti 2004, ISBN 973-718-016-X

[11] Richard Goering, Embedded Developer Survey Reveals Debugging Challenges, EETimes, May 11, 2007

[12] ELWE Operating Manual Controlled Air Mass and Temperature System with Actuators and Sensors LTR701 2002 ELWE-Lehrsysteme GmbH

[13] National Instruments. Data acquisition.

[14] Rockwell Automation (2005) – Logix 5000 Process Control, Logix 5000 General Instructions.

37

[15] Rockwell Automation (2005) – Logix 5000 Controllers System Reference, Logix 5000 PIDE.

[16] Rockwell Automation (2005) – ControlLogix Analog and Digital I/O Modules user manual.

[17] Rockwell Automation (2005) – Logix 5000 Ethernet Modules user manual.

[18] Rockwell Automation (2005) – RSView SE user manual, RSLinx Professional user manual

[19] Rockwell Automation. Control Logix 5000. RSView.

38