Capitolul 8

Implementarea unor aplicaţii de timp real

După cum s-a abservat din cele prezentate până în prezent, mediul
MATLAB/Simulink/RTW reprezintă un cadru propice pentru dezvoltarea unor aplicaţii de timp
real. Acest lucru nu înseamnă că MATLAB/Simulink/RTW este pretabil pentru comercializarea
unor aplicaţii industriale de timp real deoarece ar însemna ca beneficiarul să achiziţioneze
întregul mediu (cu un preţ de achiziţie destul de mare, aproximativ 12000 $) şi apoi să intre în
posesia aplicaţiei de timp real cu o interfaţă implementată în Simulink.
Ceea ce face acest mediu deosebit de atrăgător este faptul că, pentru prima oară, un inginer
automatist este pus în situaţia de a parcurge toate etapele corespunzătoare unui proces de
proiectare folosind un software unitar şi o placă de achiziţii de uz general. Se poate spune că
procesul de proiectare, implementare şi testare a unei bucle de reglare s-a standardizat.
Inginerul automatist porneşte de la formularea problemei de automatizare. Aceasta
presupune cunoaşterea modelului şi a parametrilor modelului părţii fixe. Dacă acesta nu este
cunoscut, folosindu-se placa de achiziţii şi Data Acquisition toolbox, Signal Processing toolbox,
Control system toolbox sau Identification toolbox, se poate determina un model aproximativ al
părţii fixe. Folosind-se acest model şi o serie de tehnici de proiectare se poate determina
regulatorul care conduce la performanţele dorite în bucla de reglare închisă. Acest algoritm de
reglare se poate testa fie sub formă continuală fie sub formă numerică (algoritm numeric de
reglare) folosindu-se mediul MATLAB/Simulink. În acest mediu se pot introduce o serie
întreagă de elemente neliniare (saturaţii, zone de insensibilitate, histerezis) precum şi blocuri de
întârziere care să facă simularea cât mai aproapiată de realitate.
În continuare, folosindu-se extensia RTW/Real-Time Windows Target sau alte extensii ale
mediului MATLAB/Simulink, se poate trece direct de la modelarea sistemului de reglare la
testarea comportamentului său în timp real, ajungându-se la implementarea aşa-numitului
Hardware-in-the loop: algoritmul numeric de reglare obţinut este compilat într-un executabil de
timp real care comunică cu exteriorul prin intermediul plăcii de achiziţii. Placa de achiziţii este
conectată la grupul (element de execuţie + instalaţia tehnologică + traductoare) ce formează
partea fixă propriu-zisă. Lansarea în execuţie a executabilului de timp real conduce la
posibilitatea testării în timp real, efectivă, a comportamentului sistemului de reglare şi la
posibilitatea de a concluziona dacă algoritmul proiectat este acceptabil sau nu.
Dacă rezultatele corespund cerinţelor de proiectare, atunci acest algoritm se validează şi se
trece la faza de implementare industrială a sa fie pe diverse automate programabile, fie pe
regulatoare numerice, fie pe diferite calculatoare de proces. Evident, modul de implementare
depinde tipul de echipament folosit precum şi de sotware-ul de proces adoptat.
Dacă rezultatele testării în timp real a sistemului de reglare nu sunt satisfăcătoare, se poate
relua procesul de proiectare prezentat anterior fie de la identificarea mai bună a părţii fixe
(modelul diferă prea mult de partea fixă reală), fie de la reproiectarea regulatorului.
Se implementează astfel un proces iterativ de proiectare-testare în timp real care conduce
în final la adoptarea celei mai bune soluţii într-un timp mult mai mic şi cu rezultate mult mai
bune decât în procesul clasic de proiectare a unui SRA.
Întregul proces de proiectare este reprezentat schematic în figura de mai jos (Fig. 1).
Distingem în schema din Fig. 1 trei medii distincte: MATLAB, Simulink precum şi
extensia de timp real a Simulink. Această extensie este, începând cu MATLAB Release 13,
Real-Time Windows Target. O serie întreagă de producători pot adăuga şi propriile extensii care
să le facă produsele mai accesibile din mediul MATLAB/Simulink.
Vom exemplifica acest lucru cu ajutorul mediului experimental produs de firma Quanser
Consulting (Canada).

124
 Modelare
Model
Parte Fixă
Identificare
Testare în
Proiectare Simulink
Parte Fixă
Regulator a SRA
Reală

Element Model
Traductor Testare în Regulator
Execuţie
MATLAB
MATLAB Simulink
a SRA

C C
N A
A N
Hardware-in-the-loop
(testare în timp real)

Algoritm de RTW
Reglare Numeric în Real-Time Windows Target
timp real WinCon

Fig. 1. Arhitectura generală de modelare, proiectare, simulare şi testare în timp real

8.1. Introducere în mediul Quanser/WinCon

Această firmă este producătoare de materiale experimentale pentru controlul automat. Ea
produce platforme experimentale ce implementează o serie de experimente de reglare automată
care implică toate etapele unui proces de proiectare a unui sistem de reglare automată. Marea
calitate a acestor platforme constă în faptul că ele sunt total compatibile cu mediul de calcul,
modelare şi simulare MATLAB/Simulink la care adaugă o extensie de timp real pentru a putea
testa în timp real performanţele regulatorului proiectat.
WinCon™ este o aplicaţie de timp real implementabilă sub Windows 98/NT/2000/XP. Ea
permite rularea în timp real a codului generat direct din diagrama Simulink. Execuţia în timp real
se poate face pe acelaşi PC (cunoscut sub numele de PC local, local PC) sau pe un PC aflat la
distanţă (remote PC). Datele provenite de la codul ce se execută în timp real pot fi plotate on-line
pe osciloscoapele din WinCon (WinCon Scopes) iar parametrii regulatorului se pot modifica în
timpul execuţiei în timp real prin intermediul panourilor de control (WinCon Control Panels)
precum şi din Simulink. Modelul Simulink din care provine executabilul de timp real devine o
interfaţă cu executabilul prin intermediul căreia putem modifica parametrii regulatorului.
Codul de timp real generat automat din diagrama Simulink constituie un controller de sine-
stătător (adică independent de mediul Simulink) şi poate fi salvat în proiecte WinCon (WinCon
Projects) împreună cu osciloscoapele configurate de utilizator şi panourile de control.
Software-ul WinCon constă în fapt din două părţi distincte: WinCon Client and WinCon
Server. Ele comunică folosind protocolul TCP/IP. WinCon Client rulează în timp real
implementat hard (hard realtime) pe când WinCon Server este o interfaţă grafică separată care
rulează în mod utilizator (user mode).
Configurarea locală şi la distanţă
WinCon suportă două configuraţii posibile: configuraţia locală (adică pe un singur PC) şi
configuraţia la distanţă (adică pe două sau mai multe PC-uri).

125
 În configuraţia locală, WinCon Client, executând codul de timp real, rulează pe aceeaşi
maşină şi în acelaşi timp cu WinCon Server (adică interfaţa grafică în mod utilizator, user-mode
graphical interface).
În configuraţia la distanţă, WinCon Client rulează pe o maşină separată de WinCon Server.
Cele două programe comunică întotdeauna folosind protocolul TCP/IP. Fiecare WinCon Server
poate comunica cu mai multe WinCon Clients, şi reciproc, fiecare WinCon Client poate
comunica cu mai multe WinCon Servers.
Configuraţia locală
Configuraţia locală este prezentată în Fig. 2.

Real-time Windows Windows 98

Fig. 2. Configuraţia locală în cele două ipostaze

Se observă cum configuraţia locală are două ipostaze. Prima, cea mai modernă, dispune de un
kernel de timp real numit RTX. RTX este o extensie de timp real a sistemului de operare
Windows şi este un software produs de firma VenturCom (USA).

Fig. 3. Instalaţia de controlat

126
Placa de achiziţii (data acquisition card), în Fig. 2 de tipul MultiQ, se foloseşte pentru a interfaţa
codul de timp real cu instalaţia de controlat (în laborator instalaţia de controlat este un
servomotor cuplat la un sistem de roţi dinţate şi la o serie de traductoare potenţiometrice rotative,
grup denumit Quamser Consulting Plant SRV-02 în Fig. 3). Utilizatorul interacţionează cu codul
de timp real fie prin intermediul WinCon Server fie prin intermediul diagramei Simulink a
modelului din care a provenit, care este utilizată în modul Extern. Datele provenite de la
controller (WinCon Client) se pot plota în timp real de către osciloscoapele din WinCon Server
iar schimbarea unor valori din diagrama Simulink va schimba automat, prin intermediul WinCon
Server, parametrii corespunzători din codul de timp real. Codul de timp real (adică WinCon
Client), rulează pe acelaşi PC cu codul utilizator al WinCon Server. Totuşi, codul de timp real are
întâietate asupra oricărui alt proces, deci performanţele hardware de timp real vor putea fi atinse.
Software-ul necesar pentru implementarea testării în timp real
Windows 98 Windows NT/2000/XP
- MATLAB/Simulink/RTW - MATLAB/Simulink/RTW
- Microsoft Visual Studio (C/C++) - Microsoft Visual Studio (C/C++)
- WinCon Server/WinCon Control/WinCon Client - RTX (ver. 4.3.2.1. în sus)
- Drivere placa de achiziţii Sensoray 626 - WinCon Server/ Control/ Client
- Drivere placa de achiziţii Sensoray 626
Pentru a putea folosi un mediu hardware-in-the-loop de timp real este necesar un proces de
configurare. Cel mai puţin pretenţios este cel sub Windows 98. Paşii necesari în procesul de
configurare sunt următorii:
1. Se instalează MATLAB/Simulink/RTW (MathWorks, Release 12 sau 13)
2. Se instalează Microsoft Visual Studio 6.0 (Microsoft). Se configurează în MATLAB
utilitarele mex şi mbuild pentru compilatorul Microsoft (cu opţiunea –setup)
3. Se instalează WinCon Server (Quanser)
4. Se instalează WinCon Control (care implementează biblioteca de timp real)
5. Se instalează placa de achiziţii cu driverele corespunzătoare. Pentru aceasta procedăm
astfel:
a. Se copiază manual fişierul S626.dll din subdirectorul
sensoray_626\sdk626\windows în subdirectorul windows\system\
b. Se copiază manual fişierul SXDRV98.dll din subdirectorul
sensoray_626\sdk626\windows\Install 98-ME-2000-XP în subdirectorul
windows\system32\drivers\
c. Se porneşte calculatorul cu placa de achiziţii MultiQ-PCI (Sensoray 626)
conectată la un slot de extensie PCI. Automat, la pornire, Windows 98 lansează
sistemul plug-and-play care va sesiza noul hardware şi va întreba de locul în care
va găsi driverele corespunzătoare. Se va indica subdirectorul
sensoray_626\sdk626\windows\Install 98-ME-2000-XP
6. Se instalează WinCon Client
7. Se restartează sistemul
Pentru instalarea sub sisteme de operare mai complexe, procesul este mai pretenţios. Spre
exemplu, în funcţie de sistemul de operare, este nevoie minim de Microsoft Visual Studio 6.0
SP5 (Service Pack 5) şi de instalarea prealabilă a kernelului de timp real RTX cu varianta
minimă RTX 4.3.2.1. În mod uzual, se foloseşte RTX 5.1 sau RTX 6.0.
Modul în care aplicaţia de timp real comunică cu hardware-ul implementat pe placa de achiziţii
în modul prezentat în Fig. 4.
Este necesară o instalare completă şi corectă a plăcii aşa cum s-a prezentat mai sus pentru ca
placa de achiziţii să poată fi gestionată corect sub sistemul de operare de care dispunem.

127
 Fig. 4. Diagrama bloc a ierarhiei software
În cazul în care se foloseşte unul dintre sistemele de operare Windows 98/Me/2000/XP atunci
sunt necesare următoarele drivere:

Configuraţia la distanţă
În această configuraţie cele două componente principale, WinCon Server şi WinCon Client
rulează pe două calculatoare diferite, comunicaţia făcându-se printr-un protocol de tip TCP/IP
(vezi Fig. 5).
O configuraţie la distanţă mai complexă este prezentată în Fig. 6. şi constă într-un server
care gestionează mai mulţi clienţi.
Calculatoarele pe care rulează clienţii sunt legate într-o reţea şi au posibilitatea de
comunicaţie prin intermediul acestei reţele

128
 Fig. 5. Configuraţia la distanţă: arhitectura cu 2 PC-uri

Fig. 6. Configuraţia la distanţă: arhitectura cu mai multe PC-uri

Principiile de operare ale WinCon

WinCon Server
WinCon Server este o componentăsoftware care realizează următoarele funcţii:
 Conversia unei diagrame Simulink în cod sursă C folosind Real-Time Workshop (RTW).
 Compilarea şi link-editarea codului sursă generat, folosind mediul Microsoft Visual C++,
pentru a crea executabilul de timp real de tip WinCon Controller Library (*.wcl).
 Download-area fişierului tip WinCon Controller Library (.wcl) către WinCon Client
pentru execuţie.
 Pornirea şi oprirea codului de timp real de pe WinCon Client (de la distanţă, prin reţea, în
cazul unei configuraţii la distanţă configuration).
 Menţinerea unei comunicaţii TCP/IP cu orice WinCon Client conectat.
 Menţinerea unei comunicaţii cu Simulink pentru a realiza modificarea în timp real a
parametrilor regulatorului. De exemplu, dacă se modifică în Simulink valoarea unui bloc
de amplificare (Gain block), atunci WinCon Server transmite această informaţie către
WinCon Client şi schimbarea se operează imediat în controllerul (codul de timp real) care
rulează.
 Efectuarea de schimbări în parametrii controllerului folosind panourile de control definite
de utilizator (user-defined Control Panels).
 Afişarea fluxurilor de date care provin de la codul de timp real via WinCon Client.
 Salvarea datelor de timp real pe disc sau/şi în MATLAB workspace.

129
 WinCon Client
WinCon Client este o componentă software de timp real care rulează codul de timp real generat
dintr-o diagramă Simulink la frecvenţa de eşantionare specificată. Ea poate îndeplini următoarele
sarcini:
 Recepţionarea codului controllerului în forma unui fişier de tip WinCon Controller
Library (.wcl) de la WinCon Server.
 Rularea controllerului în timp real.
 Menţinerea comunicaţiei cu orice WinCon Server conectat.
 Trimiterea unui flux de date în timp real către orice WinCon Server(e) care cere (cer)
acest lucru.
 Gestionarea timpilor de tranziţie definiţi de utilizatori pentru a controla cantitatea
maximă de CPU alocată codului de timp real

8.2 Nucleul de timp real (real-time kernel)

Codul de timp real este executat într-un mediu nucleu (kernel) de timp real (real-time
kernel environment), adică într-un sistem de operare ascuns în interiorul sistemului de operare
Windows. Denumirea de nucleu (sâmbure) de timp real ne sugerează modul în care a fost
conceput acest mini-sistem de operare care este inclus în sistemul de operare Windows.
Kernelul de timp real este implementat în diverse configuraţii, toate respectând o
arhitectură comună. RTW (MathWorks) implementează un astfel de kernel de timp real, după
cum RTX (Real-Time Extension for Windows) reprezintă un kernel de timp real produs de către
firma VenturCom.
Nucleul de timp real se instalează pe nivele de întreruperi prioritare (zero-level ring, inel
de nivel 0) faţă de toate celelalte întreruperi pe care le tratează sistemul de operare Windows. În
acest mod, orice cerere de întrerupere de nivel mic (prioritară) va întrerupe tratarea unei
întreruperi de nivel mai mare (mai puţin prioritară).
Întreruperile pentru nucleul de timp real vin de la ceasul de timp real al sistemului, deci
sunt perfect corelate cu timpul real. Orice întrerupere de nivel mic, tratată de către nucleul de
timp real, este tratată de către procesor integral, ea nemaiputând fi întreruptă de altă întrerupere
care nu poate fi decât de nivel mai mare.

Sistemul de operare
Windows
Echipamente ale Drivere Taskuri în
sistemului de calcul echipamente foreground

Întrerupere
ne-prioritară Rutine tratare
întreruperi Nucleu de timp real
sistem (RTW, RTX)
Microprocesor (ne-prioritare)
Rutine tratare
întreruperi
Timp real
Întrerupere (prioritare)
prioritară
Task de timp real
Placa de achiziţii (Controller)

Fig. 7. Sistemul de operare Windows cu extensie de timp real

130
 Putem să facem o distincţie între taskurile care se vor executa în prezenţa unei extensii de
timp real a SO Windows (care nu este un sistem de operare de timp real).
- taskurile obişnuite a căror execuţie este gestionată de către Windows se vor numi
foreground tasks. Execuţia lor nu are nici o legătură cu timpul real. Ele vor fi executate pe
rând de către Windows folosindu-se o partajare a timpului de execuţie a fiecărui task (time
sharing). Întreruperile utilizate de aceste taskuri sunt mai puţin prioritare, fiind de nivel
mai mare.
Taskurile de timp real sunt gestionate de către kernelul de timp real. Ele folosesc întreruperile
cele mai prioritare, de nivel imediat în jurul microprocesorului. Taskurile din foreground se vor
executa numai în timpul în care nu se tratează o întrerupere de timp real.
După cum se observă din Fig. 7, taskurile de timp real nu sunt executate de către Windows, ci
numai de către kernelul de timp real care este separat de sistemul de operare Windows. Din
această cauză există o serie de restricţii în ceea ce priveşte folosirea unor componente ale
sismului de operare Windows de către aplicaţiile de timp real.

8.3 Temporizarea evenimentelor de timp real

Fig. 8. Diagrama repartizării în timp a evenimentelor

Diagramele de timp din Fig. 8 ilustrează principiile operării în timp real. Sistemul sau
ceasul/timerul hardware generează întreruperi la intervale de timp fixe TS. TS este perioada de
eşantionare selectată de către utilizator.
Deoarece procesorul poate deservi şi alte întreruperi hardware sau cereri de acces direct la
memorie (direct memory access, DMA), o perioadă de timp nedeterminată va fi necesară pentru
ca procesorul să treacă la deservirea întreruperii venite de la controllerul implementat în forma
WinCon Client. Această durată de timp este referită drept perioadă de latenţă (latency period) TL.
Taskurile principale (foreground tasks, lansate de utilizator) afectează indirect această perioadă
de latenţă deoarece ele folosesc resurse hardware precum drivere video sau de harddisk. Chiar
dacă sub Windows NT/2000/XP toate operaţiile din foreground şi chiar operaţiile efectuate de
driverele de dispozitive rulează cu o prioritate mai mică decât codul de timp real, operaţiile
efectuate direct de către hardware, precum DMA, pot afecta perioada de latenţă. Se observă din
Fig. 8. cum latenţa (latecy) este variabilă.
La sfârşitul perioadei de latenţă, controllerul (executabilul de timp real implementat de
WinCon Client) efectuează calculele corespunzătoare momentului de eşantionare, calcule care
durează o perioadă TC. După ce controllerul completează toate calculele şi operaţiile de
131
intrare/ieşire, procesorul reia execuţia taskurilor din foreground (precum Simulink, LabVIEW,
etc.) până la apariţia unei noi întreruperi.
Perioada de eşantionare efectivă, TE, este intervalul de timp dintre două rutine de deservire a
întreruperilor (Interrupt Service Routines, ISR's) furnizate de către controller. Această perioadă
de eşantionare este variabilă şi depinde de timpul de latenţă (latency time).
Testele indică un timp de latenţă de ordinul zecilor de microsecunde sub Windows
NT/2000/XP, adică sub sistemele de operare sub care se execută mediul de timp real RTX.
Această valoare depinde de taskurile din foreground care rulează, de modul în care ele folosesc
resursele hardware ale calculatorului, precum şi de viteza sistemului (timpii de acces la memorie,
de transfer pe magistrală, de viteza microprocesorului precum şi a echipamentelor periferice).
Dacă se rulează o configuraţie la distanţă, deci dacă WinCon Client rulează pe un PC dedicat,
timpul de latenţă este sub 10 microsecunde. Întârzierile pentru efectuarea calculelor
(computational delay), TC, depind mai ales de complexitatea controllerului de timp real care
rulează. Scala de timp din Fig. 8 este oarecum exagerată de vreme ce controllere care să
consume mai mult de 50% din timpul procesorului şi care să conducă la asimetrii de execuţie
considerabile sunt rar întâlnite.
Un factor important de subliniat este că latenţa este relativ constantă, reflectând timpul
necesar pentru ca procesorul să recunoască o cerere de întrerupere cu bază de timp hardware (de
la untimer intern al PC-ului sau de la baza de timp a plăcii de achiziţii), pentru a încărca vectorul
de întrerupere şi pentru a invoca (CALL) rutina de deservire a întreruperii.
Deci, dacă latenţa este de aproximativ 10  sec pentru prima perioadă de eşantionare, va fi în
jurul acestei valori şi pentru celelalte momente de eşantionare. Din această cauză valoarea
actuală TE a perioadei de eşantionare va fi foarte aproape de perioada de eşantionare TS dorită şi
impusă de către noi. Eşantioanele sunt numai decalate cu intervalul de latenţă TL. Mai mult, cum
de obicei perioada de eşantionare este controlată de un timer hardware, perioada de eşantionare
medie va fi foarte precisă şi apropiată de cea dorită.
Alegerea perioadei de eşantionare
Determinarea celei mai mari frecvenţe de eşantionare (implicit a celei mai mici perioade de
eşantionare) depinde de cât de mare este puterea de calcul care este alocată taskurilor din
foreground. Spre exemplu un astfel de task este inclus în WinCon Server şi îl reprezintă afişarea
(plotarea în timp real) datelor de timp real furnizate de către controller (sub formă de cadre de
date, frames, pentru a spori viteza şi eficienţa). Timpul alocat acestor taskuri este (vezi Fig. 7)
TF = TE - TC.
De obicei se porneşte cu cea mai mică frecvenţă de eşantionare pentru procesul care se cere
controlat. Dacă se doreşte o frecvenţă mai mare se măreşte treptat această frecvenţă cu urmărirea
efectelor pe care le are această creştere de frecvenţă asupra taskurilor din foreground. Dacă
această frecvenţă de eşantionare creşte prea mult, atunci TE se micşorează corespunzător şi, la
fel, se micşorează şi TF. Rezultă mai puţin timp alocat de procesor pentru procesele din
foregriund, lucru vizibil prin încetinirea apreciabilă a vitezei mouse-ului sau a ploturilor de timp
real. Această degradare indică faptul că controllerul de timp real rulează prea repede pentru
resursele PC-ului folosit de către WinCon Client. Spunem acest lucru deoarece TC, timpul în care
controllerul face oparaţiile de intrare/ieşire şi calculele necesare, este dependent de viteza PC-
ului pa care rulează. Dacă PC-ul este mai performant, atunci TC se micşorează şi, implicit, TF se
măreşte. Fereastra WinCon Client oferă o statistică în ceea ce priveşte controllerul de timp real.

8.4 Descrierea WinCon Server şi WinCon Client

Fig. 9. Interfaţa grafică a WinCon Server

132
 Fig. 10. Semnificaţia icoanelor din interfaţa WinCon Server

WinCon Server generează sau foloseşte fişiere cu următoarele extensii:

Fig. 11. Interfaţa grafică a WinCon Client

133
8.5 Generarea unor aplicaţii de timp real sub WinCon
Vom prezenta prin exemple modul în care se dezvoltă o aplicaţie de timp real sub
RTW/WinCon.
Înainte ca un model Simulink să poată fi executat în timp real, trebuie generat mai întâi
codul de timp real. WinCon Server se foloseşte de Real-Time Workshop pentru generarea
codului de timp real.
WinCon Link şi WinCon Menu
După instalarea WinCon Server şi restartarea apare automat în bara de taskuri din background o
icoană WinCon Link aşa cum se arată în Fig. 12.

Fig. 12. Icoana WinCon Link şi meniul WinCon asociat în Simulink

Programul de instalare al The WinCon Server configurează sistemul pentru lansarea automată, la
încărcarea sistemului de operare (start-up), a WinCon Link. WinCon Link crează un nou meniu
în fereastra Simulink a modelului, numit WinCon, care apare în bara de meniuri a ferestrei.
Meniul WinCon conferă posibilitatea de genera şi a rula modelul în timp real fără nici un effort
special din partea noastră direct din diagrama modelului Simulink.
Setarea opţiunilor pentru Real-Time Workshop
Înainte de construirea unui controller de timp real sub WinCon pornind de la modelul Simulink
al acestui controller, trebuie să configurăm corespunzător opţiunile pentru Real-Time Workshop
pentru ca acesta să poată genera automat şi corect codul de timp real. În mod normal WinCon
configurează opţiunile implicite pentru diagramele Simulink noi şi deci acest pas nu este
întotdeauna. Opţiunea din meniu WinCon | Set WinCon Options, accesată din bara de meniuri a
ferestrei Simulink, se poate folosi pentru configurarea setărilor RTW corespunzătoare. Subliniem
în continuare câteva dintre setările cele mai importante, care trebuie configurate înainte de a
comanda procesul de generare de cod.

134
 Setări RTW

System target file
(Real-Time Workshop Tab)
Template makefile
(Real-Time Workshop Tab)
Make command
(Real-Time Workshop Tab)
Solver Fixed-Step Size
(Solver Tab)
Solver options
(Solver Tab)
Solver Mode
(Solver tab)
Descriere
Selectează fişierul Target Language Compiler wincon.tlc.
Fişierul wincon.tlc se găseşte în
C:\MATLAB6p5\rtw\c\Wincon\.
- pentru a genera cod pentru WinCon Client ce rulează
sub Windows NT/2000/XP, alegem: nt_msvc.tmf
- pentru WinCon Client ce rulează sub Windows 98,
alegem: win_msvc.tmf.
Se alege make_wc.
Se setează la valoarea dorită a perioadei de eşantionare TS (în
secunde. De menţionat că se va reconstrui (rebuilt) codul de
timp real la fiecare modificare a valorii perioadei de
eşantionare.
Alegerea metodei de integrare depinde, în anumite cazuri, de
controllerul folosit. Sunt suportate numai metode de integrare
cu pas constant. În mod tipic se foloseşte metoda ode1 (Euler).
Se setează pe Single-tasking. (o singură perioadă de
eşantionare)

Setarea opţiunilor Simulink

Înainte de construirea codului de timp real (WinCon real-time controller) din modelul Simulink,
trebuie să verificăm configurarea următoarelor setări:
- Simulation | External. Se verifică activarea acestei setări din Simulink window menu
bar. Dacă este selectată opţiunea Normal atunci Simulink va face doar o simulare în locul
unei comunicări cu codul de timp real via WinCon Server.
- External Target Interface. Din Simulink window menu bar, se selectează Tools |
External mode control panel... | Target interface... pentru a accesa fereastra External
Target Interface. Trebuie să fim siguri că fişierul MEX pentru external interface este
setat pe: wc_comm, cum se prezintă mai jos:

Generarea codului de timp real

Înainte de generarea codului de timp real, opţiunile Simulink şi RTW din diagrama ce se
doreşte executată se vor seta la valori corespunzătoare cu cele arătate mai sus.
Codul WinCon de timp real se poate genera folosind articolul WinCon | Build din Simulink
window menu bar, cum se arată în figura de mai jos.

135
Procedura Build generează un fişier de tip WinCon Controller Library (adică .wcl). Când
generarea de cod şi compilarea sunt complete, apare un mesaj în fereastra de comandă care
indică crearea cu succes a unui fişier . wcl. De exemplu, din modelul q_sine.mdl mesajul care
apare este:
### Created executable: q_sine.wcl
### Successful completion of Real-Time Workshop build procedure for
model: q_sine
După completarea cu succes a procedurii de construcţie (Build procedure), WinCon Server
transmite automat (automatically downloads) fişierul controller (cu extensia .wcl) către WinCon
Client, de unde poate fi executat.

8.6 Restricţii impuse asupra codului de timp real

WinCon suportă un număr foarte mare de blocuri Simulink, la fel ca şi blocurile Simulink
definite de utilizator. Există însă o serie de restricţii impuse diagramelor Simulink ce se folosesc
în timp real. Există de asemenea diferite restricţii impuse de către sistemul de operare ţintă. Spre
exemplu, Windows '98 este mai restrictiv decât NT, 2000 sau XP. Quanser recomandă folosirea
unui sistem de operare bazat pe un kernel de NT (Network, reţea), cum ar fi NT, 2000 sau XP.
Restricţiile impuse codului de timp real se referă la:
a) Apelul funcţiilor pe 32 de biţi (Win32 Functions) în codul de timp real
Pe toate platformele, WinCon suportă funcţii sistem definite de utilizator (user-defined S-
functions) scrise în C. Această capacitate este deosebit de utilă în special când ne interfaţăm cu
hardware construit de utilizator (custom hardware).
Totuşi, deoarece codul de timp real este executat de kernelul de timp real separat de
sistemul de operare Windows, şi anume de către kernelul de timp real care este inclus în
Windows dar care este izolat din punctul de vedere al tratării întreruperilor, funcţiile sitemului
de operare Windows nu pot fi apelate. Apelul unor funcţii ca MessageBox, spre exemplu, nu
este posibil deoarece codul funcţiilor de sistem (S-function code) rulează pe un sistem de operare
diferit (ascuns sistemului Windows).
În Windows NT/2000/XP, anumite funcţii din Win32 functions sunt emulate pentru a putea
fi folosite şi în timp real, deşi anumite funcţii oferă numai un subset funcţional în raport cu cel
implementat în mod normal sub Windows. În Windows '98, nici o funcţie din Win32 nu este
emulată.
b) Apelul funcţiilor din biblioteca C standard
Din acelaşi motiv pentru care marea majoritate a funcţiilor din biblioteca Win32 nu sunt
disponibile în mediul de timp real, există numai un subset limitat de funcţii din biblioteca C
standard disponibilă sub NT/2000/XP. Anumite funcţii posedă o funcţionalitate limitată.
În Windows '98, nici o funcţie din biblioteca C standard nu este disponibilă, în afară de
cele care sunt folosite in-line de către compilator, cum ar fi strcpy sau memset. De
remarcat că alocarea memoriei nu este posibilă într-un mediu de timp real implementat
sub Windows '98.

136
 c) Folosirea bibliotecilor cu legare dinamică în timp real
Bibliotecile cu legare dinamică (Win32 dynamic link libraries, DLLs) conţin cod executabil care
poate fi încărcat dinamic de către aplicaţiile care fac apel la astfel de funcţii. Cea mai mare parte
a sistemului de operare Windows este implementată sub formă de biblioteci cu legare dinamică.
Folosirea bibliotecilor cu legare dinamică permite ca mai mult decât o aplicaţie să partajeze
acelaşi cod precum codul funcţiilor din biblioteca C standard. Cum aceste biblioteci cu legare
dinamică sunt folosite foarte frecvent de cătrea o gamă largă de aplicaţii sub o formă partajată,
ele sunt incompatibile cu codul de timp real. Codul de timp real se compilează numai pentru
kernelul de timp real. Cum bibliotecile cu legare dinamică sunt în mod esenţial executabile pe 32
de biţi (Win32 executables), conţinând cod compilat pentru mediul Win32, ele nu pot fi
executate de către kernelul de timp real. Rezultă că bibliotecile cu legare dinamică nu se pot
folosi de către codul de timp real. Cum bibliotecile numerice folosite pentru compilare (third
party numerical libraries) sunt implementate ca biblioteci cu legare dinamică, la fel ca interfeţele
de programare a majorităţii driverelor de dispozitive, această restricţie este deosebit de
deranjantă. Dacă se pot obţine versiuni de biblioteci cu legare statică ale bibliotecilor cu legare
dinamică, această restricţie este depăşită (considerând că, la rândul lor, funcţiile din biblioteca cu
legare statică nu apelează altele cu legare dinamică).
d) Script-uri MATLAB
Programele MATLAB (MATLAB scripts, .m) se pot folosi pentru a controla WinCon, ele nu pot
fi folosite în codul de timp real. MATLAB este un limbaj interpretativ şi nu poate rula în timp
real. Mai mult, motorul MATLAB şi bibliotecile numerice nu au fost compilate pentru mediul de
timp real, deci nu este posibil să apelăm MATLAB din codul de timp real. În consecinţă, nu se
folosesc blocurile “MATLAB Fcn” din “Functions & Tables” într-o diagramă Simulink ce
va fi folosită pentru a genera cod de timp real.
e) Compilatorul MATLAB
MATLAB este un limbaj foarte convenabil pentru implementarea algoritmilor numerici. Este
deci foarte tentant să scriem S-funcţii folosind MATLAB în loc de C. Pentru a putea rula aceste
funcţii în timp real am putea crede că cea mai bună metodă este folosirea compilatorului de
MATLAB (MATLAB Compiler). Din păcate, nu este posibil. Codul generat de compilatorul
de MATLAB nu poate fi executat în timp real.
Problema nu constă în concepţia MATLAB ci în implementarea compilatorului de
MATLAB. Compilatorul MATLAB face uz intensiv de biblioteci cu legare dinamică pentru
implementarea rutinelor numerice de care are nevoie pentru a executa codul MATLAB ca pe un
program provenit din limbajul C. Din nefericire, folosirea Win32 dynamic link libraries nu este
permisă în mediul de timp real implementat în nucleu. Rezultă cum codul generat de
compilatorul MATLAB nu poate rula în timp real. Dacă MathWorks ar furniza bibliotecile cu
legare dinamică ca biblioteci cu legare statică, atunci s-ar crea posibilitatea ca MATLAB
Compiler să furnizeze cod C pentru generarea de cod de timp real. Până când MathWorks nu va
face această opţiune disponibilă, the MATLAB Compiler nu va putea fi suportat de WinCon sau
de orice alt target de timp real.

8.7 Aplicaţii de timp real dezvoltate sub WinCon disponibile în laborator

Un experiment de reglare în timp real implică implementarea fizică a unui sistem complet de
reglare automată: existenţa unui regulator, a elementelor de execuţie, a instalaţiei tehnologice şi a
traductoarelor. Sistemul Quanser foloseşte pentru implementarea regulatorului softwareule
WinCon şi plăci de achiziţie din gama Sensoray 626 (PCI) cuplate la o placă de borne de tip
MultiQ PCI.
În laborator sunt disponibile două experimente deosebit de interesante: braţul flexibil şi pendulul
invers.
 Elementul de execuţie este constituit din Modul universal de putere UPM, care realizează
adaptarea de putere între placa de achiziţie şi motorul de acţionare al structurilor robotice.

137
 Comanda de la regulator (ieşirea plăcii de achiziţie) este amplificată în putere şi transmisă
servomotorului.

Modulul universal de putere ce reprezintă elementul de execuţie

Instalaţia tehnologică este concepută modular pentru creşterea flexibilităţii implementării

experimentelor. Experimentele sunt de tipul rotativ (Rotary Motion Experiments) în sensul că
acţionarea se face prin mişcare rotativă, nu liniară. Instalaţia este compusă dintr-un modul de
bază (Quanser SRV-02 Plant) la care se pot ataşa diferite experimente. În cazul laboratorului,
dispunem de două experimente: pendulul invers rotativ (Rotary Inverted Pendulum) şi braţul
flexibil (Rotary Flexible Link).
 Servo-motor de curent continuu cuplat la reductoare de turaţie SRV-02.

Grupul motor-reductor

 Modul braţ flexibil ROTFLEX, cuplat la servomecanismul de acţionare

138
  Modul pendul-invers ROTPEN, cuplat la servomecanismul de acţionare

Fiecare dintre experimentele de mai sus dispune de traductoarele necesare pentru implementarea
sistemului de reglare. Astfel, în cazul instalaţiei SRV-02 dispunem de un traductor
potenţiometric de poziţie a braţului rotativ.
În cazul braţului flexibil deflecţia vârfului este măsurată cu ajutorul unei mărci tensiometrice iar
în cazul pendulului invers deviaţia pendulului de la verticală se măsoară cu ajutorul unui
traductor potenţiometric.
Pentru implementarea controllerului de timp real se foloseşte o diagramă Simulink prezentată şi
detaliată mai jos.

Diagrama Simulink din care se generează controllerul de timp real

Detalii ale blocurilor componente ale diagramei:

Bias removal şi Calibration and differentiation

139
 Implementarea blocului State Feedback

Această arhitectură tinde să devină un standard în proiectarea, testarea şi implementarea

aplicaţiilor de timp real.
Putem spune că am folosit un mediu în care simularea şi testarea în timp real urmează un traseu
logic care este cunoscut în literatură sub denumirile de Rapid Prototyping şi Hardware-in-the-
loop.
Partea esenţială o reprezintă RTW (Real-Time Workshop) care implementează un kernel de timp
real legat la nivel de interfaţă cu mediul MATLAB/Simulink. Acest mediu de timp real poate
genera mai multe « ţinte » (target), unul dintre ele fiind Real-Time Window target sau WinCon
target (implementat în mediul Simulink de către firma Quanser) într-o arhitectura prezentată în
figura de mai sus.
Integrarea modului External al Simulink şi a Real-Time Windows Target permite
folosirea modelului Simulink ca o interfaţă grafică cu utilizatorul pentru:
 Vizualizarea semnalelor – Se pot folosi aceleaşi blocuri Simulink Scope care
vizualizează semnalele în timpul simulării în mod Normal pentru a vizualiza
semnalele vehiculate de aplicaţia de timp real.
 Acordarea (modificarea) parametrilor—Se poate folosi Block Parameter dialog
boxes pentru schimbarea valorilor parametrilor aplicaţiei în timp ce aceasta se
execută în timp real. Aplicaţii tipice pentru Real-Time Windows Target include
Real-time control sau Real-time data acquisition.
 Real-time hardware-in-the-loop simulation – Simulare hardware în buclă:
 crează un prototip al controllerului conectat prin intermediul unei plăci de proces la
o instalaţie fizică reală (controller software, instalaţie reală). Spre exemplu, se poate
conduce un proces reprezentat de un servomotor şi un braţ robotic sau se poate
regla poziţia unui braţ flexibil sau menţine în echilibru un pendul invers.
 Crează un prototip al unei instalaţii conectate la un controller real (instalaţie
software, controller real).

140
Procesul general de proiectare şi testare în timp real este prezentat în figura de mai sus. În cazul
particular al cercetărilor experimentale folosite în prima fază a contractului de cercetare, folosind
mediul hardware/software prezentat mai sus, se abordează următorul flux de proiectare :
1. Determinarea parametrilor modelelor asignate instalaţiilor tehnologice
(părţilor fixe).
2. Estimarea parametrilor modelelor
3. Proiectarea algoritmului de reglare folosind anumite metode de sinteză a
regulatorului.
4. Simularea în mediul MATLAB/Simulink a comportamentului sistemului de
reglare în buclă închisă. Punctele 3 şi 4 se repetă iterativ până la obţinerea
performanţelor dorite.
5. În modelul Simulink folosit pentru simulare se înlocuieşte modelul părţii
fixe cu blocurile de intrare/ieşire corespunzătoare plăcii de achiziţie folosite.
Folosind Real-Time Window target sau WinCon target se generează aplicaţia de timp real
corespunzătoare modelului Simulink obţinut anterior. Această aplicaţie de timp real va deveni
aplicaţia hardware-in-the-loop folosită pentru testarea algoritmului de reglare în timp real asupra
instalaţiei real pentru care a fost conceput.

141