Master Sisteme Inteligente de Conducere [602080]

Universitatea Politehnica din București
Facultatea de Automatică și Calculatoare
Departamentul de Automatică și Ingineria Sistemelor
Master Sisteme Inteligente de Conducere

LUCRARE DE DISERTA ȚIE

Coordonator științific:
Prof.univ.dr.ing.Nicolae Constantin

Absolvent: [anonimizat]
2015

Universitatea Politehnica din București
Facultatea de Automatică și Calculatoare
Departamentul de Automatică și Ing ineria Sistemelor
Master Sisteme Inteligente de Conducere

LUCRARE DE DIS ERTA ȚIE

Analiza sistemelor distribuite de
conducere în timp real

Coordonator științific:
Prof.univ.dr.ing.Nicolae Constantin

Absolvent: [anonimizat]
2015

Abstract

Instalarea de noi echipamente cu diverse protocoale de comunicație (filedbus -uri)
într-o instalatie industrială cere noi abordă ri în ceea ce privește p roiectarea sistemului de
conducere .Sisteme le de conducere în rețea (NCS) sunt de obicei sisteme distribuite
descentralizate interconectate prin rețele industriale cu fir și/sau wireless.În această lucrare
sunt abordate cele doua metode de realizare a unui sistem de control in rețea, cu fir sau
wireless, și simularea acestora într -un mediu spe cific si anume Matlab TrueTime.

Listă figuri

Fig.1.Nivel ul fizic al unui process de fabricație (NCS hibrid) 10
Fig.2.Biblioteca TrueTime 2.0 beta 6 11
Fig.3.Blocul TrueTime Kernel 11
Fig.4.Blocul TrueTime Battery 12
Fig.5.Blocurile TrueTime Send și TrueTime Receive 13
Fig.6.Blocurile TrueTime Network și TrueTime Wireless Network 13
Fig.7.Setarea parametrilor blocului TrueTime Network 14
Fig.8.Setarea parametrilor pentru Blocul TrueTime Wireless Network 17
Fig.9.Structura unui NC S cu mai multe noduri 20
Fig.10.Sincronizarea elementelor NCS -ului 21
Fig.11.Modelul întârzierilor în NCS 23
Fig.12.Sistem de conducere distribuit cu rețea CAN 24
Fig.13.Arhitectura NCS 24
Fig.14.Schema Simulink TrueTime a NCS -ului propus 25
Fig.15.Parametrii PD -ului discret 25
Fig.16.Fereastra de dialog a blocului Simulink Computational Delay 26
Fig.17.Referința treaptă r,ieșirea sistemului y și comanda u la  data
rate80000 bits/s 27
Fig.18.Referința treaptă r,ieșirea sistemului y și com anda u la  data rate
80000 bits/s 27
Fig.19.Referința treaptă r,ieșirea sistemului y și comanda u la  data rate
160000 bits/s 28
Fig.20.Referința treaptă r,ieșirea sistemului y și comanda u la  data rate
80000 bits/s 28
Fig.21.Ref erința treaptă r,ieșirea sistemului y și comanda u la  data rate
80000 bits/s 28
Fig.22.Rezultate simulare NCS  29
Fig.23.Referința treaptă r,ieșirea sistemului y și comanda u la și data
rate 80000 bits/s 29
Fig.24.Referința treaptă r,ie șirea sistemului y și comanda u la  și data rate
80000 bits/s 30
Fig.25.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate
160000 bits/s 30
Fig.26.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate
80000 bits/s 30

Fig.27.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate
80000 bits/s 31
Fig.28.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate
160000 bits/s 31
Fig.29. Structura Simulink/True Time a sistemului de conducere distribuit wireless 32
Fig.30. Fereastra de dialog a blocului True Time kernel 33
Fig.31.Traficul de mesaje în rețeaua wireless 33
Fig.32.Referința treaptă r,ieșirea sistemului y și comanda u la  39
Fig.33.Sche dule pentru nodul elementului de execuție  39
Fig.34.Network Schedule 40
Fig.35. Schedule pentru nodul kernel(computer) 40
Fig.36. Bateria pentru elementul de execuție și pentru regulator 40
Fig.37.Referința treaptă r,ieșirea sistemului y și comanda u la  41
Fig.38.Influenta blocului battery asupra motorului de c.c.  41
Fig.39.Parametrii regulatorului PI  43
Fig.40.Schema Simulink/TrueTime a NCS -ului wireless ZigBee  43
Fig.41. Performanțele NCS -ului cu o perioada de eșantionare de 0.005s 43
Fig.42.Performanțele NCS -ului cu o perioada de eșantionare de 0.00285s 44
Fig.43. Performanțele NCS -ului cu 14 noduri 44
Fig.44. Performanțele NCS -ului cu 15% pierderi de pachete 44

Abrevieri

NCS Network Control System
RTNCS
A/D Real Time Networ k Control System
Analog/Digital Converter
D/A Digital/Analog Converter
CSMA/CD
CSMA/AMP(CAN)

FDMA
TDMA (TTP)
PD
PI
WSN Carrier Sense Multiple Access with Collision Detection
Carrier Sense Multiple Access with Arbitration on Message
Priority(Contoller A rea Network)
Frequency Division Multiple Acces
Time Division Multiple Acces
Proportional Derivative
Proportional Integrator
Wireless Sensor Network
WLAN
MAC Wireless Local Area Network
Media Access Control addreses
LAN Local Area Network

Cuprins

1.INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. ……………. 8
1.1.S ISTEME DISTRIBUITE D E CONDUCERE ………………………….. ………………………….. ………………………….. ……………….. 9
1.1.1Structuri de rețele pentru sisteme distribuite (SD) ………………………….. ………………………….. …………….. 9
1.2.NCS (NETWORK CONTROL SYSTEM ) ………………………….. ………………………….. ………………………….. ………………. 11
1.3.F UNCȚIILE TOOLBOX -UL TRUETIME ………………………….. ………………………….. ………………………….. ………………… 12
1.3.1.Blocul TrueTime Kernel ………………………….. ………………………….. ………………………….. …………………. 12
1.3.2.Blocul TrueTime Battery ………………………….. ………………………….. ………………………….. ……………….. 13
1.3.3.Blocurile TrueTime Standalone Network Interface ………………………….. ………………………….. …………. 13
1.3.4.Blocurile TrueTime Network și TrueTime Wireless Network ………………………….. ……………………….. 14
2.REȚEAUA TRUETIME Î N NCS ………………………….. ………………………….. ………………………….. ……………….. 15
2.1. REȚEAUA CU FIR TRUETIME ………………………….. ………………………….. ………………………….. ………………………… 15
2.1.1.CSMA/CD (Ethernet) ………………………….. ………………………….. ………………………….. ……………………… 16
2.1.2.CSMA/AMP (CAN) ………………………….. ………………………….. ………………………….. …………………………. 16
2.1.3.Round Robin (Token Bus) ………………………….. ………………………….. ………………………….. ……………….. 17
2.1.4.FDMA ………………………….. ………………………….. ………………………….. ………………………….. ……………… 17
2.1.5.TDMA (TTP) ………………………….. ………………………….. ………………………….. ………………………….. ……… 17
2.1.6.Switched Ethernet ………………………….. ………………………….. ………………………….. …………………………. 17
2.2. REȚEAUA FĂRĂ FIR (WIRELESS ) TRUETIME………………………….. ………………………….. ………………………….. ………… 18
2.2.1.802.11b/g(WLAN) ………………………….. ………………………….. ………………………….. ………………………… 19
2.2.2.802.15.4 (ZigBee) ………………………….. ………………………….. ………………………….. …………………………. 19
3. PLATFORMA DE LUCR U:TRUETIM E SIMULINK/MATLAB ………………………….. ………………………… 20
3.1.CERINȚE SOFTWARE ………………………….. ………………………….. ………………………….. ………………………….. ……… 20
3.2.I NSTALAREA TOOLBOX -ULUI TRUETIME ÎN MATLAB ………………………….. ………………………….. ………………………….. 20
3.3.COMPILAREA ………………………….. ………………………….. ………………………….. ………………………….. ……………… 20
4.ANALIZA PERFOMANȚE LOR SISTEMELOR DIST RIBUITE DE CONDUCERE WIRED ………… 21
4.1.Î NTÂRZIERILE ÎNTR -UN SISTEM DE CONDUCE RE DISTRIBUIT ………………………….. ………………………….. …………………… 21
4.1.1.Relația dintre întârziere și perioada de eșantionare într -un NCS ………………………….. ………………….. 21
4.1.2.Modelul întârzieril or în NCS ………………………….. ………………………….. ………………………….. ……………. 23
4.2.I MPACTUL ÎNTÂRZIERILO R ȘI A TIPULUI REȚEL EI ASUPRA NCS-ULUI ………………………….. ………………………….. …………. 24
4.2.1.Simularea NCS folosind protocolul CSMA/AMP (CAN) ………………………….. ………………………….. …….. 28
4.2.2.Simularea NCS folosind protocolul CSMA/CD(Ethernet) ………………………….. ………………………….. ….. 30
5. ANALIZA PERFOMANȚ ELOR SISTEMELOR DIST RIBUITE DE CONDUCERE WIRELESS ……. 33
5.1. SIMULAREA UNUI NCS FOLOSIND PROTOCOLUL 802.11 B(WLAN) ………………………….. ………………………….. ………. 33
5.1.1.Simularea cu blocul TrueTime kernel ………………………….. ………………………….. ………………………….. .. 33
5.1.2.Rezultate în simulare ………………………….. ………………………….. ………………………….. …………………….. 40
5.2.S IMULAREA UNUI NCS FOLOSIND PROTOCOLUL 802.15.4(Z IGBEE) ………………………….. ………………………….. ………. 43
5.2.1.Simularea cu blocuri standalone Send/Receive ………………………….. ………………………….. ……………… 43
5.2.1.1.Perioada de eșantionare ………………………….. ………………………….. ………………………….. ………………………… 43
5.2.1.2.Numărul de noduri ………………………….. ………………………….. ………………………….. ………………………….. …… 43
5.2.1.3.Pierderi de pachete ………………………….. ………………………….. ………………………….. ………………………….. …… 43
5.2.2.Rezultate în simulare ………………………….. ………………………….. ………………………….. …………………….. 44
6.AVANTAJELE/DEZAVAN TAJELE FOLOSIRII SIS TEMELOR DISTRIBUITE DE CONDUCERE …….. 46
7.CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. ………………… 47
8.BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. …………… 48

8
1.Introducere

În zilele noastre, se poate observa o tendință de a trece de la clasicul sistem de
conducere centralizat la sistemul de conducere distribuit.Această abordare cere de la sine o
schimbare în ceea ce priveste proiectarea sistemului de control, automatizarea t radițională
fuzionând cu tehnologiile noi impuse și rețelele de calculatoare[1].
Cel mai folosit și cel mai sigur mod de a conecta noduri le de comunicație într-o rețea
industrială este prin cabluri.Există diverse tehnologii date în folosință în aplicații le
industriale, fiecare dintre ele este implementată de mai mulți producă tori.B eneficiile
principale ale folosirii unei astfel de rețele sunt eficiența costurilor și fiabilitatea.
Fiecare tehnologie și producător în parte respectă aceste cerințe.Principal a diferență
constă în viteza de transfer și protocoalele de comunicații.
Tehnologii mai vechi ca CAN bus sau Profibus au fost proiectate de la zero pentru
nevoile industriale(siguranța și rezistența la interferențe) iar limitele lor au rămas
nedescoperite până în ultimii ani (numărul maxim de noduri conectate, maximul vitezei de
transfer) .La origine, CAN a fost dezvoltat pentru utilizare în industria c onstructoare de
automobile de că tre firma Bosch. Din cauza limitărilor impu se de CAN a existat o initiativă
pentru folosirea Ethernet -ului folosit deja in LAN -uri.Aceasta perspectivă a fost posibilă
datorită vitezei de transfer mare, ușurința în instalare, hardware ieftin și rezistența la
interferențe.Princ ipalii producatori de hardware ș i-au implementat deja p ropriile produse pe
baza protocolui Ethernet, cum ar fi: Profinet de Siemens, EherCAT de Beckhoff sau Ethernet
Powerlink de B@R. Diferențele principale se regăsesc în protocoale si accesul la
mediu.Asemanările se reg ăsesc la nivelul fizic:cabluri si switch -uri.
Urmărind implementarea de success a tehnologiilor cu fir bazate pe Ethernet în
industrie, producătorii au imp lementat tehnologii de transfer de date prin rețea
wireless.Beneficiile sunt: flexibilitatea în ins talare și cost redus, scalabilitare, costuri reduse
de operare [5].
În spatele acestui concept tehnologic se ascund protocoale de comunica ție
standardizate care au evoluat rapid în u ltimii 20 ani. Bazate pe această optimizare spațio –
temporalã, în ultimii an i au apărut structuri de control în rețea (NCS) din ce în ce mai
performante.Aceste tehnologii sunt din ce în ce mai utilizate din considerente de cost, de
fiabilitate si de confort cât si în ceea ce priveste facilitatea instală rii si întreținerii lor.

Mijloacele de comunicaț ie intr-un proces industrial sunt de mai multe tipuri :
 Mecanice
 Hidraulice si pneumatice
 Electrice (curent, tensiune ,…)
 Semnale (analogice) unificate – semnale standardizate
– tensiune (0-10V , -5 – +5V)
– curent (4-20 mA)
 Semnale digita le – semnale de stare, impulsuri, etc.
 Magistrale si retele de comunicatie

În sistemele de control informațiile sunt transmise in diferite moduri:
– prin conexiuni (legă turi) dedicate între sistemul de control (calculator) si dispozitivele
de automatizare ( senzori, elemente de executie) plasate în procesul controlat.
– prin reț ea ind ustrială de comunicație ce leagă toate elementele unui sistem de
automatizare.

9
1.1.Sisteme distribuite de conducere
Avem în vedere relația care caracterizează un sistem cu intră ri si ieșiri de
forma: y = f(x) (1)
Fie
x – date de intrare
y – date de iesire
f – mijloace de prelucrare a datelor de intrare
Un astfel de sistem îl nu mim sistem de prelucrare a datelor .Un sistem în care datele
de intrare si cele de iesire reprezintã informații de un anumit interes, atunci acest sistem îl
numim sistem informațional .Dacă prelucrarea datelor de intrare se face prin mijloace
mecanizate spun em cã avem un sistem de prelucrare mecanizatã a datelor .Dacă prelucrarea
datelor de intrare se face cu ajutorul calculatorului (calculatoarelor) atunci avem un sistem de
prelucrare automată a datelor sau sistem informatic . În general un sistem informatic
cuprinde mai multe aplicații informatice. O aplicație informaticã se referă la un domeniu mai
restrâns din cadrul unei societăți comerciale sau întreprindere [7].
Odatã cu realizarea unor reț ele de calculatoare si implementarea unor aplicații de o
anvergură mai larg ă pe acestea, s -a ajuns la necesitatea realizãrii unor sisteme informatice
distribuite pe care le vom numi simplu sisteme distribuite [7].

1.1.1Structuri de rețele pentru sisteme distribuite (SD)
În ceea ce priveș te topologiile de rețele ce le folo sesc sistemele distribuite (SD) și care
se referă la dispunerea geometrică a nodurilor si a legăturilor care există, pentru un sistem
distribuit, putem pune in evidență următoarele structuri:
a)
b)

c)
d)

e)

10

a) structură de tip centra lizat sau stea
Există un nod central cu func ții de control in rețeaua de calculatoare asociată
sistemului distribuit; celelalte noduri pot comunica intre ele numai prin intermediul nodului
central.
b) structură de inel sau buclă
Mult folosită în practică, se utilizează atunci când c alculatoarele nu sunt la distanț e
mari unele de altele. O astfel de structură se caracterizează prin aceea că fiecare nod are 2
vecini.
c) structură ierarhică
Sub forma unei arborescențe, cu un nod rãdãcinã a structurii; celelalte con ectate într –
o anumita ierarhie, pe nivele. E specifică utilizatorilor dintr -o soci etate comercială, de regulă
organizată într -o anumită ierarhie între diverse sectoa re si compartimente ale societăț ii.
d) structură de multistea sau distribuită – există mai mul te noduri cu funcții de control
(de exemplu: mai multe arhitecturi stea conectate intre ele)
e) structură complet distribuită
Cea mai generală formă de structură a unei rețele; reprezentarea unei astfel de
topologii făcandu -se cu un graf complet; intre orice două noduri ale sistemului există o linie
de comunicație.
Acestea fiind spuse o astfel de structura de rețea pentru sistemele distribuite poate f i
implementată în cadrul unui si stem de conducere distribuit în timp real ( RTNCS ).

RTNCS (real -time networked control systems) este definit pe scurt prin egalitatea :
RTNCS = NCS + RTCS (2)
Cele două domenii integrate in acest cadru de cercetare sunt RTCS (real -time
control systems) și NCS (networked control systems).
RTCS (real -time control system) se referă la sistemele de control cu un
comportament temporal bine determinat și strâns legat de timpul fizic. În unele cazuri aceste
sisteme sunt implementate în arhitectură monotasking: algoritmul de reglare unic dispune de
toate resursele sistemului de calcul (memorie, procesor, etc.). În alte situații se preferă
partajarea resurselor de calcul între mai multe taskuri de control, caz în care sistemele de
control sunt în arh itectură multitasking [8].
NCS (networked control system ) se bazează pe implementarea unor sisteme de
control prin partajarea resurselor de comunicație: rețele de date sau de control.
Avantajele soluțiilor furnizate sunt avantajele generale ale unor resurse partajate (de
calcul și de comunicare): sisteme de control flexibile, modulare, tolerante la defecte, preț de
cost scăzut.
Strategia folosită pentru implementarea acestor soluții este concepută pentru
diminuarea dezavantajelor pe care le implică folosire a resurselor de calcul și de comunicare
limitate: strategia de ordonare a taskurilor, strategia de acces in rețea, diminuarea influenței
întârzierilor introduse de rețea si a pier deri pachetelor de date (măsuri sau comenzi) . Este
necesară proiectarea uno r controllere care î n algoritmul implementat să țină cont de
parametrii rețelelor de comunicație și a strategiilor de acces la resursele de calcul, folosind o
metoda novativă chiar pe plan mondial, anume proiectar ea conjugată a controllerului si a
strategiil or de partajare a resurselor [8].

11
1.2.NCS (Network Control System)

Conform [2] un sistem de control în rețea (NCS) este o structură de control distribuită
unde comunicația între nodurile sistemului este realizată de către rețeaua de
comunicație.Elementel e de bază ale unui NCS sunt:senzorii, regulatoarele, elementele de
execuție si rețeaua de comunicație.
Un NCS poate fi pe un nivel sau multi -nivel.NCS -ul pe un nivel este un sistem in care
nodurile de comunicație sunt interconectate în cadrul unui singur n ivel al intregului proces de
producție al unei companii/fabrici etc.Un exemplu de astfel de si stem este reprezentat în
fig.1.Mai multe niveluri interconectate în cadrul unui proces de fabricație formează un NCS
multi -nivel. Există fieldbus -uri pe nivelele inferioare ale procesului si rețeaua LAN pe
nivelele superioare ale procesului unde datele de la nivelul industrial sunt procesate din
motive economice și/sau tehnologice [6].
Motivele folosirii unei structuri de con ducere în rețea sunt similare cu motivele
folosirii unei rețele de calculatoare într -o cladire.Acestea sunt:
 Un mediu, mai multe conexiuni
 Transmiterea de date simple și/sau complexe in directii multiple
 Infrastructur ă de comunicaț ie mai ieftina (rentabilitate)
 Transmisie sigură/fiabilă :
o Prin fol osirea tehnicilor digitale de codare si transmisie
o Mijloace specifice de protecție a datelor (metode de detecție si corecț ie a
erorilor in cluse în protocolul de comunicaț ie)
 Mediu de comunicaț ie scalabil si reconfigurabil
 Standardizare si interoperabilita te

Fig.1. Nivel ul fizic al unui process de fabricație (NCS hibrid)

Din punctul de vedere al principiilor comunicației NCS -urile pot fi ierarhice sau
directe.Î n cadrul celor directe bucla de reglare este formată din elemente de execuție, senzori
si regulatoare conectate la o rețea, pe cand în cadrul celor ierarhice bucla de control locală
este conectată la un controller aflat la un nivel superior.Acest tip de NCS este folosit în
sisteme de conducere mai av ansate cum ar fi robotica mobilă [6].
Nodurile din cadrul unui NCS sunt conectate fie prin cabluri cu diverse protocoale
(CAN , Ethernet) sau wireless ( ZigBee, iWLAN ).
Un astfel de sistem poate fi simulat cu ajutorul toolbox -ul Matlab TrueTime.

12
1.3.Funcțiile toolbox -ul TrueT ime
Principalele blocuri din biblioteca TrueTime sunt două obiecte Simulink: True Time
Kernel si True Time Network . În cazul implementării unei structuri de conducere în rețea este
necesară folosirea blocului Network sau Wireless Network [3].

Fig.2. Biblioteca TrueTime 2.0 beta 6

1.3.1.Blocul TrueTime Kernel

Fig.3.Blocul TrueTime Kernel

Blocul True Time Kernel din biblioteca True Time este folosit pentru implementarea
controlului în rețea. Cu ajutorul acestui bloc putem conecta diferitele blocuri funcț ionale ale
unui sistem de r eglare pentru a putea simula funcționarea unui sistem distribuit de co ntrol [3].
Acesta este o funcție -S Simulink care simulează un computer cu kernel în timp real,
convertoare A/D și D/A, o interfață de rețea si canele de intrerupere externe .Kernel -ul
execută task -uri definite de către user și anumite întreruperi.

13
În cadrul acestui bloc se definește funcția de inițializare a kernel -ului în timp
real:Name of init function (MEX or MATLAB) .Fiecare block kernel trebuie initializat la
inceputul simulării.Mai p oate fi setat un block de battery, clock drift și clock offset.
Scriptul de inițializare, co dul pentru realizarea task -urilor, ș i codul pentru întreruperi
se pot scrie ca m-files (Matlab) sau ca funcții C++. Algoritmii de control pot fi implementați
cu aju torul diagramelor block Simulink.

1.3.2.Blocul TrueTime Battery
Fig.4.Blocul TrueTime Battery

Blocul TrueTime Battery se comportă ca o sursă de putere în cazul în care blocurile
kernel sunt activate de o baterie.Folosește un model integrator simplu p entru a putea fi
încărcat si reîncărcat.Singurul parametru din blocul de configurare a TrueTime Battery este
acela de initial energy (Fig.4) .Pentru a putea folosi acest bloc, trebuie activat in check box -ul
din masca de configurare a kernel -ului, conectată ieșirea E la intrarea Energy a blocului
kernel și conectată intrarea P la ieșirea Power a blocului kernel . Pe iesirea E se adauga un
bloc Simulink Scope pentru a urmări evoluția bateriei în timp real.

1.3.3.Blocurile TrueTime Standalone Network Interface

Blocurile TrueTime Standalone Network Interface (TrueTime Send, TrueTime
Receive ) pot fi folosite pentru a trimite mesaje în rețea (folosind blocul Network ) fară a
folosit blocuri kernel .Asta înseamnă că nu este nevoie de o funcție de inițializare sau de o
funcție pentru task -uri.Conform [4] simularea rețelei poate fi realizată doar în Simulink fară
folosirea de m-files sau cod C++ .
Este posibilă combinarea blocurilor standalone cu cele kernel într-o simulare.Asta
inseamnă că unele elemente pot trimite me saje fară ajutorul m-file-urilor (e.g.senzori) iar alte
elemente pot folosi blocuri kernel (regulatoarele) pentru transmiterea de mesaje [6].
Blocurile TrueTime Send și TrueTime Receive pot fi configurate în ferestrele proprii de
dialog(Fig.6).Blocul Send poate fi time-triggered sau event -triggered .Portul de intrare trigger
poate fi configurat ca: raising, falling sau either [6].

14

Fig.5.Blocurile TrueTime Send și TrueTime Receive

1.3.4.Blocurile TrueTime Network și TrueTime Wireless Network

Fig.6.Blocur ile TrueTime Network și TrueTime Wireless Network

15
2.Rețeaua TrueTime în NCS
2.1. Rețeaua cu fir True Time
Blocul rețelei TrueTime simulează accesul la mediu si transmisia de pachete într -o
rețea locală. Fiecare nod are un număr si câte o intrare si o iesire în blocul de rețea TrueTime
Kernel.Când un nod încearcă să transmită un mesaj (folosind primitiva ttSendMSg ) un semnal
de triggerare se transmite canalului de iesire corespunzător nodului de primire. Mesajul
transmis este pus pus într -un buffer al nodului receptor. Un mesaj conține informatii despre
nodul transmițător si cel receptor, datele arbitrare ale utilizatorului (uzual semnalele de
măsură de la senzori la controller sau de comandă de la controller la elementele de execuție),
lungimea mesaju lui si un atribut opțional de timp real precum o prioritate sau un termen final.
Sunt suportate 6 modele simple: CSMA/CD (ex: Ethernet), CSMA/AMP (ex: CAN),
RoundRobin (ex: Token Bus), FDMA, TDMA (ex: TTP) si Switched Ethernet.
Întârzierea propagată este ignorată, din moment ce este foarte mică într -o rețea locală.
Numai simularea la nivel de pachet este suportată, (se presupune că protocoalele de nivel
superior din nodurile nucleului rețea divid mesajele mai lungi în pachete).Blocul de rețea este
configur at prin intermediul măsti i blocului de dialog, din fig.7 . Unii parametri pot fi de
asemenea setați pe baza nodului cu comanda ttSetNetworkParameter [3].

Fig.7.Setarea parametrilor blocului TrueTime Network

16

Următorii parametrii de rețea sunt comuni tutu ror modelelor [3]:
Network number – Numărul rețelei, Numărul blocului de rețea. Rețelele pot fi
numerotate de la unu în sus. Rețelele cu fire sau rețelele fără fire nu au voie sa folosească
acelasi număr.
Data rate (bits/s) – Viteza rețelei
Minimum frame si ze (bytes ) – Un mesaj sau un frame mai mic decât acesta poate fi
completat să dea această lungime minimă. Reiese că o lungime de frame minimă include
orice overhead introdus de către protocol De exemplu, mărimea minimă inclusiv un header de
14 byte si unCR C de 4 byte este de 64 de bytes. Rezultă că pentru date rămân minim (64 -14-
4 = 46 bytes).
Pre-processing delay(s) – întârzierea pre -procesată. Timpul cu care este întârziat un
mesaj deinterfața de rețea la nodul transmițător. Acesta poate fi folosit pentru a modela, de
exemplu, o conectare serială lentă între computer si interfața de rețea.
Post-processing delay (s) – întarzierea post – procesată Timpul cu care este întârziat
un mesajde interfața de rețea la nodul receptor.
Loss probability (0 -1) – probabilit atea pierderii . Probabilitatea ca un mesaj de
rețea să fie pierdut în timpul trasmisiei. Mesajele pierdute vor consuma lațimea de bandă a
rețelei, dar nu vor ajunge niciodata la destinație.

2.1.1.CSMA/CD (Ethernet)
CSMA/CD înseamnă Carrier Sense Multipl e Access with Collision Detection (Acces
multiplu cu ascultarea purtătoarei si detectarea coliziunii). Dacă rețeaua e ocupată,
transmițătorul va astepta pană se va elibera. O coliziune va apărea dacă un mesaj este
transmis într -o microsecundă față de mesaj ul altui nod (aceasta corespunde propagării
întarzierii într -un cablu de 200 de m; numărul actual nu este foarte important devreme ce
coliziunile după toate previziunile se întâmplă când 2 sau mai multe noduri asteaptă
eliberarea (neutilizarea) cablului).
Când se întâmplă o coliziune transmițătorul va da înapoi pentru un timp definit de:
tbackoff = minimum frame size / data rate x R unde R= rand (0,2 K- 1) (distribuție uniformă
discretă) si K este numărul de coliziuni într -un rand (linie) (dar maxim 10 – aici oricum nu este
o limită superioară a numărului de retransmisii).
Notați că pentru CSMA/CD marimea minimă de frame nu poate fi 0. După as teptare,
nodul va încerca sa retransmită. Într -un exemplu unde 2 noduri asteaptă ca al treilea nod să
termine transmisi a, acestia vor intra în coliziune cu probabiliatea 1, apoi cu probabilitatea 1/2
(K=1), apoi 1/4 (K=2) si asa mai departe [3].

2.1.2 .CSMA/AMP (CAN)
CSMA/AMP înseamnă Carrier Sense Multiple Access with Arbitration on Message
Priority (Acces multiplu cu asc ultarea purtătoarei si arbitraj pe prioritatea mesajului).
Dacă rețeaua este ocupată, transmițătorul va astepta până când se va întâmpla să fie liber.
Dacă se întâmplă o coliziune (adica dacă 2 transmisii au început într -o microsecundă) mesajul
cu cea mai ridicată prioritate (numărul de prioritate cel mai mic) va continua să transmită.
Daca 2 mesaje cu aceeasi prioritate caută să transmită în acelasi timp, se va face o alegere
arbitrară cât priveste cel care să transmită primul. În aplicații reale CAN, toat e nodurile care
transmit au un identificator unic, care serves te la prioritatea mesajului[3].

17
2.1.3 .Round Robin (Token Bus)
Nodurile în rețea transmit pe rând (de la cel mai mic la cel mai mare număr de nod)
câte un frame fiecare. Între transmisii reț eaua este liberă pentru un timp de: tidle = minimum
frame size / date rate reprezentând timpul de pasare a ‘stafetei’ (token) de la un nod la
altul[3].

2.1.4 .FDMA
FDMA însemnă Frequency Division Multiple Acces (Accesul Multiplu cu divizarea
frecvenței). T rasmisia diferitelor noduri este complet independentă si nu apar coliziuni. În
acest mod va fi nevoie de un extra atribut. Bandwidth allocations Alocările de lățime de
bandă Un vector de partajări a lărgimii de bandă pentru nodurile transmițătoare care tre buie
să însumeze cel mult 1 [3].

2.1.5 .TDMA (TTP)
TDMA înseamnă Time Division Multiple Acces (Accesul multiplu cu divizarea
timpului).Lucrează similar cu FDMA –ul, exceptând faptul că fiecare nod are 100% lățime de
bandă dar numai în sloturile (intervalele de timp) programate. Dacă un frame complet nu
poate fi transmis într-un slot, transmisia va continua în următorul slot programat, fără alte
penalități. Notați ca overhead este adăugat la fiecare frame la fel ca în celelalte protocoale.
Extra atributele sun t: Slot size (bytes ) Marimea slotului (octeți) Marimea unui slot
transmițător. Slotul de timp este de aici data de: tslot = slot size / data rate Schedule – orar,
alocator un vector ce conține identificator ii (numerele de ordine, ID) (1… nrDeNoduri)
specifi când un program de trasmitere ciclic. Un ID zero este de asemenea un ID permis,
însemnând că nimănui nu -i este permis să transmită în acel interval de timp (slot) [3].

2.1.6 .Switched Ethernet
În Switched Ethernet , fiecare nod din rețea are conexiunea sa p roprie completă (full
duplex) către un switch central. Comparat cu un Ethernet normal, nu se va întâmplă niciodată
o coliziune între segmentele de rețea într -un Switched Ethernet. Switchul central
înmagazinează mesajele primite într -un tampon (buffer) si a poi le trimite mai departe la nodul
de destinație corect. Aceasta schemă comună este cunoscută ca store and forward
(înmagazineaza si transmite mai departe). Dacă mai multe mesaje în timpul schimbului sunt
destinate aceluiasi nod, ele sunt transmise în ord in FIFO. Poate fi sau numai o coadă (un sir)
care ține toate mesajele sau o coadă pentru fiecare segment de iesire. În cazul unui transfer
greoi si unui sir lung de mesaje, schimbul poate să nu poată fi memorat din lipsă de memorie.
Următoarele opțiuni sun t asociate cu Switched Ethernet: Total switch memory (bytes)
Aceasta este suma totală a memoriei disponibile pentru stocarea mesajelor în schimb. O
cantitate de memorie egală cu lungimea mesajului este alocată când mesajul a fot primit cu
success în timpul schimbului. Aceeasi memorie este eliberată când mesajul complet a ajuns la
nodul final de destinație. Switch buffer type Aceasta setare descrie cum este alocată memoria
în switch . Common buffer – înseamnă că tamponul este comun, deci toate mesajele sunt
stocate într -un singur sir FIFO si împart acelasi spațiu de memorie. Symmetric outputs buffer
înseamnă ca memoria este împărțită în n părți egale, una pentru fiecare segment conectat la
switch. Când un singur sir de iesire ramâne fără memorie nici un mesaj nu mai poate fi stocat
în acea coadă. Switch overflow behavior -Comportamentul în caz de depăsire memorie.
Aceasta opțiunedescrie ce se întâmplă când switchul a ramas fără memorie. Când mesajul
complet a fost primit în timpul schimbului acesta este sters. Retransmit înseamnă că switchul
informează nodultransmitător care ar trebui sa încerce să retransmită mesajul. Drops
înseamnă ca nu s -a dat nici o notificare – mesajul s -a sters pur si simplu [3].

18
2.2. Rețeaua fără fir (wireless) TrueTime
Folosirea unui bloc de rețea fără fir este similară si lucrează în acelasi mod ca cea cu
fire.Ca să luam în considerare calea pierdută a unui semnal radio sunt x si y intrări ca să
specificam locația adevarată a nodurilor. Două protocoale de rețea sunt suportate în acest
mome nt : IEEE802.11b /g (WLAN) si IEEE 802.15.4 (Zig Bee) [3].

Fig.8.Setarea parametrilor pentru Blocul TrueTime Wireless Network

Modelul radio folosit include suport pentru:
 Rețele fără fir ad -hoc
 Calea pierdută (path loss) a semnalelor radio modelate ca 1 /da unde d este distanța în
metri si a este un parametru ales corespunzător ca să modeleze mediul.
 Înterferen țe de la alte terminale.

Blocul de re țea fără fir este configurat prin intermediul m ăstii de dialog a blocului de
rețea,vezi fig.8 . Câțiva parame tri pot fi de asemenea seta ți pe baza unui nod cu comand ă
ttSetNetworkParameter .

19
2.2.1.802.11b/g(WLAN)
IEEE 802.11b/g este folosit ă în multe laptop -uri si dispozitive mobile de ast ăzi.
Protocolul este bazat pe CSMA/CA cu câteva modific ări. În simulare , transmisia unui pachet
de date este modelat ă astfel: nodul care vrea s ă transmit ă un pachet controleaz ă dacă mediul
este nefolosit (disponibil) si dac ă a stat a sa pentru 50 s . Dac ă, pe de alt ă parte, mediul este
găsit să fie ocupat, este ales un timp b ack off la întâmplare si decrementa în acela si mod ca si
cum ar fi intrat în coliziune (aceasta sec țiune se va descrie mai târziu). Când un nod începe sa
transmit ă este calculat ă poziția sa relativ ă în raport cu celelalte noduri din aceea si rețea si
nivelu l de semnal în toate aceste noduri este calculat în conformitate cu form ula de pierdere a
traiectoriei 1/da[3].
Se presupune ca este posibil să detectăm semnalul, dacă nivelul de semnal în nodul
primitor este mai mare decât receiver signal threshold – pragu l de semnal primit. Dacă acesta
este cazul, atunci signal –to-noise ratio (SNR) este calculată si folosită să se găsească rata de
erori blocului. (BLER). Remarcați că toate celelalte transmisii sunt adăugate la zgmotul de
fundal când se calculează SNR. BLER , împreună cu marimea mesajului, este folosit să se
calculeze numărul erorilor de bit (biților eronați) în mesaj si dacă acest număr este mai mic
decat Pargul de codificare eronată – error coding threshold, atunci se presupune că schema
de codificare a canalului este în stare sa reconstruiască mesajul în totalitate. Dacă acolo sunt
deja transmisii în derulare pe care nodul de transmitere curent îl ajunge cu transmisia lor,
atunci aceste mesaje pot ă fie marcate ca si când s -ar fi ciocnit între ele (colizion at) [3].
Notați ca nodul transmițător nu stie dacă mesajele sale vor intra în coliziune, din
cauza aceasta mesajele ACK sunt trimise către un nivel (layer) de protocoale MAC . Din
perspectivele nodule care transmite date, mesajele pierdute si mesajele care intra în coliziune
sunt la fel, adică nu este primit nici un ACK. Dacă nu este primit nici un ACK în timpul ACK
timeout , mesajul este retransmis dupa ce se asteaptă un timp aleatoriu back -off în înteriorul
unei ferestre de conflict [3].
Mărimea fereastrei de conflict (contention window) este dublă pentru fiecare
retransmitere a anumitor mesaje. Timerul back -off este oprit dacă mediul este ocupat, sau
dacă nu a fost libe re pentru cel puțin 50micro secunde . V om avea un număr de ‘ Retry limit’
retransmisii înai nte ca transmițătorul să renunțe la mesaj si să nu -l mai retransmită deloc [3].

2.2.2. 802.15.4 (ZigBee)

ZigBee este un protocol proiectat cu sensor si rețele simple de control. Are lațime de
band mică, dar are si un consum de energie mic. Cu toate ca se bazează pe CSMA/CA ca
802.11b/ este mult mai simplu si protocoalele sunt diferite. Modelul pachetului de trasmisie
în ZigBee este similar cu WLAN , dar procedura MAC diferă [3].

20
3. Platforma d e lucru:TrueTime Simulink/Matlab
3.1.Cerințe software
TrueTime este recunoscut de la Matlab 6.1 (R12.1) până la versiunea actuală cu
Simulink de la 4.1 până la versiunea actuală . Un compilator C++ este necesar pentru a rula
TrueTime în versiunea C++. Pentru versiunea Matlab , fișiere preconpilate sunt puse la
dispoziție în arhiva ce poate fi downloadată de pe website-ul TRUETIME .
Următoarele compilatoare funcționeaza pentru versiunea C++ :
• Visual Studio C++ pentru Windows
• gcc, g++ pentru Linux
3.2.Instalarea toolbox -ului TrueTime în Matlab
Se downloadează și se extrag fișierele din arhiva (truetime -2.0.zip ), de pe pagina
TRUETIME . Extragând fișierele se crează directorul truetime -2.0, care va avea
rădacina recunoscută ca $DIR .
În versiunile mai vechi de Matlab variabila seteven nu există asa că î nainte d e
pornirea Matlab -ului, trebuie setată variabila de mediu TTKERNEL pentru a realiza calea
către directorul unde se afla fișierele pentru TrueTime kernel, astfel:

Unix/Linux: > export TTKERNEL=$DIR/kernel
Windows: Control Panel / System / Advanced / Environment Variables

Folosind o versiune nouă de Matlab se adaugă scriptului u rmătoarea secventa :
setenv('TTKERNEL;' , D:\Dizertatie \truetime -2.0-beta7\truetime -2.0-
beta7\kernel');
addpath([getenv( 'TTKERNEL' )])
addpath([getenv( 'TTKERNEL' ) '/matlab/help' ])
addpath([getenv( 'TTKERNEL' ) '/matlab' ])
truetime
simulink
După rularea scriptului se deschid cele doua ferestre truetime și Simulink , iar blocurile
din component acestora pot fi folosite pentru diverse simulări.

3.3.Compilarea

Pentru compilarea scripturilor, funcțiilor și schemelor Simulink este nevoie să fie
urmati toți pașii de mai sus.Pentru simularile studiilor de caz ce au fost tratate în această
lucrare s -a folosit versiunea de Matlab R2012a , versiunea Simulink aferentă, versiune a de
TrueTime 2.0. beta6 și la folosirea blocului TrueTime kernel se vor folosi m -functions,m -files
și se vor apela diagrame bloc din Simulink.

21
4.Analiza perfomanțel or sistemel or distribuite d e conducere
wired
În acest capitol se va realiza o an aliza a consecințelor folosirii a diverselor tipuri de
protocoale în simula rea unui NCS și efectul întarzierilor asupra performanțelor sistemului de
conducere în timp real.
4.1.Întârzierile într -un sistem de conducere distribuit
În momentul în care intervi ne rețeaua este inevitabilă și apariția întârzierilor
transmisiei de date [11]. Din punctul de vedere al controlului, întârzierea în rețea poate
produce stagnarea a unei faze a sistemului, deteriorarea performanțelor sistemului, reducerea
intervalului de ti mp in care sistemul este stabil sau chiar instabilitatea sistemului.În plus din
perspectiva planificării resurselor de timp (scheduling), informația poate sa nu ajungă la timp
sau chiar sa nu ajungă deloc.Așa un aspect important ce trebuie tratat atunci câ nd se
analizeaza și se proiecteaza un NCS este acela a importanței întârzierilor în rețea.

4.1.1.Relația dintre întârziere și perioada de eșantionare într -un NCS

NCS este un sistem de conducere în timp real în buclă închisă care transmite date într –
o rețea.O structură tipică a unui astfel de sistem este reprezentată în figura 9.

Fig.9.Structura unui NCS cu mai multe noduri
În funcție de durată, întârzierea în rețea poate fi de lungă sau scurtă durată.
Dacă întârzierea τ ∈[0, τ max] și τmax<h(perioada de eșantionare) atunci τ este
întârziere de scurtă durata .
Dacă întârzierea τ ∈[0, τ max] și τmax>h(perioada de eșantionare) atunci τ este
întârziere de lungă durata .
Cea de lungă durată se poate transforma în cea de scurtă durată prin selectarea unei
perioade de eșantionare potrivită si adoptarea unui algortim de scheduling adecvat
situației.Astfel acest capitol studiaza doar întârzierea de scurta durată.Diagrama de
sincronizare a elementelor într -un NCS se regăsește în figura 10.

22

Fig.10.Sincronizarea el ementelor NCS -ului
Din moment ce întârzierea este mai mică decât perioada de eșantionare, relația dintre
elementele procesului și regulator (controller) se poate scrie sub forma unui sistem ce conține
următoarele ecuații de stare:
(3)

În acest sistem , x∈Rn, y∈Rp, u∈Rm, reprezintă variabilele de stare, ieșirea și intrarea
variabilelor de sistem. În plus ,A∈Rn*n , B∈Rn*m , C∈Rp*n , K∈Rm*n , sunt matrici constant e ,
reprezentând matricile de stare ale si stem ului. Din figura 10, putem deduce că două valori ale
ieșirii regulatorului sunt transmise către elementul de executie în mai puțin de o valoare a
perioadei de eșantionare.

(4)

Așa că starile sis temului la perioadele de timp kh+ τ k și (k+1)h sunt:

(5)
Sistemul de ecuații de stare discrete în timp este:

(6)

23
În ecuație,
(7)

Vectorul de stare:
(8)
Sistemul în b uclă poate fi reprezentat astfel:

(9)

(10)

Cum raza spectrală în ec uația(10) este mai mică decât 1, atunci ecuația (9) reprezintă
ecuația de stabilitate [12]. Astfel, putem afla relația dintre τk și h:
(11)

Formula (11) este relația de constrângere dintre întârziere și perioada de eșantionar e.
Din formulă, cu cât perioada de eșantionare este mai mica, cu atât stabilitatea poate fi
susținuta într -un interval mai mare de timp de întârziere,cu cât perioada de eșantionare este
mai mare, timpul de întârziere poate fi mai mic în vederea mențineri i stabilității
sistemului .Deasemenea mai arată, că cazul unui sistem stabil cu perio ada de eșantionare mică
duce la cantitatea mare de date transmisă prin rețea ce va crește întârzierile de transmisie de
date în rețea.

4.1.2.Modelul întârzierilor în NCS

Întârzierile în retea sunt cele mai comune problem e întâlnite în cadrul unui NCS.
Atunci când apare întârzierea , intrarea sistemului nu mai este actualizată la timp și în cazuri
severe crează discordanțe în sistem, degradând calitatea acestuia și ducând chiar la
instabilitate.Întreaga buclă de reglare este adoptată în conformitate cu relația dintre
elementele sistemului: senzor→regulator PD discret→element de execuție →proces controlat,
ca în figura 11 .

24

Fig.11.Modelul întârzierilor în NCS
Întregul pro ces, de la sensor până la elementul de execuție al procesului controlat
constituie un flux de semnale ale sistemului de conducere.Într -un sistem ideal , procesul de
transfer a fluxului de date este considerat instantaneu[13 ]. Totuși, forward delay și feedb ack
delay în bucla de reglare sunt inevitabile la introducerea în sistemul de control a unei rețele.
Fiecare element al sistemului introduce un anumit tip de întârziere:
s -este întarzierea introdusă de către sensor în timp ce preia datele de la proces
c -este întârzierea introdusă de regulator care calculează comanda și convertește
semnalul pentru a fi transmis pe magistrala CAN
a -este întârzierea introdusă de elementul de execuție care primeste semnalul și
execută comanda
scîntârzierea de rețea car e reprezintă forward delay , de la senzor la regulator
ca- întârzierea de rețea care reprezintă feedbak delay , de la regulator la elementul de
execuție
Astfel,expresia întarzierii totale într -un NCS este urmatoarea:
 scca+s+c+a
Atât timp cât întârzierea în principal depinde de performanța pe fiecare nod , se poate
reduce impactul întârzierilor asupra execuției procesului prin selectarea unor procesoare
puternice si alegerea unui algoritm de optimizare cât mai bun.
Așadar , în timpul analizei și pro iectării unui NCS , întârzierea totală poate fi scrisă ca
suma dintre forward delay ca și feedback delay sc .
 scca

4.2.Impactul întârzierilor și a tipului rețelei asupra NCS -ului
Pentru a studia impactul celor doua întârzieri, forward delay ca și feedback delay sc,
construim un sistem în buclă închisă format din:sensor, element de execuție, regulator,
interferență, motor de curent continuu, ca în figura 12.Folosim senzorul pentru a măsura
viteza motorului si de a procesa datele.Apoi trimitem i nformația către regulator prin rețea, se
calculează intrarea pentru elementul de execuție și apoi se trimite rezultatul către elementul
de execuție care acționează asupra motorului.Nodul de interferență este folosit pentru a
produce un semnal periodic si a periodic și de a ajusta nivelul de trafic din rețea.

25

Fig.12.Sistem de conducere distribuit cu rețea CAN
Arhitectura sistemului cu toate elementele sale este:

Fig.13.Arhitectura NCS [3]

În cazul concret pe care îl voi prezenta, instalația de controlat va fi reprezentatã de un
motor de curent continuu iar algoritmul de reglare numeric va fi un controller PD.
Funcția de transfer a motorului de curent continuu este:

Modelul Simulink/True Time este prezentat în figura de mai jos(14). Re țeaua folositã
pentru implementarea sistemului de reglare este compusã din 3 noduri, dupã cum urmeazã:

26

Fig.14.Schema Simulink TrueTime a NCS -ului propus

Regulatorul PD discret este implementat prin blocul Discrete -time PD controller cu
următorii parametrii setați (perioa da de eșantionare h este setată 0.01) :

Fig.15.Parametrii PD -ului discret
Schema Simulink TrueTime este implementată cu ajutorul blocurilor standalone Send
și Receive , nemaifiind nevoie de blocul kernel și funcțiile de ințializare ale kernel -ului si a
regulatorului. Blocul Network implementat este simulat cu ajutorul protocolului
CSMA/AMP(CAN).

27

Nodul 1 este numit si nod de interferență (de tip raising ). Rolul acestu i nod este să
genereze către el însusi mesaje. Aceste mesaje vor aglomera traficul din rețea , deci acest nod
simulează traficul din rețea altul decât cel alocat schimbului de date (de măsură si de
comandă) al sistemului de reglare. O lățime de bandă mai mare alocată nodului de
intereferență va însemna implicit o largime de bandă mai îngustă pentr u datele din sistemul
de reglare.
Nodul 2 este nodul elementului de execuție (actuator) si cel al
senzorului (sensor) .Blocul Send care reprezintă senzorul va primi datele numerice de comandă
din rețea (pe intrarea Rcv, receive), le va transforma în mărimi a nalogice cu ajutorul unui
convertor numeri -analogic (CNA) si le va trimite mai departe pe iesirea sa analogică (D/A)
către un element de execuție si mai departe către instalația de controlat . Blocul Receive va
primi mărimi analogice de la traductoarele ana logice cuplate la instalația de controlat, le va
converti în numere cu ajutorul unui convertor analog -numeric (CAN) si apoi le va trimite în
rețea către regulator .
Nodul 3 este nodul alocat regulatorului(controller) . Acesta poate fi un PC dotat cu o
placă de achiziții si cu facilități de cuplare în rețea. El va primi datele numerice din rețea (de
la senzori) pe intrarea de rețea Rcv (receive), le va prelucra numeric conform algoritmului de
reglare implemetat (în cazul nostru un PD) si apoi comanda numerică elaborată va fi trimisă
în rețea către elementul de execuție folosind iesirea de rețea Snd (send).
Rețeaua care interconectează toate aceste noduri corespunzătoare sistemului de
reglare este implementată cu blocurilor TrueTime Standalone Network Interface (TrueTime
Send, TrueTime Receive ) care sunt folosite pentru a trimite mesaje în rețea (folosind blocul
Network ) fară a folosit blocuri kernel ..
Pentru a face mai simplu modelul Simulink, se folosesc blocuri de interconectare de
tip From (de la) si Go to (du-te la).
Pentru inceput, analizăm efectul introducerii întarzieri totale în cadrul magistralei
CAN bus asupra performanței sistemului.Intrarea este un semnal de tip treaptă iar raspunsul
la aceasta intrare este prezentat in figurile următoare cu divers e valori ale întârzierilor:
 și
Întârzierile sunt introduse în sistem cu ajutorulul blocului Simulink Computational
Delay ca în figura 16.

Fig.16.Fereastra de dialog a blocului Simulink Computational Delay

28
4.2.1.Simular ea NCS folosind protocolul CSMA/AMP (CAN)

Sistemul de conducere CAN bus este un NCS folosit în industrie pe scară
largă.Inevitabil a introdus anumiți factori de incertitudine, principala problemă este
degradarea performanței sau chiar instabilitatea care este introdusă de întârzierile de
transmisie de pachete în rețea.Pentru a asigura stabilitatea sistemului este necesar un studiu
teoretic asupra problemei întârzierilor în NCS făcut în prealabil [9].
În acest subcapitol se prezintă efectele întârzierilor ce se reflectă în performanțele
sistemului de conducere implementat cu protocolul CSMA/AMP(CAN) .
Dupa realizarea structurii Simulink TrueTime (fig.12) se ruleaza programul cu
Simulation stop time de 2, iar rezultatele simularilor sunt prezentate în figurile d e mai jos
dupa cum urmează:

Fig.17.Referința treaptă r,ieșirea sistemului y și comanda u la  data rate 80000
bits/s

Fig.18.Referința treaptă r,ieșirea sistemului y și comanda u la data rate 80000 bits/s

29

Fig.19.Referința treaptă r ,ieșirea sistemului y și comanda u la  data rate 160000
bits/s

Fig.20.Referința treaptă r,ieșirea sistemului y și comanda u la  data rate 80000 bits/s 


Fig.21.Referința treaptă r,ieșirea sistemului y și comanda u la  data rate 80 000 bits/s

30
Simul ările arată că o întârziere totală mai mică , un suprareglaj și un timp de creștere
mici duce la un sistem mult mai stabil.Când întârzierea totală crește , stabilitatea sistemului se
deteriorează sau chiar se duce în instabilitate. În plus un date rate mai mare(fig.17) duce la un
sistem mai stabil și la un suprareglaj(în comparatie cu figura 16).
Urmează studiul efectului întârzierilor forward și feedback asupra performanțelor
sistemului de conducere. În timp ce setăm semnalul de intrare ca se mnal de tip treaptă,se
setează întârzierile astfel: sc<<ca,scca.Rezultatele se pot observa în figura 20.

Fig.22.Rezultate simulare NCS 

Concluzii:
1)Când  , timpul de creștere și suprareglajul sunt relativ mici ceea ce demonstrează
considerațiile si analiza teoretică.
2)Când sc<<ca , performanța sistemului este mai bună decât în situația când scca,
suprareglajul fiind mai mic deci mai bun .

4.2.2.Simularea NCS folosind protocolul CSMA/CD(Ethernet)
În acest subcapitol se prezintă efectele întârzierilor ce se reflectă în performanțele
sistemului de conducere implementat cu protocolul CSMA/CD(Ethernet) .
Dupa realizarea structurii Simulink TrueTime (fig.12) se ruleaza programul cu
Simulation stop time de 2, iar rezultatele simularilor sunt prezentate în figurile de mai jos
dupa cum urmează:

Fig.23.Referința treaptă r,ieșirea sistemului y și comanda u la și data rate 80000
bits/s

31

Fig.24.Referința treaptă r,ieșirea sistemului y și comanda u la și data rate 80000
bits/s

Fig.25.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate 160000
bits/s

Fig.26.Referința treaptă r,ieșirea sistemului y și comanda u la și data rate 80000
bits/s

32

Fig.27.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate 80000 bits/s

Fig.28.Referința treaptă r,ieșirea sistemului y și comanda u la  și data rate 160000
bits/s
Concluzii:
Primul exemplu foloseste reț eaua CSMA/CD (Etherne t) cu o rată de transmisie de
80000 bits/sec iar al doilea cu o rată de transmisie de 160000 bits.s . Folosind o rată de
transmisie de 80000 bits/sec, sistemul îsi pierde stabilitatea .
Când întârzierea totală crește , stabilitatea sistemului se deteriorează sau chiar se duce
în instabilitate.
Rezultatele simulării probează că rețeaua CAN se comportă mai bine decât rețeaua
Ethernet.

33
5. Analiza perfomanțel or sistemel or distribuite d e conducere
wirel ess
5.1. Simularea unui NCS folosind protocolul 802.11b(WLAN)
Se va prezenta un exemplu de control distribu it în rețea al unu motor de curent
continuu. Cu ajutorul acestui exemplu vom putea simula consumul de putere (power
consumption) si vom utiliza blocul baterie (baterry block).
Modelul constă în două noduri de rețea, situate la 20 m unul d e altul, fiecare
reprezentat de c âte un bloc True Time Kernel, si un bloc baterie. Nodul complex
senzor/element de execuție este condus de timp (time -driven) esantionează procesul periodic
si trimite esantioanele în rețea către nodul controller. Taskul de control implementa t în nodul
controller calculează comanda (semnalul de control) care este trimis prin rețeaua wireless
înapoi la nodul senzor/EE unde este convertit în semnal analogic trimis către motorul de
curent continuu.Rețeaua wireless este în acelasi timp subiectul u nei scheme de control al
puterii [3].
Taskul de control al puterii rulează în ambele noduri (senzor/EE respectiv controller)
si trimit periodic mesaje de ping unul către celălalt nod pentru a testa canalele de transmisie.
Dacă este recepționat un mesaj rep lică (reply) se presupune canalul ca fiind funcțional si
puterea de transmisie este diminuată. Dacă în schimb nu se primeste un semnal de răspuns,
atunci putere de transmisie este crescută considerabil până când se saturează sau se primeste
un semnal de răspuns [3].
Se observă deosebirea majoră între rețeaua wireless si rețea ua clasică. În rețeaua
wireless este nevoie de o testare permanentă a comunicației între noduri, în paralel cu
taskurile de control care se execută.
Cum orice comunicație se face prin re țea, este nev oie ca în tipul de date care îl
implementăm să rezervăm un câmp pentru tipul datei (trimise sau recepționate). Astfel nodul
senzor/element de execuție poate primi date de la controller, caz în care va activa taskul de
acționare a elementului d e execu ție sau poate primi un mesaj ping de verificare a comunica ției
caz în care trebuie s ă replice acestui semnal. În mod analog, nodul controller poate primi o m ăsură
de la nodul senzor caz în care activeaz ă taskul de calcul al comenzii, sau poate primi un mesaj de
la nodul corespondent de testare a c ăilor de comunica ție[3].
5.1.1.Simularea cu blocul TrueTime kernel

Fig.29. Structura Simulink/True Time a sistemului de conducere distribuit wireless

34
Nodul 1: Senzor/element execu ție(sensor/actuator).
Nodul 2:Nodul pentru regulator
Nodul 3:Nodul pentru rețeaua wireless.
După cum se observ ă, în ferestra de dialog a blocului True Time Kernel ce implementeaz ă
nodul senzor/element de execu ție, este selectat ă opțiunea Battery . În acest mod terminalele E si P
ale b locului kernel sunt activate pentru a putea fi conectate la un bloc baterie.

Fig.30. Fereastra de dialog a blocului True Time kernel
În figura de mai jos este redat modul în care se realizeaz ă traficul de mesaje în re țeaua
wireless. Blocurile galbene sim bolizeaz ă taskurile periodice ia r cele albe pe cele dirijate de
evenimente.

Fig.31.Traficul de mesaje în rețeaua wireless [3]

35
Comunica ția efectiv ă este realizat ă prin intermediul handlerelor de înterupere
msgRcvActuator respectiv msgRcvCtrl . Tipul mesajel or va determina locul în care datele
primite din re țea se vor stoca în mailbox -urile disponibile. Acest lucru va fi mai evident în
momentul în care vom prezenta codurile func țiilor implementate [3].
Fisierul de ini țializare a acestui kernel este actuator_in it.m care are con ținutul :
function actuator_init

% Distributed control system: actuator node
%
% Receives messages from the controller and actuates
% the plant.

% Initialize TrueTime kernel
ttInitKernel( 'prioFP' ); % fixed priority
ttSetKernelParamete r('energyconsumption' , 0.010); % 10 mW

% Create mailboxes
ttCreateMailbox( 'control_signal' , 10)
ttCreateMailbox( 'power_ping' , 10)
ttCreateMailbox( 'power_response' , 10)

% Create sensor task
data.y = 0;
offset = 0.0;
period = 0.010;
prio = 1;
ttCreatePer iodicTask( 'sens_task' , offset, period, 'senscode' , data);
ttSetPriority(prio, 'sens_task' );

% Create actuator task
deadline = 100;
prio = 2;
ttCreateTask( 'act_task' , deadline, 'actcode' );
ttSetPriority(prio, 'act_task' );

% Create power controller task
offset = 2.07;
period = 0.025;
prio = 3;
power_data.transmitPower = 20;
power_data.name = 1; % We are node number 1 in the network
power_data.receiver = 2; % We are communicating with node 2
power_data.haverun = 0; % We have not run yet
ttCreatePeriod icTask('power_controller_task' , offset, period,
'powctrlcode' , power_data);
ttSetPriority(prio, 'power_controller_task' );

% Create power response task
deadline = 100;
prio = 4;
ttCreateTask( 'power_response_task' , deadline, 'powrespcode' );
ttSetPriority(p rio, 'power_response_task' );

% Initialize network
ttCreateHandler( 'nw_handler' , 1, 'msgRcvActuator' );
ttAttachNetworkHandler( 'nw_handler' );

36
În acest nod rulează 4 taskuri: cel al senzorului (periodic), cel al elementului de
execuție (activat la prim irea unui mesaj de la regulator), cel al testului de putere de emisie
(periodic) si cel de comunicare (răspuns la ping).
Modul de comunicare scoate în evidență tipurile de evenimente care se desfăsoară
într-o rețea de timp real. Există două tipuri de tasku ri: time -driven (acționate de timp) si
event -driven (acționate la producerea unui eveniment.
Taskul senzorului si cel al controlului comunicației sunt periodice, deci sunt acționate
de timp. Taskul elementului de execuție si cel al regulatorului sunt acțio nate de evenimente.
Evenimentul este reprezentat de sosirea unui mesaj din rețea. Din această cauză se crează un
handler de întreruperi care, la sosirea unui mesaj de la controller sau de la controlul emisiei se
va activa, executând codul din msgRcvActuato r.
function [exectime, data] = msgRcvActuator(seg, data)
temp = ttGetMsg;
ttTryPost(temp.type, temp.msg);
if strcmp('control_signal' , temp.type)
ttCreateJob( 'act_task' );
elseif strcmp('power_ping' , temp.type)
ttCreateJob( 'power_response_task' );
end
exectime = -1;
După cum se observă, la primirea unui mesaj, se citeste interfața de rețea cu
ttGetMsg(). Apoi imediat se plasează mesajul primit într -unul din mailbox -uri, după cum este
tipul acestui mesaj.
Dacă tipul mesajului primit este ‘control_signal’ (a dică provine de la controller)
atunci se plasează în mailbox -ul control_signal .
Dacă mesajul provine de la powctrlcode atunci el va fi un m esaj de ping si se va
depune în mailbox -ul power_ping.
Dacă mesajul provine de la powrespcode atunci el se va depune în mailbox -ul
power_resp. Aceste mailbox -uri au fost create în prealabil în fisierul de inițializare.
În faza imediat următoare se crează joburile corespunzătoare: act_task sau
power_response_task . Acestea vor executa codurile din fisierele actcode.m respectiv
powrespcode.m .
function [exectime, data] = actcode(seg, data)
switch seg,
case 1,
% Read all buffered packets
temp = ttTryFetch( 'control_signal' );
while ~isempty(temp),
data.u = temp;
temp = ttTryFetch( 'control_signal' );
end
exectime = 0.0005;
case 2,
ttAnalogOut(1, data.u)
exectime = -1; % finished
end
Observ ăm că taskul corespunz ător elementului de execu ție cite ste datele trimise de
controller din mailbox -ul ‘control_signal’ unde au fost plasate în prealabil de c ătre handler ul
de întreruperi.
Se va face citirea mailbox -urilor pân ă când acesta se gole ste, astfel încât se va
converti analogic ultima valoare intrat ă în stiva FIFO a mailbox -ului, adic ă valoarea corect ă.
Acela si lucru se va întâmpla cu semnalul de control al puter ii:
function [exectime, data] = powrespcode(seg, data)
switch seg,
case 1,
data.msg.msg = ttTryFetch( 'power_ping' );
data.msg.type = 'power_response' ;

37
exectime = 0.00002;
case 2,
% disp(['power ping received from node: ' num2str(data.msg.msg.sende r) ',
sending response'])
ttSendMsg(data.msg.msg.sender, data.msg, 80); % Reply to the sender
exectime = -1; % finished
end
Taskul corespunzãtor senzorului rea lizeazã periodic urmãtoarele acț iuni:
function [exectime, data] = senscode(seg, data)
switch seg,
case 1,
data.msg.msg = ttAnalogIn(1);
exectime = 0.0005;
case 2,
data.msg.type = 'sensor_signal' ;
ttSendMsg(2, data.msg, 80); % Send message (80 bits) to node 2
(controller)
exectime = 0.0004;
case 3,
exectime = -1; % finished
end
Taskul periodic de control al puterii de transmisie implementeazã codul:
function [exectime, data] = powctrlcode(seg, data)
switch seg,
case 1,
% Read all buffered packets
msg = ttTryFetch( 'power_response' ); % Obtain power ping response
temp = msg;
while ~isempty(temp),
y = temp;
temp = ttTryFetch( 'power_response' ); % Obtain power ping response
end

if isempty(msg) & data.haverun ~= 0
% No echo reply, the other node did probably not hear us
data.transmitPower = data.transmitPower + 10;
% Limit the maximum transmit power to 30 dbm
data.transmitPower = min(30, data.transmitPower);
ttSetNetworkParameter( 'transmitpower' , data.transmitPower);
else
% An echo reply, the other did hear us – try to lower the transmission
power
data.transmitPower = data.transmitPower – 0.5;
ttSetNetworkParameter( 'transmitpower' , data.transmitPower);
end
exectime = 0.00002;
case 2,
data.haverun = 1;
msg.msg.sender = data.name;
msg.type = 'power_ping' ;
time = ttCurrentTi me;
%disp(['setting transmitpower to: ' num2str(data.transmitPower) ' in
node: ' num2str(msg.msg.sender) ' at time ' num2str(time)]);
ttSendMsg(data.receiver, msg, 80); % Send 80 bits
exectime = -1; % finished
end

38
Funcția asteaptă răspunsul u nui ping efectuat în prealabil. Dacă nu primeste replica,
trage concluzia că nu a fost auzit, deci măreste puterea de transmisie până la o valoare de
saturație. Dacă primeste replica, atunci înseamnă că a fost auzit de nodul corespondent deci
va diminua pu țin puterea de transmisie pentru a economisi bateria. La final trimite un nou
ping către nodul correspondent[3] .
O funcție asemănătoare, dar neperiodică ci event -driven este powrespcode.m prin care
se realizează replica la un ping primit în prealabil.
Se observă că taskul de răspuns la un ping nu are nevoie de o structură de date proprie
deoarece el doar returnează mesajul primit.
Lucrurile se desfăsoară asemănător la celălalt nod, cu numărul 2, adică nodul
controller.
function regulator_init

% Distribute d control system: regulator node
%
% Receives messages from the sensor node, computes control signal
% and sends it back to the actuator node.

% Initialize TrueTime kernel
ttInitKernel( 'prioFP' ); % fixed priority
ttSetKernelParameter( 'energyconsumption' , 0.010); % 10 mW

% Create mailboxes
ttCreateMailbox( 'sensor_signal' , 10)
ttCreateMailbox( 'power_ping' , 10)
ttCreateMailbox( 'power_response' , 10)

% Controller parameters
h = 0.010;
N = 100000;
Td = 0.035;
K = 1.5;

% Create task data (local memory)
data.u = 0.0;
data.K = K;
data.ad = Td/(N*h+Td);
data.bd = N*K*Td/(N*h+Td);
data.Dold = 0.0;
data.yold = 0.0;

% Create controller task
deadline = h;
prio = 1;
ttCreateTask( 'pid_task' , deadline, 'ctrlcode' , data);
ttSetPriority(prio, 'pid_task' );

% Create power controller task
offset = 2;
period = 0.025;
prio = 2;
power_data.transmitPower = 20;
power_data.name = 2; % We are node number 2 in the network
power_data.receiver = 1; % We are communicating with node 1
power_data.haverun = 0; % We have not ru n yet
ttCreatePeriodicTask( 'power_controller_task' , offset, period,
'powctrlcode' , power_data);
ttSetPriority(prio, 'power_controller_task' );

39
% Create power response task
deadline = 100;
prio = 3;
ttCreateTask( 'power_response_task' , deadline, 'powrespcod e');
ttSetPriority(prio, 'power_response_task' );

% Initialize network
ttCreateHandler( 'nw_handler' , 1, 'msgRcvCtrl' );
ttAttachNetworkHandler( 'nw_handler' );

Taskul activat de eveniment ttMsgRcvCtrl are codul:
function [exectime, data] = msgRcvCtrl(seg , data)
temp = ttGetMsg;
ttTryPost(temp.type, temp.msg);
if strcmp('sensor_signal' , temp.type)
ttCreateJob( 'pid_task' )
elseif strcmp('power_ping' , temp.type)
ttCreateJob( 'power_response_task' );
end
exectime = -1;
Codul executat de controller atunci cân d este activat de handlerul de întreruperi este :
function [exectime, data] = ctrlcode(seg, data)
switch seg,
case 1,
% Read all buffered packets
temp = ttTryFetch( 'sensor_signal' );
while ~isempty(temp),
y = temp;
temp = ttTryFetch( 'sensor_ signal');
end
r = ttAnalogIn(1); % Read reference value
P = data.K*(r -y);
D = data.ad*data.Dold + data.bd*(data.yold -y);
data.u = P + D;
data.Dold = D;
data.yold = y;
exectime = 0.0005;
case 2,
msg.msg = data.u;
msg.type = 'control_ signal';
ttSendMsg(1, msg, 80); % Send 80 bits to node 1 (actuator)
exectime = -1; % finished
end

Rezultatele primite în linia de comandă Matlab
Datele primite de la rețeaua wireless :
Puterea de transmisie : 30.00 dbm <==> 1000.00 mW
Pragul de rece pție a datelor : -48.00 dbm <==> 1.58e -05 mW
Distanța maxima calculată de recepție a semnalului : 168.27 m

40
5.1.2.Rezultate în simulare

Simulările se fac cu rețeaua 802.11b WLAN. Dacã vom face simulãrile cu valorile
implicite, vom obț ine rezultatele prezentate în figura de m ai jos. Se observã cã performanț ele
nu sunt repetabile. Acest lucru este explicabil prin faptul cã anumite mãsuri se pot pierde
datoritã mecanismului simplu de control al transmisiei pe care l -am implementat.

Fig.32.Referința tre aptă r,ieșirea sistemului y și comanda u la 

Fig.33.Schedule pentru nodul elementului de execuție 

41

Fig.34.Network Schedule

Fig.35. Schedule pentru nodul kernel(computer)

Fig.36. Bateria pentru elementul de execuție și pentru regulato r

42

Fig.37.Referința treaptă r,ieșirea sistemului y și comanda u la 
Se poate observa din ultima simulare că la un  față de un  sistemul
isi pierde stabilitatea ajungând chiar în instabilitate, deci cu o întârziere mai mica avem u n
sistem de conducere mult mai stabil.
Pentru următorul experiment se va dezactiva schema de control a puterii de
transmisie. Acest lucru se poate face simplu transformând în comentarii secven ța de creare a
taskului power_controller_task în fisierul de i nițializare controller_init .

Fig.38.Influenta blocului battery asupra motorului de c.c.
Dacă se va relua simularea, vom nota cum puterea baterie scade constant si la un
moment dat (dup ă aproximativ 6 secunde) motorul r ămâne necomandat.Bateria r ămâne f ără
energie si controlul se pierde.

43
5.2.Simularea unui NCS folosind protocolul 802.15.4(ZigBee)
Tehnologia ZigBee a devenit recent una dintre opțiunile importante și semnificative
pentru rețeaua wireless(WSN) ,deoarece are multe avantaje cum ar fi:consumul re dus de
energie,date mai puține de transmis, costuri reduse și caracteristici de întârziere de scurtă
durată. ZigBee este singurul standard bazat doar pe tehnologia 802.15.4 . Protocolul ZigBee
include: suport pentru mai multe topologii de rețea cum ar fi pu nct la punct, multipunct,
rețele mesh , un ciclu scurt de funcționare care duce la o viață lungă a bateriei, latent redusă,
pînă la 65,000 noduri pe rețea ,criptare conexiuni sigure [14,15].
Aplicații pentru protocolul ZigBee sunt:automatizarea cladirilor(BMS ), sisteme de
securitate , control de la distanță( remote ), citirea contorului de la distanță(IoT -Internet of
Things) [16].
5.2.1.Simularea cu blocuri standalone Send/Receive
Fiecare schema realizată pentru simulare Simulink/TrueTime conțtine un bloc pentru
regulatorul PID(PD/PI/P), procesul controlat si bloc ul pentru rețeaua cu fir sau fară fir.Pentru
exemplul următorul exemplu se folosește un regulat or PID și o funcție de transfer pentru
procesul controlat [18].
Funcțiile de transfer pentru proces (Gp(s)) și regulator (Gc(s)) sunt:

Pentru rețeaua wireless se for realiza mai multe simulări pentru a demonstra influența
perioadei de eșantionare, numărului de noduri, și abandonul de pachete(packet dropouts)
asupra performanțelor NCS -ului.Cele trei caracteristic i sunt prezentate în cele ce urmează.
5.2.1.1.Perioada de eșantionare
Într-un NCS senzorii măsoară parametrii procesului controlat într -un timp periodic.
Pentru majoritatea sistemelor dinamice mai multe măsurători duc la ocontrol al sistemului
mult mai bun . Sistemele NCS nu sunt obligate sa aiba acelasi răspuns in diverse situații. O
perioada de eșantionare mai mare poate cauza un flux de date mare si un o suprasaturare a
rețelei ducând astfel la întârzieri în rețea iar performanțele sistemului pot fi degra date[15].
5.2.1.2.Numărul de noduri
Principalul scop al implementării unei comunicații intr -un sistem de conducere este
acela de a controla mai multe sisteme prin aceeași rețea.Creierea mai multor sisteme
prinadaugarea mai multor noduri poate de asemenea d uce la suprasaturarea cu date a rețelei
deoarece există cerere de transmisie de date din partea mai multor noduri pe același canal în
acelasi timp [15].
5.2.1.3. Pierderi de pachete
Într-o rețeaua wireless există o probabilitate mai mare ca o anumită cantita te de
informații să fie pierdută pe parcursului unui process de transmisie de date.Acest lucru poate
fi cauzat de perturbări în process, în mediu, sau de o distanță mai lungă între noduri. Cand
transmisia de pachete este pierdută, retransmisia datelor este posibilă când perioada de
eșantionare nu este foarte mică.
Sistemul NCS este controlat de un regulator PI cu urmatorii parametrii:

44

Fig.39.Parametrii regulatorului PI 

Fig.40.Schema Simulink/TrueTime a NCS -ului wireless ZigBee 
5.2.2.Rezultate în simul are

Fig.41. Performanțele NCS -ului cu o perioada de eșantionare de 0.005s

45

Fig.42.Performanțele NCS -ului cu o perioada de eșantionare de 0.00285s
În prima simulare (figura 39,40) se schimbă perioada de eșantionare de la 0.005 s la
0.00285s. Communicați a a fost supraîncărcată și performanța sistemului de conducere a
scăzut.

Fig.43. Performanțele NCS -ului cu 14 noduri
A doua simulare, în momentul când se adaugă mai multe noduri performanța
sistemului scade , suprareglajul este mare iar timpul de creșter e la fel.

Fig.44. Performanțele NCS -ului cu 15% pierderi de pachete
A treia simulare, se poate observa performanța sistemului față de referință în
momentul când existâ pierderi de pachete și când nu există pierderi de pachete.Suprareglajul
în primul caz este mai mare iar performantele sistemului scad.
După cum s -a putut observa performantele NCS -ului cand are în component o rețea
cu fir este mult mai bună decât atunci când rețeaua este wireless. 

46
6.Avantajele/Dezavantajele folosirii sistemelor distribuite de
conduce re

Aplica țiile moderne utilizeaz ă pe scar ă tot mai larg ă sistemele de control în re țea.
Având în vedere tendin ța vizibil ă de generalizare a acestui tip de control datorit ă avantajelor
de care dispune, vom scoate în eviden ță câteva dintre carac teristicile sale.
La capitolul avantaje , putem enumera:
– Cost de implementare sc ăzut: o aplica ție de control distribuit utilizeaz ă o rețea de
comunica ție dotat ă cu un protocol de comunicare standardizat. Blocurile componente
ale unui sistem de control în rețea sunt concentrate în anumite noduri ale re țelei. Semnalele
(numerice) de m ăsură si control circul ă între diferitele noduri ale re țelei în pachete de date
conform protocolului de comunica ție utilizat. Rezult ă că un sistem de control se poate
implementa foarte rapid f ără a fi nevoie de leg ături electrice direc ționate si specifice între
blocurile componente ale sistemului, sc ăzând sim țitor costul de exploatare și implementare.
-Flexibilitate sporit ă: arhitectura unui SRA în re țea se poate modifica foarte simplu
adăugând sau sco țând din re țea blocuri componente ale sistemului, f ără a fi obliga ți să
reconfigur ăm vreun sistem de leg ături electrice [3].
– Fiabilitate sporit ă: datorit ă faptului c ă transferul de semnal (informa ție) este realizat
‘inteligent’, se pot face diagnostic ări periodice ale func ționării diferitelor blocuri
componente si lua decizii de reparare sau înlocuire a lor f ără a afecta decisiv func ționarea
sistemului în ansamblul s ău.
– Complexitate sporit ă: sistemul de control poate cre ste în complex itate numai prin
modific ări software . Se schimb ă algoritmii numerici de reglare. Ad ăugarea unor noi
blocuri componente se face prin simpla cuplare la re țea.
-Implementarea de sub -sisteme autonome (sisteme înglobate, embedded ): se poate
implementa un sistem de conducere descentralizat prin folosirea local ă a unor subsisteme de
control cu func ționare în timp real independent ă. Aceste sub -sisteme autonom comunic ă între
ele si cu un host central pentru realizarea unor sarcini de monitorizare si schimbare de
parametri.
La capitolul dezavantaje , putem enumera toate neajunsurile pe care le întâmpin ă
utilizatorii obi șnuiți ai unei re țele :
– Intârzieri în re țea: comenzile c ătre nodurile elementelor de execu ție si măsurile de la
nodurile senzorilo r au o întârziere variabil ă datorat ă traficului din re țea.
– Pierderi de date : datorit ă coliziunilor de date în re țelele cu protocol care permite
acest lucru se pot pierde pachete cu informa ții de comand ă sau de m ăsură. Acest lucru poate
conduce la o func ționare nedorit ă a sistemului de control.
– Dacă rețeaua nu mai func ționeaz ă, se întrerupe func ționarea tuturor sistemelor de
control care utilizeaz ă rețeaua.
Pentru a reduce din neajunsurile mai sus men ționate, se utilizeaz ă arhitecturi de re țea
sau protoc oale de comunica ție cu caracter particular, dar standardizate dup ă normative foarte
precise [3].

47
7.Concluzii

În această lucrare am prezentat cele doua metode prin care pot fi simulate sistemele
distrbuite de conducere în timp real, cu rețea cu fir si cu reț ea wireless, rezultatele fiecarei
simulări în parte, fiecare metoda fiind implementată cu câte doua protocoale diferite pentru a
putea observa mai bine influența diversilor parametrii asupra performanțelor sistemului de
conducere distribuit.
În primul capi tol Introducere am introdus noțiunile generale pentru a putea simula un
astfel de sistem, despre sistemele distribuite de conducere, despre toolbox -ul TrueTime si
funcțiile blocurilor acestuia: TrueTime kernel, TrueTime network, TrueTime wireless network,
TrueTime Send/Receive, TrueTime Battery.
În al doilea capitol Rețeaua Truetime în NCS am prezentat mai pe larg blocul Network
atât cu fir cât si wireless, prezentând si toate protocoalele prin care pot fi implementate aceste
două rețele:wired(CAN,ETHERNETM FDMA, TDMA etc.) și wireless(WLAN și ZigBee).
În capitolul al treilea, Platforma de lucru:TrueTime Simulink/Matlab , am prezentat
cum se folosește toolbox -ul Truetime în cadrul Matlab -ului, cum se setează parametrii ș ice
script trebuie rulat ca acest toolb ox să funcționeze în cele mai bune condiții și correct.
În capitolul patru, Analiza performanțelor sistemelor distribuite de conducere wired
introduc câteva noțiuni despre efectul întârzierilor în cadrul unui sistem NCS, afirmațiile
sustinându -le cu doua simulari ale aceluiași sistem condus de un regulator PD, cu acelasi
proces controlat (motor de c.c.) folosind doua protocoale diferite:CAN și Ethernet.Rezultatele
simulărilor au aratat că intârzierile în rețea în cele doua cazuri se comportă diferit și sun t
controlate mai bine încadrul protocolului CAN.
În capitolul cinci, Analiza performanțelor sistemelor distribuite de conducere wireless
se realizează în primul rând o analiză a performanțelor unui sistem de conducere simulat cu
ajutorul Truetime -ului cu b locul Kernel și funcții m-file de inițializare si calculul
regulatorului, în al doilea rând se folosește un alt sistem de conducere ce este simulat cu
ajutorul blocurilor standalone Send/Receive nemaifiind nevoie de anumite funcții de
inițializare.În acest caz urmăresc analiza sistemului de conducere în momentul când intervine
schimbarea mai multor parametrii:perioada de eșantionare, numărul de noduri(sisteme) din
rețea și pierderea de pachete.Concluziile pentru fiecare caz în parte au fost trase în cadrul
fiecărui subcapitol.
După toate simulările realizate cu diverse tehnologii și protocoale am ajuns la
concluzia că comunicația prin fir(în ziua de azi cea mai bună fiind fibra optică dar și cea mai
scumpă) este cea mai sigură, cea mai fiabila și eficienta metodă de a transfera pachete de date
intr-o rețea implementată în cadrul unui sisteme de conducere distribuit(NCS).

48
8.Bibliografie

[1] M. Foltin, J. Murgaš. Sieťové riadenie procesov – formulácia a trendy , Elosys ’07,
Trenčín 2007.
[2] M. Jamshidi. Large-scale systems: modeling, control and fuzzy logic , Prentice Hall
[3] Utilizarea sub Si mulink a toolbox -ului True Time pentru simularea aplicațiilor de
timp real în rețea , 2012
[4]A. Cervin et. al. TrueTime 2.0 beta – Reference Manual , Department of Auto matic
Control, Lund University, January 2010
[5] J. Slipp Farkas, J. Hnát et al. WINTeR: Architecture and Applications of a Wireless
Industrial Sensor Network testbed for Radio -Harsh Environments , Communication
Networks and Services Research Conference, 2008, 422 -431, IS BN 978 -0-7695 –
3135 -9
[6] SIMULATI ON OF NETWORKED CONTROL SYSTEMS USING TRUETIMEĽ.
[7] DziÑac, I., Moldovan, G ., Sisteme distribuite – Modele info rmatice, Ed. Univ.
Agora, 2006, ISBN (10) 973 -87960 -9-1 ; ISBN (13) 978 -973-87960 -9-6, 146 p.
[8] SICOTIR 71 -084 REZUMATUL FAZEI a II -a (2008) Instrumente pentru modelarea
RTNCS: TrueTime sub Simulink
[9] Y . Wang, L. He , 2013, Vol.17, No. 4, 210 -216 Computer Modelling and New
Technologies Transport and Telecommunication Institute, Lomonosov 1, LV -1019,
Riga, Lat via ANALYSIS AND SIMULATION OF NETWORKED CONTROL
SYSTEMS DELAY CHARACTERISTICS BASED ON TRUETIME
[10] International Journal of Intelligent Engineering and Systems, Vol.3, No.2,2010
Performance Analysis of Wireless Network Measurement Contro l System using
Matlab/Simulink Shurui Fan, Jingbo Li, Jie Li, Hexu Sun
[11] Guo, X.,Wu,B.(2010) The Impact of Time -delay on Networked Control System
and Stability Region Analysis of PID Controllers [C]. International Conference on
Computer, Mechatroni cs, Control and Electronic Engineering (CMCE) , 163 -166.
[12] Jing, N., Wang L., An, B. -Y . (2009) Analysis and policy of network latency in CAN
control system [J]. Computer Engineering and Design , 30(20), 4599 -4602.
[13] Rui, D., Xian -Ming, T., Yu, J. -S. (2010) Analysis of Delay Compensation in NCS
based on TrueTime Tool Box [J]. Industrial Control Computer , 23(2), 24 -26.
[14] [Ch.-Ch. Song ; Ch. -F. Feng ; Ch. -H. Wang ; D. -Ch. Liaw. Simulation and
experimental analysis of a ZigBee sensor network with faul t detection and
reconfiguration mechanism , Control Conference (ASCC), 2011 8th Asian, p. 659 –
664
[15] ZigBee Alliance, ZigBee Technology [online] ZigBee Alliance, cit: 12.10.2011,
available at<http://www.zigbee.org >
[16] Z. Bradáč, P. Fiedler, O. Hynčic a, F. Bradáč, Design of ZigBee Device, Proceedings
of theWSEAS Conference: Automatic Control, Modelling and Simulation (ACMOS
'05), Prague, Czech Republic, March 13 -15, 2005
[17] M. Urban, M. Blaho, J. M urgaš, M. Foltin SIMULATION OF NETWORKED
CONTROL SYSTEMS VIA TRUETIME
[18] Y . Tipsuwan, M. -Y . Chow. Control methodologies in net worked control systems,
Control Engineering Practice 11 (2003) pp. 1099 –1111