Toader Andrei Proiect de Diploma

Universitatea POLITEHNICA din Bucureşti
FACULTATEA DE ENERGETICĂ
060042 Bucureşti, Splaiul Independenţei, nr. 313, sector 6
PROIECT DE DIPLOMĂ
Implementarea protocolului M-bus pentru o aplicație de
smart metering
Autor: Andrei M. TOADER
Cadru didactic îndrumător: Conf. Dr. Ing. Vladimir TANASIEV
București
Iulie 2020
Departamentul de Sisteme Electroenergetice
Proiect de diplomă
Implementarea protocolului M-bus pentru o

aplicație de smart metering
prezentat la
Universitatea POLITEHNICA din București

Facultate de Energetică
pentru obținerea titlului de

inginer
Specializarea: Informatică industrială
de către
Andrei M. TOADER
(absolvent UPB)
sub îndrumarea
Conf. Dr. Ing. Vladimir TANASIEV
Susținut în Iulie, în fața comisiei de examinare
Prof. dr. ing. Constantin BULAC Președinte

Prof. dr. ing. Virgil DUMBRAVĂ Membru
Prof. dr. ing. Ion TRIȘTIU Membru
Conf. dr. ing. Radu PORUMB Membru
Ș.l. dr. ing. Dorian Octavian SIDEA Membru
Ș.l. dr. ing. Nicoleta ARGHIRA Membru
As. drd. Andreea Ianțoc Secretar
Această lucrare a fost pregătită în cadrul Facultății de Energetică a UPB

2
Pag.
INTRODUCERE............................................................................................ 5
CAPITOLUL 1
STIVA ISO OSI ȘI TOPOLOGII DE REȚEA............................................ 6
1.1. Funcții de bază ale sistemului Bus......................................................... 6

1.2. Modelul de referință OSI........................................................................ 8
1.3. M-bus și modelul OSI.............................................................................. 10
CAPITOLUL 2
STANDARDUL M-BUS - ASPECTE TEHNICE....................................... 12
2.1. Nivelul fizic............................................................................................... 12

2.1.1 Generalități……………………………………………………….. 12
2.1.2 Comunicarea prin cablu (M-Bus)……………………………….. 13
2.1.2.1 Specificații electrice................................................................. 13
2.1.2.2 Conexiuni hardware și cablu………………………………... 13
2.1.3 Comunicarea wireless (wM-Bus)………………………………... 14
2.1.3.1 Moduri și cerințe…………………………………………….. 14
2.1.3.2 Transmisie sincronă versus asincronă………………………. 15
2.2. Nivelul de date......................................................................................... 16
2.3. Formatul telegramelor............................................................................ 17
2.3.1 Specificul secțiunilor…………………………………………….. 19
2.3.2 Procesul de comunicare………………………………………….. 21
2.3.3 Biții FCB, FCV și adresarea……………………………………... 22
2.3.3.1 Aplicații ale mecanismului FCB (Frame Count-Bit) -
Răspunsuri multi-telegramă (RSP_UD) de la slave la master……… 22
2.3.3.2 Telegrame cu răspuns “blocat” (frozen answer) de la slave
la master……………………………………………………………... 22
2.3.3.3 Date cu mai multe telegrame (SND_UD) de la master la
slave………………………………………………………………….. 23
2.3.3.4 Acțiuni incrementale în dispozitivul slave ințiate de
dispozitivul master................................................................................ 23
2.3.4 Aspecte de implementare a adresării primare.............................. 24
2.4. Nivelul de aplicație.................................................................................. 26
2.4.1 Câmpul CI........................................................................................ 26
2.4.2 Structura datelor fixe...................................................................... 28
2.4.3 Structura datelor variabile............................................................. 30
3
2.4.4 Bloc de date specific producătorului............................................. 34

2.5. Configurarea componentelor dispozitivului slave................................ 35
CAPITOLUL 3
STUDIU DE CAZ, IMPLEMENTAREA UNEI APLICAȚII DE
SMART METERING.................................................................................... 40
3.1. Implementarea soluției software............................................................ 40

3.2. Implementarea soluției hardware.......................................................... 44
3.3. Prelucrarea datelor măsurate................................................................ 50
CAPITOLUL 4
IMPLEMENTAREA SOLUȚIEI DE IoT PENTRU STOCAREA ȘI
PROCESAREA DATELOR.......................................................................... 53
4.1. Configurarea soluției IoT pentru stocarea datelor.............................. 53

4.2. Implementarea soluției de procesare a datelor..................................... 58
CONCLUZII ................................................................................................ 61
BIBLIOGRAFIE........................................................................................... 63
4
INTRODUCERE
Indiferent de domeniul de activitate, de industria în care se profesează, de momentul

zilei, datele informatice au devenit o resursă indispensabilă pentru desfășurarea activităților.
Datele digitale fac parte din nevoile indivizilor, indiferent de contextul social, economic,
politic, cultural sau religios în care se regăsesc. Astfel, șansele ca populația să depindă de
aceste date, sunt din ce în ce mai mari, în funcție de aspirații și de mediul în care se dezvoltă.
Conform studiilor din ultimii ani [4], volumul de date crește în fiecare zi datorită atât
evoluției tehnologiei, cât și unor concepte precum Internet of Things.
Internet of Things descrie interconexiunea dintre așa numitele dispozitive inteligente.
De obicei un dispozitiv inteligent este un dispozitiv care deține tehnologii necesare dobândirii
de noi capabilități. De regulă, un procesor este adăugat dispozitivelor pentru a le face mai
inteligente, capabile să interacționeze și să comunice informații, aceasta fiind caracteristica
principală a unui dispozitiv inteligent. În primul rând, interacțiunea constă în colectarea
datelor despre mediul în care se află dispozitivele. Informațiile sunt procesate și posibil
răspândite, astfel încât prelucrarea acestora poate conduce la o nouă interacțiune, dispozitivele
comportându-se conform pașilor anteriori.
Scopul lucrării constă în prezentarea unei soluții inteligente cu ajutorul dispozitivelor
de tip master-slave care folosesc protocolul M-Bus pentru comunicație și transmiterea datelor,
în vederea monitorizării diferiților parametrii din rețeaua proprie necesari observării/
identificării în orice moment al zilei atât al consumului de electricitate, cât și al intensității și
tensiunii curentului din rețea.
Datele colectate prin intermediul dispozitivelor de tip master-slave sunt stocate pe o
platformă de tip cloud (Wago Cloud) în vederea vizualizarii sub forma de grafice interactive
a acestora. Astfel, prin implementarea soluției inteligente se va putea observa evoluția pe
termen mediu și lung a consumului de curent, precum și a diferiților parametrii din rețea.
Lucrarea este structurată pe patru capitole distincte în care se prezintă aspecte teoretice
precum și aspecte practice. Capitolul 1 conține elemente teoretice legate de protocolul M-Bus
(funcții de bază ale sistemului și modelul de referință). Capitolul 2 prezintă în detaliu
informații despre structura standardului M-Bus. În capitolul 3 se prezintă echipamentul
utilizat și procedura utilizată pentru colectarea datelor. În capitolul 4 se prezintă
implementarea aplicației pentru stocarea în Cloud și procesarea datelor preluate de la
dispozitivele de tip master-slave. În ultimul capitolul destinat concluzilor, sunt prezentate
principalele concluzii și posibilitățile de dezvoltare ulterioară ale aplicației.
5
CAPITOLUL 1
STIVA ISO OSI ȘI TOPOLOGII DE REȚEA
1.1. Funcții de bază ale sistemului Bus
M-bus (Meter-Bus) este un standard european ce a fost dezvoltat pentru a satisface

nevoia unui sistem pentru transmiterea datelor în rețea și citirea de la distanță a contoarelor de
utilități. Comunicația M-Bus se poate realiza prin intermediul a 2 fire [EN 13757-2] sau fără
fir [EN 13757-4].
Utilizat la scară largă pentru simplitate și consum scăzut de resurse (energie și
procesare), acest protocol a fost dezvoltat in anul 1997 de profesorul Horst Ziegler în
parteneriat cu TI pentru contorizarea căldurii, definit inițial în standardul [EN1434].
Când sunt interogate, contoarele livrează datele pe care le-au colectat unui dispozitiv
master comun, care poate fi, de exemplu, un laptop, conectat la intervale periodice pentru a
citi toate contoarele de utilitate ale unei clădiri. O metodă alternativă de colectare a datelor
este transmiterea citirilor de contor prin intermediul unui modem [1].
Tehnici de accesare
Pentru utilizarea protocolului M-Bus trebuie ținut cont de anumite tehnici de accesare,
deoarece în sistemul bus, mediul de transmisie este utilizat de toate dispozitivele participante.
Metodele utilizate de participanții care doresc să transmită date sunt cunoscute ca tehnici de
accesare. Aceste tehnici trebuie să se asigure că mai multe dispozitive nu transmit simultan, să
nu existe conflicte sau coliziuni de date, astfel fiecare dispozitiv poate transmite pentru o
perioadă minimă de timp.
Utilizarea dispozitivelor care doresc să transmită este implementată cu ajutorul unui
sistem logic de alocare.
Cu logica centrală de alocare, controlerul principal primește o cerere de utilizare a
port-ului și după decide dacă se poate utiliza acest port și momentul în care se poate accesa.
Pentru acest scop sunt utilizate diferite metode de înregistrare a cererilor de ocuparea a
port-ului:
- înregistrare directă a fiecărui echipament
- interogare periodică a participanților cât și a cerințelor de transmisie
- cereri trimise pe o linie comună pentru a se identifica emitorul
- alocarea port-ului pentru o perioadă predeterminată de timp fără a se ține cont de
cerințele individuale
Avantajul logicii centrale de alocare este reducerea complexității necesare stațiilor
individuale.
6
În majoritatea reţelelor locale, una din următoarele topologii exemplificate în Figura

1.1 sunt folosite pentru a conecta componentele la sistem [1].
Fig. 1.1 Topologii de rețea
Stea: Fiecare componentă este conectată la o unitate de procesare centrală cu o linie

de transmisie individuală. Echipamentul poate transmite către unitatea centrală fie pe rând, fie
simultan.
Inel: În acest caz, componentele sunt conectate una la alta într-un inel, şi datele sunt
transferate de la un punct la altul. Dezavantajul acestei topologii îl reprezintă faptul că, dacă
un singur element nu mai merge, întreaga reţea nu va mai funcţiona.
Bus: Componentele sunt conectate printr-o linie de transmisie comună, la orice
moment dat doar un singur echipament poate transmite date. Eficientă din punct de vedere al
costului. Rețeaua rămâne funcţională dacă apare un defect [13].
Sincronizarea participanților
Sincronizarea reprezintă coordonarea în timp a participanților care comunică în ceea
ce privește transmisia și recepția semnalului. Diferitele metode de sincronizare pot fi
clasificate în transmisie de date care este sincronă și care este asincronă (Figura 1.2) [2].
Fig. 1.2 Clasificarea tehnicilor de sincronizare
7
Acolo unde există o confirmare a semnalului (handshake), expeditorul arată cu un

semnal specific pe linie că are date de trimis și așteaptă o confirmare de la receptor. Tehnicile
fără confirmare folosesc un timp de transfer pe o linie specială pentru transmisia de paralelă
de biți sau biți de pornire și oprire pentru a încadra un caracter pentru transmisie de biți [2].
Procesarea erorilor
Motivul apariţiei erorilor în transmisia de date în sistemul bus sunt în general
cunoscute. Acestea includ în particular interferenţele electromagnetice din exterior. Un sistem
bus trebuie să asigure ca erorile de transmisie să fie recunoscute si corectate. Din acest motiv
informaţii suplimentare trebuie să fie adăugate la datele transmise pentru a putea verifica
datele primite.
La transmisia asincronă, un bit adiţional de paritate este folosit de obicei la transmisia
fiecărui caracter. Bitul de paritate (un număr par de valori de „1” sau un număr impar de
valori de „1”) este construit pentru a verifica condiţia de paritate.
Bitul de paritate permite doar recunoașterea unui număr impar de biți defecți. Pentru a
corecta erorile, destinatarul trimite o confirmare, care indică faptul că transmisia a fost fie fără
erori, fie că au fost erori de transmisie. În același scop, emițătorul verifică dacă receptorul
recunoaște recepția datelor într-o anumită perioadă de timp. Dacă se depășește limita de timp
(Timeout) sau dacă a fost raportată o eroare de transmisie, atunci expeditorul repetă
transmisia un număr de ori predeterminat.
O altă metodă de verificare este prin adaugarea unei sume de control (Check sum) de
dimensiuni reduse derivata din blocul de date transmis [2].
1.2. Modelul de referință OSI

Modelul de referință ISO-OSI oferă o bază pentru dezvoltarea standardelor pentru
interconectarea sistemelor deschise (Open Systems Interconnection - OSI). Acest model
realizat de „International Organization for Standardization” (ISO) are rolul de a asigura că
informaţiile de la sistemele dezvoltate de diferiţi producători, deci având o structură diferită,
pot fi transmise şi interpretate în concordanţă cu procedurile standardizate [2].
Acest model grupează protocoalele de comunicare în 7 niveluri, fiecare având o

conexiune virtuală cu nivelul adecvat al dispozitivului cu care se comunică. Doar pe nivelul
cel mai de jos (Nivelul 1) există o conexiune fizică pentru transmiterea semnalelor.
Fiecare nivel, cu excepţia nivelului 1, obține setul de date necesar de pe nivelul

anterior. Modelul OSI defineşte doar funcţionarea nivelurilor, dar nu şi realizarea tehnică
(protocoalele) din interiorul nivelurilor.
Două programe de utilizator pot schimba informații pe stratul 7, dacă există un acord
între ele (adică există protocoale) cu privire la următoarele puncte [2]:
- reprezentarea informațiilor în stratul 6;
- fluxul de comunicații (conținut și formă) din stratul 5;
8
- caracterul complet al informațiilor și securitatea transportului în stratul 4;

- modul în care informațiile trebuie transferate prin rețea în stratul 3;
- securitatea transmisiei în stratul 2;
- mediul fizic din stratul 1.
Tabel 1.1 Reparția pe straturi a protocolului M-bus

7 Strat de aplicație
6 Strat de prezentare Straturi orientate
5 Strat de sesiune către aplicație
4 Strat de transport
3 Strat de rețea Straturi orientate
2 Stratul legăturii de date către transport
1 Strat fizic
Stratul fizic
Conexiunea fizică de bază între partenerii comunicanți are loc în acest cel mai de jos
strat. Cuplarea mecanică și electrică la mediul de transmisie este determinată aici, specificând
(printre altele) cablul, distanțele implicate, fixarea conectorilor și modul în care sunt
reprezentați biții.
Stratul legăturii de date

Acest strat este responsabil de asigurarea faptului că o conexiune de funcționare
fiabilă se face între doi participanți.
În acest scop, protocolul acestui strat determină metodele de protejare a transmisiilor,
structura telegramelor, metodele de acces la mediul de transmisie și pentru sincronizarea și
adresarea participanților. Folosind procedurile, ar trebui să fie posibilă identificarea și
corectarea defecțiunilor din stratul legăturii de date.
Stratul de rețea
Stratul de rețea se angajează să aleagă și să implementeze cea mai bună rută de
transmisie într-o rețea între părțile care comunică și furnizează acest serviciu (rutare) stratului
de transport. Această funcție are o semnificație deosebită atunci când trebuie conectate
diferite rețele prin intermediul Gateway-urilor.
Stratul de transport
Stratul de transport reprezintă granița dintre straturile orientate către aplicație 5 până la
7 și straturile de transport 1 până la 4. Acesta are rolul să ghideze informațiile prin rețea,
controlul fluxului de informații și gruparea în pachete individuale.
9
Stratul de sesiune
Stratul de sesiune oferă proceduri pentru deschiderea, progresarea ordonată și
încheierea unei „sesiuni” de comunicare. În acesta este inclus și controlul dialogului dintre
sisteme: adică determinarea privilegiilor respective de transmitere.
Stratul de prezentare
Datele aplicației sunt convertite în stratul de prezentare într-un format de date pe care
aplicația receptoare îl poate interpreta. Acest strat implementează astfel potrivirea formatelor
de date și conversia codurilor.
Stratul de aplicație
Acest strat superior reprezintă interfața dintre sistemul deschis și utilizator. Acesta
oferă utilizatorului sau programului său un serviciu care îi permite să lucreze ușor cu sistemul.
Programele de aplicații care trebuie dezvoltate pot astfel accesa funcțiile sistemului deschis
prin protocolul stratului de aplicații.
1.3. M-bus și modelul OSI
Protocolul M-Bus este separat în mai multe straturi pe baza modelului de strat OSI 7.
Acest document este structurat în funcție de stratul de comunicare aplicat prezentat în Figura
1.3.
Fig. 1.3 Repartiția pe straturi a protocolului M-bus conform modelului OSI
APL
Strat de aplicație
TPL
Strat de transport
AFL
Strat de autentificare și fragmentare
ELL
Strat de legătură extins
DLL
Stratul legăturii de date
PHY
Strat fizic
Stratul fizic (PHY) și stratul de legătură de date (DLL) sunt întotdeauna prezente.
Stratul de transport (TPL) și stratul de aplicație aplicat (APL dacă există) sunt întotdeauna
introduse de câmpul CI al stratului de transport. Straturi opționale precum ELL sau AFL sunt
introduse de câmpurile CI speciale. Într-un astfel de caz, mesajul M-Bus conține mai multe
câmpuri CI, înlănțuite unul cu altul.
10
Traseul urmat de date de la transmitor la receptor se realizează conform celor

prezentate în Figura 1.4, prin indicațiile date de către săgețile continue.
Fig. 1.4 Transmiterea datelor în conformitate cu modelul OSI
La partea de transmitere a informațiilor (overhead), care este necesară pentru transmisie

și prelucrare, se adaugă la datele reale din fiecare strat; la partea destinatară, aceste informații
sunt eliminate din nou în ordine inversă după procesare [3].
11
CAPITOLUL 2
STANDARDUL M-BUS, ASPECTE TEHNICE
2.1. Nivelul fizic
2.1.1 Generalități
Datele se colectează de la contoare folosind un modul M-Bus cu două fire prin modul de
tragere sau M-Bus wireless (wM-Bus) prin modul push. Acest lucru înseamnă că, contoarele
transmit date de contorizare prin RF în intervale regulate sau că trebuie să fie interogate prin M-
Bus cu cablu prin gateway. Opțional gateway-ul poate interoga, de asemenea, datele de
contorizare de la contoarele M-Bus fără fir bidirecționale.
M-bus este un sistem ierarhic, cu comunicarea controlată de un master (logică centrală de

alocare). Pe acest nivel are loc conexiunea fizică între dispozitivele care comunică. Cuplajele
electrice şi mecanice la mediul de transmitere sunt determinate pe acest nivel, specificând
(printre altele) cablul, distanţa de transmisie, conectorii, şi felul în care sunt reprezentaţi biţii.
M-bus este format dintr-un dispozitiv master, un număr de dispositive slave (contoare) şi un
cablu de conectare pe două fire. Contoarele sunt conectate în paralel la mediul de transmitere
prin intermediul cablurilor de conectare (Figura 2.1)
Fig. 2.1 Reprezentarea principiului de funcționare al sistemului M-Bus
Transferul de biţi master-slave este realizat prin intermediul a 2 tensiuni. O valoarea

logică „1” (Mark) corespunde unui nivel nominal de +36 V la ieşire, iar o valoare logică „0”
(Space) este interpretata ca fiind tensiunea nominală de 24 V la ieşire (Figura 2.2) [2].
12
Fig. 2.2 Reprezentarea biților în protocolul M-Bus
Biții transmiți de la dispozitivele slave la master sunt modulați in curent. O valoare logică
„1” are un curent constant de până la 1.5 mA, şi o valoare logică „0” este reprezentată printr-un
exces de consum din partea slave-ului cu până la 11-20 mA.
2.1.2 Comunicarea prin cablu (M-Bus)
2.1.2.1 Specificații electrice

Pentru conexiunile cu fir se utilizează stratul M-Bus PHY conform standardului european
[EN 13757-2:2004]. Dispozitivele care utilizează protocolul M-Bus sunt sisteme cu două fire
care, în mod optional pot furniza energie electrică pentru dispozitivele conectate. Numărul de
dispozitive M-Bus, care poate fi controlat printr-o poartă, este specificat de producător. Cerințele
minime sunt cele ale unui Mini-Master așa cum este descris în standardul [EN 13757-2:2004][2].
2.1.2.2 Conexiuni hardware și cablu
Interferențele bus ale slave-ilor sunt independente de polaritate, ceea ce înseamnă că cele
două linii de bus pot fi inversate fără a afecta funcționarea dispozitivelor slave. Pe lângă
aspectele de protecție, acest lucru duce și la o instalare simplificată a sistemului de bus. Pentru a
menține funcționarea corectă a bus-ului în cazul unui scurtcircuit al unuia dintre dispozitivele
slave, acestea trebuie să aibă o rezistență de protecție cu o valoare nominală de 430 ± 10 Ω în
liniile lor de bus. Aceasta limitează curentul în cazul unui scurt circuit până la maximum 100 mA
(42 V / 420 Ω). Pentru cerințele pentru cablare și instalare se consultă standardul [EN 13757-
2:2004] [2].
13
2.1.3 Comunicarea wireless (wM-Bus)
2.1.3.1 Moduri și cerințe

Standardul [EN 13757-4:2013] descrie diferite variante pentru comunicarea contorului
wireless. Ele acoperă toate tipurile de comunicații ale contorului, inclusiv modurile de citire
mobile și staționare. Scenariul Open Metering System (OMS) necesită un receptor staționar și o
transmitere frecventă a datelor contorului pentru a sprijini feedback-ul consumatorilor și tarifele
variabile. Acest document se extinde [EN 13757-4: 2013] pentru a permite retransmiterea
opțională a unui singur hop pentru extinderea intervalului radio. Această transmisie multi-hop a
acestor date prin alte contoare (opțional cu baterie) nu este acceptată de această specificație [2].
În ceea ce privește diferitele moduri descrise în standardul [EN 13757-4: 2013], numai
modurile S1, S2, T1, T2, C1 și C2 sunt acceptate de această specificație. Aceste moduri
funcționează în sub-benzi limitate în ciclu de serviciu ale intervalului de frecvențe libere de
licență 868 - 870 MHz. Ciclul de funcționare nu limitează funcțiile necesare pentru sistemul de
contorizare deschis, ci limitează timpul de ocupare a benzii de la alte sisteme care operează în
aceste benzi de frecvență.
Modurile C1 și C2 oferă o codificare mai eficientă a canalului NRZ, care este acceptată de
cipurile RF moderne. Pentru toate modurile de comunicare radio, este recomandată o limitare a
ciclului total de transmisie pe oră la 0,02%. Acest lucru este necesar pentru a limita rata de
coliziune în dens sau situații repetate.
S1, T1 și C1 sunt moduri unidirecționale în care contorul frecvent (secunde până la ore)
transmite datagrame care conțin identificarea contorului împreună cu date contorizate. Această
funcție unidirecțională este suficientă pentru a susține toate funcțiile de comunicare necesare
pentru un contor de bază în cadrul sistemului de contorizare deschis.
S2, T2 și C2 sunt îmbunătățiri bidirecționale compatibile ale respectivelor moduri
unidirecționale. Acestea activează o comunicare opțională a gateway-ului în contor, urmând un
șir de date gateway.
[EN 13757-4: 2013] descrie toate cerințele (aplicabile și pentru condițiile de testare) pentru
modurile acceptate S1, S2, T1, T2, C1 și C2. Pentru modul S2 este acceptată doar varianta cu
preambul lung.
Datorită duratei de viață a bateriei, majoritatea contoarelor și a anumitor actuatoare nu pot
suporta continuu modul de primire. Este posibilă o comunicare inițiată de o poartă („Pull”) cu
contorul sau actuatorul. Dar orice astfel de comunicare (în aval) este de obicei limitată la un
interval de timp direct în urma unei comunicări în amonte (cu excepția dispozitivelor alimentate
cu rețeaua electrică).
Deoarece contorul transmite frecvent, întârzierea de transmisie rezultată (variază de la
secunde la ore) pare acceptabilă. Un actuator trebuie să transmită cel puțin ID-ul său unic și
starea sa și să aștepte după fiecare transmisie pentru o posibilă datagramă de la poartă, așa cum
este descris în standardul [EN 13757-4: 2013] [2].
14
2.1.3.2 Transmisie sincronă versus asincronă

Contoarele OMS utilizează schema de transmisie strict sincronă specificată în standardul [EN
137574: 2013].
Dacă este prezent stratul de legătură extinsă (ELL), numărul de acces și bitul sincron in ELL
se va utiliza sincronizare sincronă. În caz contrar, se vor aplica numărul de acces al stratului de
transport și bitul sincron din câmpul de configurare (Figura 2.3).
Fig. 2.3 Numărul de acces pentru transmisii sincrone și asincrone
Legendă:
S S=1:datagramă sincronă; S=0:datagramă asincronă
ACC Număr de acces
tACC interval de transmisie individuală de la baza de date cu numărul de acces ACC = n
la următoarea transmisie sincronă cu ACC = n + 1
Transmisiile sincrone trebuie să fie de tipul SND-NR, ACC-DMD sau ACC-NR. Dacă
intervalul nominal de transmisie este mai mic decât intervalul de actualizare selectat al datelor de
consum, atunci unul sau mai multe ACC-NR pot fi utilizate pentru transmisia sincronă între
transmisiile sincrone ale SND-NR.
Raportul dintre ACC-NR și SND-NR (respectiv ACC-DMD în caz de alertă) trebuie să fie n
la 1 pentru a permite primirea fiecărui n-lea datagram doar (cu n = 0 ... 15) de către un receptor
cu baterie. Raportul nu poate fi modificat după instalarea contorului / actuatorului.
Începutul primei transmisii sincrone va fi aleatoare. Nu este permisă repararea transmisiei
sincrone exact la un eveniment comun, cum ar fi un timp special sau o pornire după o întrerupere
a tensiunii. Acest lucru este necesar pentru a evita utilizarea simultană a canalului radio de către
mai multe controlere.
Transmisiile asincrone sunt destinate oricărei transmisii în afara celei sincrone. Tipurile de
mesaje ale controlerului RSP-UD, ACK, NACK, SND-IR trebuie transmise asincron. Cu toate
acestea, tipurile de mesaje SND-NR, ACC-DMD sau ACC-NR pot fi, de asemenea, transmise
asincron [2].
15
Tabel 2.1 Intervalul de actualizare al datelor de consum pentru diferite medii

Medii măsurate Obligatoriu (facturare și actuator) Aspecte informative (de
consum)
Intervalul de actualizare Interval de Interval de vizualizare
mediu maxim [min] vizualizare pentru pentru
furnizorul de consumator [min]
energie [ore]
Electricitate 7,5 1 15
Gaz 30,0 1 60
Căldură 30,0 1 60
Apa/Apă caldă 240,0 24 -
Costuri încălzire 240,0 24 -
Încălzire/Răcire 240,0 24 -
(sub-contorizare)
Tabelul 2.1 prezintă intervale de vizualizare a datelor pentru aspecte informative și de facturare.
Intervalele de vizualizare pentru consumatori (furnizarea de date actuale) sunt de 15 sau 60 de
minute (în funcție de suport) cu o probabilitate de recepție mai mare de 95% [2].
2.2. Nivelul de date
Acest nivel are responsabilitatea de a asigura o conexiune sigură între doua

dispozitive. Din acest motiv, protocolul acestui nivel determină metodele de protecţie a
transmisie, a structurii telegramei, a metodelor de accesare, a mediului de transmitere şi de
sincronizare şi adresare a dispozitivelor.
Acest protocol foloseşte transmiterea asincronă în serie a biţilor. Sincronizarea este
implementată cu biţi de start şi stop pentru fiecare caracter. În Figura 2.4 este reprezentată
transmiterea unui bit în direcția de apel și de răspuns.
Fig. 2.4 Transmiterea caracacterelor între dispozitivele master - slave
16
Sunt transmişi cei 8 biţi de date şi bitul de paritate, asigurând că cel puţin fiecare al
11-lea bit este un Mark. Biţii de date sunt transmişi în ordine crescatoare, de exemplu bitul cu
cea mai nesemnificativă valoare (LSB=least significant bit) este primul regăsit pe linie.
Parametrii de transmisie
Acest protocol utilizează transmisie asincronă de biți seriali, în care sincronizarea este
implementată cu biți de pornire și oprire pentru fiecare caracter. Nu trebuie să existe pauze în
cadrul unei telegrame, nici măcar după un bit de oprire.
Întrucât quiescence pe linie corespunde unui 1 (Mark), bitul de început trebuie să fie
un Space, iar bitul de oprire un Mark.
Între cei opt biți de date și bitul de paritate sunt transmise, asigurând că cel puțin
fiecare al unsprezecelea bit este un Mark. Biții de date sunt transmiși în ordine crescătoare,
adică bitul cu cea mai mică valoare (LSB = bit cel mai puțin semnificativ) este primul care se
găsește pe linie. Transmisia are loc în jumătate duplex și cu o rată de transfer de cel puțin 300
Baud. În figura următoare, este reprezentată transmiterea unui byte în direcția de apel și de
răspuns [3].
2.3. Formatul telegramelor
Conform IEC 870-5, sunt preconizate trei clase diferite de integritate a datelor (I1, I2
și I3) pentru transmiterea datelor de control de la distanță. Clasa de integritate a datelor este o
măsură a coeficientului dintre rata mesajelor false nedetectate și probabilitatea de biți defecte
în timpul transmisiei. Pentru clasele de integritate a datelor menționate mai sus, au fost
identificate diferite clase de format, în care sunt definite măsuri de recunoaștere a
defecțiunilor de transmisie.
Pentru protocolul M-Bus al stratului de legături de date se folosește clasa de format
FT 1.2, care este conținută în clasa I2 de integritate a datelor, care specifică o distanță
Hamming 4. Distanța Hamming dintre două șiruri de lungime egală este numărul de poziții
ale căror simboluri corespunzătoare sunt diferite.
Clasa de format FT 1.2 specifică trei modele diferite de telegramă, care pot fi
recunoscute cu ajutorul unor caractere speciale de pornire. Mai jos, sunt explicate formatele
de telegramă utilizate pentru M-Bus (Figura 2.5).
17
Fig. 2.5 – Formatul telegramelor în protocolul M-Bus
Telegramele prezentate mai sus, se clasifică în următoarele categorii, după cum urmează:
Single Character (Caracter unic)

Acest format este compus dintr-un singur caracter, și anume E5h (zecimal 229) și
servește la confirmarea primirii transmisiilor.
Short Frame (Structură scurtă)

Acest format cu o lungime fixă începe cu caracterul de pornire 10h, iar pe lângă
secțiunile C și A se include check sum (aceasta este formată din cele două ultime caractere
menționate) și caracterul de oprire 16h.
Control Frame (Structură de control)

Această structură este la fel ca structura lungă, dar fără datele utilizatorului, cu un L
field cu conţinutul de 3. Check sum este calculată în acest moment din secțiunile C, A și CI.
Long Frame (Strucură lungă)

După caracterul de pornire 68h, secțiunea de lungime (L field) este mai întâi transmis
de două ori, urmat din nou de caracterul de început. După aceasta, urmează secțiunea de
funcție (C field), secțiunea de adresă (A field) și secțiunea de control (CI field). L field oferă
cantitatea de intrări de date ale utilizatorului plus 3 (pentru C, A, CI). După introducerea
datelor utilizatorului, se transmite check sum, care este construită pe aceeași zonă cu secțiunea
de lungime, iar în final se transmite caracterul de oprire 16h [3].
18
2.3.1 Specificul secțiunilor
În această secțiune, vor fi explicate secțiunile utilizate pentru formarea telegramelor.

Toate acestea au o lungime de 1 Byte, corespunzând la 8 biți.
Secțiunea C (secțiune de control, secțiune funcțională)

Pe lângă etichetarea funcțiilor și a acțiunilor cauzate de acestea, secțiunea C specifică direcția
fluxului de date și este responsabil pentru diverse sarcini suplimentare atât în direcțiile de
apel, cât și de răspuns. Tabelul 2.2 prezintă codarea biților individuali ai secținii C.
Tabelul 2.2 Codarea secțunii de control

Număr de biți 7 6 5 4 3 2 1 0
Direcția de apelare 0 1 FCB FCV F3 F2 F1 F0
Direcția de răspuns 0 0 ACD DFC F3 F2 F1 F0
Cel mai mare bit (cel mai semnificativ) este rezervat funcțiilor viitoare, iar în prezent
este alocată valoarea 0; numărul de biți 6 este utilizat pentru a specifica direcția fluxului de
date.
Bitul FCB (frame count bit) indică proceduri de transmisie de succes (adică cele la
care s-a răspuns sau a fost recunoscut), pentru a evita pierderea sau înmulțirea transmisiei.
Dacă răspunsul aștepat lipsește sau recepția este defectuoasă, dispozitivul master trimite din
nou aceeași telegramă cu un FCB identic, iar dispozitivul slave răspunde cu aceeași telegramă
ca mai devreme. Dispozitivul master indică cu un 1 în bitul FCV (frame count bit valid), că
FCB este utilizat.
Când FCV conține un „0”, dispozitivul slave ar trebui să ignore FCB. În direcția de
răspuns, ambii biți pot efectua alte sarcini. DFC (controlul fluxului de date) servește la
controlul fluxului de date, prin faptul că slave-ul cu un DFC = 1 indică faptul că nu poate
accepta alte date.
Cu un bit ACD (cerere de acces) cu o valoare de 1, slave-ul arată că vrea să transmită
date de clasa 1. Dispozitivul master ar trebui apoi să-i trimită o comandă pentru a solicita date
din clasa 1. Aceste date din clasa 1 au prioritate mai mare, care (spre deosebire de datele din
clasa 2) ar trebui transmise cât mai curând posibil.
Asistența datelor din clasa 1 și a biților DFC și ADC nu este cerută de standard.
Biții 0 până la 3 ai câmpului de control codează adevărata funcție sau acțiune a mesajului.
Tabelul 2.3 prezintă codurile de funcții utilizate în apelurile și indicațiile de răspuns.

Funcțiile prezentate în acest tabel vor fi explicate mai detaliat în secțiunea următoare. Toate
codurile de funcții suplimentare definite în IEC 870-5-2 pot fi de asemenea utilizate [3].
19
Tabelul 2.3 Coduri de control ale protocolului M-Bus (F: FCB-Bit, A: ACD-Bit, D: DFC-Bit)
Nume Binarul din C Hex. Din C Telegramă Descriere

Field Field
SND_NKE 0100 0000 40 Structură scurtă Inițializarea dispozitivului
slave
SND_UD 01F1 0011 53/73 Structură lungă / Trimite datele utilizatorului
de control către slave
REQ_UD2 01F1 1011 5B/7B Structură scurtă Cerere pentru date de clasa 2
REQ_UD1 01F1 1010 5A/7A Structură scurtă Cerere pentru date de clasa 1
REQ_UD 00AD 1000 08/18/28/38 Structură lungă / Cerere de transfer de date de
de control la slave către master
A field (secțiune de adresare)

Secțiunea de adresare servește pentru adresarea destinatarului în direcția de apel și
pentru identificarea expeditorului de informații în direcția de primire. Mărimea acestei
secțiuni este de un byte (8 biți) și, prin urmare, poate lua valori de la 0 la 255.
Adresele 1 până la 250 pot fi alocate dispozitivelor slave individuale, până la
maximum 250. Dispozitivelor slave neconfigurate li se oferă adresa 0 la fabricare și de regulă,
sunt alocate una dintre aceste adrese atunci când sunt conectate la M-Bus.
Adresele 254 (FEh) și 255 (FFh) sunt utilizate pentru a transmite informații tuturor
participanților (Broadcast). Cu adresa 255, niciunul dintre dispozitivele slave nu răspunde, iar
cu adresa 254 toate dispozitivele slave răspund cu propriile lor adrese. Cel din urmă caz are ca
rezultat, în mod natural, coliziuni atunci când două sau mai multe dispozitive slave sunt
conectate și trebuie folosite doar în scopuri de testare.
Adresa 253 (FDh) indică faptul că adresarea a fost efectuată în stratul de rețea în loc
de stratul de legătură de date. Adresele rămase 251 și 252 au fost păstrate pentru viitoarele
aplicații.
CI field (secțiune informațională de control)

Secțiunea informațională de control este deja o parte a stratului de aplicații și a fost
inclusă în formatul de telegramă utilizat, pentru a face diferența între formatele structurilor
lungi și cele de control. Informațiile de control permit implementarea unei varietăți de acțiuni
în dispozitivul master sau în dispozitivul slave.
Check Sum (suma de verificare)

Check sum servește la recunoașterea defecțiunilor de transmisie și sincronizare și este
configurată din anumite părți ale telegramei. Check sum este calculată din suma aritmetică a
datelor menționate mai sus, fără a ține cont de cifrele de transport [3].
20
2.3.2 Procesul de comunicare
Stratul legăturii de date utilizează două tipuri de servicii de transmisie:

- Send/Confirm: SND/CON
- Request/Respond: REQ/RSP
După recepția de pe o telegramă valabilă, dispozitivul slave trebuie să aștepte între 11 biți și
(330 biți + 50ms) înainte de a răspunde.
Proceduri Send/Confirm
- SND_NKE → Caracter de control unic

Această procedură servește pentru a începe după întreruperea sau începerea
comunicării. Valoarea bitului de număr de cadre FCB este ajustată în master și slave, adică
prima telegramă principală cu FCV = 1 după SND_NKE conține FCB = 1. Dispozitivul slave
răspunde unui SND_NKE primit corect cu o confirmare constând dintr-un singur caracter
(E5h).
-SND_UD → Caracter de control unic

Cu această procedură, dispozitivul master transferă datele utilizatorului la dispozitivul
slave. Dispozitivul slave poate confirma primirea corectă a datelor cu un singur caracter de
confirmare („$ E5”), sau omițând un semnal de confirmare că nu a primit corect telegrama.
-REQ_UD2 → RSP_UD
Dispozitivul master solicită date de la dispozitivul slave în conformitate cu clasa 2.
Dispozitivul slave poate transfera datele sale cu RSP_UD, sau nu poate da niciun răspuns care
să indice că telegrama REQ_UD2 nu a fost primită corect sau că adresa conținută în telegrama
REQ_UD2 nu se potrivește [3].
Comunicare minima
Conform standardului european EN1434-3, ca minim pentru comunicare este nevoie de
procedurile REQ_UD2 / RSP_UD și SND_NKE / $ E5. Toate celelalte funcții sunt opționale.
Proceduri de transmisie în cazul erorilor

O eroare într-o telegramă primită poate fi detectată de către receptor (master sau slave),
verificând următoarele puncte:
- Biți Start/Paritate/Oprire character
- Pornire/Verifică suma/Oprirea caracaterelor în formatul telegramelor
- Al doilea caracter Start, paritatea celor două lungimi de câmp și numărul de caractere
suplimentare primite (= L Field + 6) cu o structură lungă sau de control.
Când a fost detectată o defecțiune ca urmare a verificărilor de mai sus, transmisia nu
va fi acceptată, iar răspunsul sau confirmarea nu va fi trimisă.
După o limită de timp (330 biți + 50 ms), dispozitivul master interpretează lipsa de răspuns ca
o defecțiune și repetă aceeași telegramă de până la două ori. Dacă o telegramă valabilă nu a
21
fost primită la acel moment, se introduce un așa-numit „timp inactiv” de cel puțin 33 de biți.
Când dispozitivele slave trimit răspunsuri defecte sau corupte, se fac până la trei încercări, iar
dacă există o defecțiune în ultima încercare, atunci se introduc perioadele de 33 de biți „timp
inactiv”. Dispozitivul master poate încerca un SND_NKE. Dacă acest lucru nu reușește, va
continua cu următoarea adresă de slave [3].
2.3.3 Biții FCB, FCV și adresarea
Bitul FCB (Frame Count-Bit) în REQ_UD2 poate fi considerat ca bit LSB (Least
Segnificant Byte) al telegramelor transmise spre dispozitivul master de către dispozitivul
slave. Pe de altă parte, FCB în SND_UD poate fi considerat ca LSB al unui contor de
telegramă (separat) pentru telegramele transmise în master spre direcția slave. Un bit FCV
(Frame Count Valid) semnalează dacă acest mecanism de numărare a cadrelor este activ [3].
2.3.3.1 Aplicații ale mecanismului FCB (Frame Count-Bit) - Răspunsuri multi-telegramă

(RSP_UD) de la slave la master
Dacă o secvență totală de răspuns dintr-un dispozitiv slave nu se va încadra într-o

singură telegramă RSP_UD (răspunde la datele utilizatorului) de la dispozitivul slave la
dispozitivul master, dispozitivul master semnalează printr-un FCB-Bit comutat împreună cu
un set FCV-Bit în următoarea REQ_UD (solicitare) date utilizator) telegramă că stratul său de
legătură a primit în mod corespunzător ultimul RSP_UD - telegramă de la dispozitivul slave.
Răspunsul dispozitivului slave la o solicitare REQ_UD cu FCB-bit comutat cu un bit FCV set
de la dispozitivul master cu un RSP_UD care conține următoarea secțiune de telegramă a
stratului de legătură a unui răspuns multi-telegramă, altfel va repeta ultima telegramă.
Un dispozitiv slave cu o singură telegramă RSP_UD poate ignora FCB-ul din
telegrama REQ_UD2 și poate trimite întotdeauna aceeași (singură) telegramă. Un dispozitiv
slave cu exact două telegrame cu răspuns RSP_UD (secvențial) poate folosi FCB din
REQ_UD2 pentru a decide care dintre cele două telegrame trebuie transmise. Astfel, un
dispozitiv slave cu unul sau două telegramele de răspuns RSP_UD (secvențiale) nu necesită
un bit intern „Last-REQ_UD2FCB”.
Un dispozitiv slave cu trei sau mai multe telegrame cu răspuns RSP_UD (secvențial)
necesită un astfel de bit de memorie internă. Un astfel de bit de memorie internă pentru
direcția RSP_UD trebuie să fie independent de un posibil bit suplimentar de memorie internă
pentru direcția SND_UD [3].
2.3.3.2 Telegrame cu răspuns “blocat” (frozen answer) de la slave la master
În aceleași cazuri, un slave va “bloca” datele ultimei sale telegrame de răspuns

RSP_UD într-un stoc temporar suplimentar și va repeta acest răspuns RSP_UD “blocat”
anterior, dacă FCB nu a fost “blocat”. După recepția unui FCB-Bit comutat cu un set FCV-Bit
sau după recepția unui REQ_UD2 cu FCV-Bit șters, dispozitivul slave va genera o nouă
22
telegramă cu răspuns care reflectă starea actuală a tuturor datelor sale în loc să repete datele
valorii “blocate” la prima încercare REQ_UD2 cu FCB comutat. În aplicațiile de contor,
această abordare de tip “frozen telegram” va avea ca rezultat date de contor, foarte vechi, dacă
ultimul REQ_UD2 cu bit FCB comutat a avut loc cu mult timp în urmă. Astfel, pentru citirea
contorului, această tehnică de telegramă “blocată” nu este recomandată [3].
2.3.3.3 Date cu mai multe telegrame (SND_UD) de la master la slave
Dacă dispozitivul master trimite un bloc de date mare (secvențial) către un dispozitiv
slave (de exemplu, inițializarea RAM / EEPROM, încărcarea codului) care trebuie împărțit în
mai multe telegrame, se poate întâmpla o situație similară ca în slave în direcția principală.
Dacă dispozitivul slave primește corect o telegramă și răspunde cu o confirmare
pozitivă (de obicei printr-un răspuns cu un byte de $E5), dar dispozitivul master nu primește
corect acest răspuns pozitiv, acesta repeta ultima telegramă cu FCB-bit identic ca în prima
încercare. Din această cauză, dispozitivul slave poate recunoaște că următoarea telegramă nu
conține următorul bloc de date, dar repetă ultimul bloc de date care a fost primit corect. Deci,
dispozitivul slave poate sau ignoră complet această repetare a telegramelor sau poate să o
accepte astfel, rescriind ultimele date ale telegramelor cu două date identice. În ambele cazuri,
un contor de secvență de telegramă intern nu este incrementat.
Un dispozitiv slave care poate accepta trei sau mai multe telegrame SND_UD
(secvențiale) necesită un astfel de bit intern de memorie. Un astfel de bit de memorie internă
pentru direcția SND_UD trebuie să fie independent de un posibil bit suplimentar de memorie
internă pentru direcția RSP_UD.
Un dispozitiv slave care va accepta numai un singur dispozitiv master de telegramă
pentru comunicarea dispozitivelor slave poate ignora pur și simplu FCB în SND_UD. Un
dispozitiv master care poate accepta exact două (secvențiale) SND_UD pot utiliza pur și
simplu FCB al SND_UD pentru a decide care dintre cele două telegrame a fost trimis. Astfel,
un dispozitiv slave care poate accepta unul sau două telegrame cu răspuns SND_UD
(secvențiale) nu necesită un bit intern „Last-SND_UD-FCB” [3].
2.3.3.4 Acțiuni incrementale în dispozitivul slave ințiate de dispozitivul master
Dacă o singură telegramă SND_UD va iniția o acțiune incrementală într-un dispozitiv

slave (cum ar fi comutarea unei releu sau numărarea a ceva), în contrast cu trimiterea unor
date sau parametri „absoluți”, mecanismul FCB permite ca în situația multi-telegramă
SND_UD să distingă între o repetiție din ultima telegramă din cauza recepției ratate și a
următoarei acțiuni. În acest caz, acțiunea este luată numai dacă FCB-ul actualei telegrame
SND_UD e diferit de FCB în telegrama anterioară SND_UD [3].
23
2.3.4 Aspecte de implementare a adresării primare
Dispozitivul Master
Dispozitivul master trebuie să conțină întotdeauna un „bit de imagine REQ_UD2-

FCB” și, de asemenea, un „bit de imagine SND_UD-FCB” pentru fiecare adresă principală de
slave folosită de stratul său de aplicație. După trimiterea unei cereri SND_NKE către o adresă
slave, trebuie să fie setate atât „Următorul bit de imagine FCB” asociat cu această adresă
conținută în cerere. Astfel, pentru fiecare adresă primară, prima telegramă REQ_UD2 sau
SND_UD după un SND_NKE conține un set FCB-Bit.
După o pierdere de memorie (de obicei din cauza unei întreruperi de curent) a acestor
„imagini de biți FCB următoare”, dispozitivul master trebuie să trimită un SND_NKE la toate
adresele afectate. Toate telegramele RSP_UD2 ulterioare trebuie să conțină "Următorul bit de
imagine REQ_UD2- FCB" a adresei primare corespunzătoare ca FCB. Acest "bit de imagine
REQ_UD2 FCB următor" este comutat după ce a fost primit un telegramă RSP_UD a stratului
de legături fără erori. Toate telegramele SND_UD ulterioare trebuie să conțină "imaginea
SND_UD- FCB" - imagine a adresei primare corespunzătoare ca FCB. Dacă un SND_UD a
fost transmis cu succes unui slave (recepția unui byte de confirmare valabil $ E5 sau a unei
telegrame RSP_ACK valabile) acest „bit de imagine SND_UD-FCB” următor asociat cu
această adresă este comutat [2].
Dispozitivul Slave
Dacă un dispozitiv slave dorește să utilizeze mecanismul FCB-Bit pentru transferurile

de tip REQ_UD2 (slave către master), transferă pentru mai mult de două telegrame
secvențiale, trebuie să ofere un „Ultim REQ_UD2-FCB”. Dacă se primește o telegramă
REQ_UD2 validă cu un set FCV-Bit, FCB-Bit-ul său este comparat cu „Ultimul REQ_UD2-
FCB-Bit”.
Dacă diferă sau bit-ul FCV este clar, următoarele date reale de telegramă sunt utilizate
pentru răspunsul RSP_UD, altfel se repetă ultima telegramă (stocată). Dacă un dispozitiv
slave dorește să utilizeze mecanismul FCB-Bit pentru transferurile de tip SND_UD (master
către slave) pentru mai mult de două telegrame secvențiale, trebuie să furnizeze un bit de
memorie „Ultimul SND_UD-FCB”.
Dacă se primește o telegramă SND_UD validă cu un bit FCV setat, Bit-ul său FCB
este comparat cu acest „Ultimul bit de memorie SND_UD-FCB”. Dacă acestea diferă sau
bitul FCV este clar, următoarele date reale de telegramă sunt utilizate pentru răspunsul
RSP_UD, altfel se repetă ultima telegramă (stocată). După o recepție valabilă a unui
SND_NKE la adresa principală a dispozitivului sau la adresa de testare 254 ($ FE) sau la
adresa de difuzare 255 (255 $), acești biți de memorie „Ultimul FCB” intern trebuie șterși [2].
24
Implementarea pentru dispozitiv slave cu mai multe adrese

Un dispozitiv slave ar putea fi configurat pentru a răspunde la mai multe adrese
primare. Acest lucru ar putea fi util pentru dispozitivele slave care constau în mai multe
blocuri funcționale independente. Dacă acest dispozitiv slave dorește să utilizeze
funcționalități FCB, trebuie să implementeze numărul adecvat de biți de memorie internă (0, 1
sau 2) pentru fiecare dintre aceste adrese [2].
Implementarea adresei principale 255 de difuzare

Toate transferurile la adresa de difuzare primară 255 ($ FF) nu răspund și, prin
urmare, ar trebui să fie implementate de către dispozitivul master cu FCV-Bit șters. Un
SND_NKE la adresa principală 255 va șterge biții interni „Ultimul FCB primit” al tuturor
dispozitivelor de tip slave cu adrese primare 0-250 și cu implementare simultană FCB-Bit [2].
Implementare pentru adresa principală 254 ($ FE)
Un dispozitiv slave ar trebui să răspundă la toate solicitările adresei principale 254 ($

FE = adresa de testare) indiferent de propria adresă principală. Răspunsul trebuie să conțină
propria sa adresă principală și nu adresa 254 ($ FE). Această adresă de testare este utilizată de
echipamentele de citire sau de testare în modul “point-to-point”. Deși aceasta este o a doua
adresă principală pentru fiecare dispozitiv slave separat "Ultimul FCB primit" - biții nu sunt
necesari pentru acest caz special, deoarece orice echipament de testare sau dispozitiv master
trebuie să emită un SND_NKE după fiecare reconectare eliminând „Ultimul FCB primit” și
astfel pregătirea pentru transfer nou indiferent de istoricul comunicării anterioare [2].
Implementare pentru adresarea secundară

FCB-Dispozitiv slave de implementare
Un dispozitiv slave cu adrese secundare implementate și cu administrarea FCB implementată
trebuie să aibă un set suplimentar de 0, 1 sau 2 biți ("Last Received FCB") pentru toate
comunicațiile prin adresa principală 253 ($ FD). Dacă se poate comunica, de asemenea,
alternativ prin intermediul unei alte adrese primare (exceptând adresele speciale 254 și 255),
este necesar un set suplimentar de 0, 1 , 2 "Ultimul FCB primit" -biți de memorie pentru
fiecare dintre aceste adrese primare. O telegramă de selecție validă nu numai că va seta bitul
de selecție intern, dar va șterge și toți biții 0, 1 , 2, biți " Last Received FCB ", asociați cu
adresarea secundară prin adresa primară 253 ($ FD). Dispozitivul master va începe
comunicarea (REQ_UD2 sau SND_UD) după orice telegramă de selecție (CI = 52 $ sau 56 $)
cu setul FCV-Bit setat și setul FCB-Bit setat. Dacă un dispozitiv slave are mai multe
identificări secundare alternative, este necesar doar un singur set de 0, 1 sau 2 biți FCB primiți
pentru toate adresele secundare [2].
FCB - Dispozitiv master implementare

Dispozitivul master trebuie să implementeze o pereche separată de „Next FCB image” -Biți
pentru adresa primară 253 ($ FD) ca pentru fiecare altă adresă primară. Cu toate că aceste "
Next FCB image " pot fi utilizate pentru mai multe dispozitive slave, nu există nicio confuzie,
deoarece pentru accesarea unui alt dispozitiv slave este necesară o telegramă de selecție care
va defini viitoarea secvență FCB atât pentru dispozitivul slave cât și pentru dispozitivul
master [2].
25
2.4. Nivelul de aplicație
Protocolul de aplicare standardizat în standardul EN1434-3 pentru schimbul de date cu

contoare de căldură va fi baza discuției următoare. Acest standard este potrivit și pentru alte
contoare de utilitate pentru consumatori, de exemplu pentru gaz și apă. Cu toate acestea,
EN1434-3 acoperă doar structura de date în direcția de răspuns, structura de date utilizată în
general în direcția master-slave [3].
2.4.1 Câmpul CI
Câmpul CI codează tipul și secvența datelor de aplicație care trebuie transmise în
această structură (Tabel 2.4). Standardul EN1434-3 definește două secvențe de date posibile
în înregistrări multibit. Bitul doi (numărarea începe cu bitul 0, valoarea 4), care se numește bit
M sau bit Mode, în câmpul CI oferă o informație despre secvența de octeți utilizată în
structurile de date multibit. Dacă bitul Mode nu este setat (Mode 1), primul LSB (bit cel mai
puțin semnificativ) al unei înregistrări multibit este transmis mai întâi, altfel (Mode 2) este
MSB (cel mai semnificativ bit) [3].
Tabel 2.4 Coduri CI de câmp utilizate de dispozitivul master
Modul 1 Modul 2 Aplicație Definită în

51h 55h Transmisie date EN1434-3
52h 56h Selecție dispozitive slave Grup de utilizatori Iulie ´93
50h Resetarea aplicației Grup de utilizatori Iulie ´93
54h Acțiune de sincronizare Sugestie
B8h Setează rata de transfer la 300 baud Grup de utilizatori Iulie ´93
B9h Setează rata de transfer la 600 baud Grup de utilizatori Iulie ´93
BAh Setează rata de transfer la 900 baud Grup de utilizatori Iulie ´93
BBh Setează rata de transfer la 1200 baud Grup de utilizatori Iulie ´93
BCh Setează rata de transfer la 2400 baud Grup de utilizatori Iulie ´93
BDh Setează rata de transfer la 9600 baud Grup de utilizatori Iulie ´93
BEh Setează rata de transfer la 19200 baud Sugestie
BFh Setează rata de transfer la 38400 baud Sugestie
B1h Solicită citirea conținutului RAM complet Sugestie Techem
B2h Transmite datele utilizatorilor Sugestie Techem
B3h Inițializează modul de testare de calibrare Grup de utilizatori Iulie ´93
B4h Citește EEPROM Sugestie Techem
B6h Începe testul software Sugestie Techem
90h-97h Coduri utilizate pentru hashing Învechit, nerecomandat
Resetarea aplicației (CI=$50)

Cu codul CI $50, masterul poate elibera o resetare a stratului de aplicație în slave.
Fiecare slave însuși decide ce parametri trebuie schimbați - de exemplu, ce ieșire de date este
implicită după ce a primit o astfel de resetare a aplicației.Această aplicație resetată de un
SND_UD cu CI = $50 este echivalentul resetării stratului de legătură de date de către un
SND_NKE [3].
26
Subcodarea de resetare a aplicației
Este permisă utilizarea parametrilor opționali după CI = $50. Primul parametru (codul
de resetare a aplicației) definește ce funcție de telegramă și ce subtelegramă este solicitată de
master. Tipul de date al acestui parametru este binar pe 8 biți. Cei 4 biți superiori definesc
tipul de telegramă sau aplicația de telegramă iar cei 4 biți inferiori definesc numărul
subtelegramei. Utilizarea valorii zero pentru numărul subtelegramei înseamnă că toate
telegramele sunt solicitate [2].
Dispozitivele slave cu un singur tip de telegramă pot ignora resetarea aplicației și parametrii
adăugați, dar trebuie să o confirme ($E5).
Următoarele coduri pot fi utilizate pentru cei 4 biți superiori ai primului parametru (Tabel
2.5):
Tabel 2.5 Codarea celor patru biți superiori ai primului parametru după CI =$50
Codificare Descriere Exemple

0000b Toate Consum informații reale și
0001b Date utilizator fixe + date valori istorice
0010b Factură simplă
0011b Factură îmbunătățită
0100b Factură în mai multe tarife
0101b Valori instantanee Pentru reglare
0110b Valorile de gestionare a
sarcinii pentru management
0111b Rezervat
1000b Instalare și pornire Adresa de BUS, date fixate și
1001b Testare valori de înaltă rezoluție
1010b Calibrare
1011b Setări fabrică
1100b Dezvoltare
1101b Autotestare
1110b Rezervat
1111b Rezervat
Exemplu:
Master-ul eliberează o resetare a aplicației îmbunătățită către toate dispozitivele slave.
Toate telegramele de tipul datelor de utilizator sunt solicitate.
Master to Slave: 68 04 04 68 | 53 FE 50 | 10 | B1 16
Slave to Master: E5
27
Sincronizarea acțiunii (CI= $54)

Acest cod CI poate fi utilizat pentru sincronizarea funțiilor în slave și master (ex:sincronizarea
orei).
Următoarele coduri pot fi folosite pe direcția slave-master (Tabelul 2.6)
Tabel 2.6 Codurile câmpului CI utlizate de dispozitivul slave

CI M=0 CI M=1 Cerere Definită în
70h Raportul erorilor generale ale Grup de utilizatori Martie ´94
aplicației
71h Raportul stării de alarmă Grup de utilizatori Martie ´94
72h 76h Răspuns date variabile EN1434-3
73h 77h Răspuns date fixe EN1434-3
2.4.2 Structura datelor fixe
În direcția de răspuns cu un șir lung sunt utilizate două structuri diferite de date.
Structura de date fixă (Tabel 2.7), pe lângă o lungime fixă, este limitată la transmiterea a
numai două stări contrare de lungime predeterminată, care au codare binară sau BCD. În
schimb, structura variabilă a datelor permite transmiterea mai multor stări de contorizare în
diverse coduri și informații suplimentare utile despre date. Numărul de octeți ai stărilor
contorului transmis este, de asemenea, variabil cu această structură de date. Spre deosebire de
structura fixă, structura variabilă poate fi utilizată și în direcția de apelare. Din acest motiv,
structura de date fixă nu este recomandată pentru evoluțiile viitoare. Pentru identificarea
structurii de date fixe, se utilizează numerele 73h / 77h pentru câmpul informațional de
control. În acest fel, software-ul principal poate vedea cum trebuie să interpreteze datele [3].
Tabel 2.7 Structura de date fixă în direcția de răspuns

(transmiterea secvenței de la stânga la dreapta)
Număr de identificare Număr de acces Stare Mediu/unitate Contor 1 Contor 2
4 Biți 1 Bit 1 Bit 2 Biți 4 Biți 4 Biți
Numărul de identificare este un număr de serie alocat în timpul fabricației, codat cu 8

cifre BCD (4 Biți), și care rulează astfel între 00000000 și 99999999. Numărul de acces are
coduri binare nesemnate și este crescut cu unu după fiecare RSP_UD din slave. Cu ajutorul
câmpului de stare (Tabel 2.8) diverse informații despre starea contoarelor și defecțiunile care
au apărut pot fi comunicate:
Tabel 2.8 Codarea câmpului de stare

Bit Sensul cu Bit setat Sensul fără Bit setat
0 Contorul 1 și 2 codificat binar Contorul 1 și 2 codificate BCD
1 Contorul 1 și 2 stocate la o dată fixă Contorul 1 și 2 sunt valori reale
2 Putere redusă Fără putere redusă
3 Eroare permanentă Fără eroare peramanentă
4 Eroare temporară Fără eroare temporară
28
5 Specific producătorului Specific producătorului

Câmpul mediu/unitate este mereu transmis cu bit-ul cel mai puțin semnificativ mai
întâi și dă mediul măsurat atât pentru stările contoare, cât și pentru unitățile pentru fiecare
dintre cele două stări contrare. Unitățile contorului 1 sunt codificate cu primii 6 biți ai
primului byte, iar unitățile contorului 2 cu primii 6 biți ai celui de-al doilea byte. Conform
informațiilor prezentate în Tabelul 2.9, codificarea mediului este alcătuită din cei doi cei mai
mari biți ai acestui byte și, prin urmare, poate avea 16 valori diferite (4 biți) [3].
Tabel 2.9 Codarea unității fizice și a mediului în structura de date fixe (tip de date E)
Biți Bitul nr. 8 (bit 2 de mediu/unitate) Bitul nr. 7 (bit 1 de mediu/unitate)
Bit 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Mediu Unitate fizică contor 1 Mediu Unitate fizică contor 2
MSB MSB LSB LSB MSB
LSB
Pentru a permite transmiterea unei valori memorate cu unul dintre cele două contoare,
a fost definită unitatea specială (111110b sau cota codului hex de 3Eh). Această unitate
declară că acest contor are aceeași unitate ca și celălalt contor real.
Exemplu pentru RSP_UD cu structură de date fixă (modul 1):

Slave-ul cu adresa 5 și numărul de identificare 12345678 răspunde cu următoarele date:
68 13 13 68 antetul telegramei RSP_UD (câmpul L = 13h = 19d)
08 05 73 Câmp = 08h (RSP_UD), adresa 5, câmp CI = 73h (fixat, primul LSB)
78 56 34 12 număr de identificare = 12345678
0A contor de transmisie = 0Ah = 10d
00 starea 00h: contoare codate BCD, valori reale, fără erori
E9 7E Tip și unitate: apă medie, unitate1 = 1l, unitate2 = 1l (aceeași, dar memorată)
01 00 00 00 contor 1 = 1l (valoarea reală)
35 01 00 00 contor 2 = 135 l (valoare memorată)
3C 16 checkum și semn de oprire
Antetul datelor fixe
Primii doisprezece biți ai datelor utilizatorului constau dintr-un bloc cu o lungime și o

structură fixă, după cum urmează:
Nr. Identificare Fabricant Versiune Mediu Număr acces Stare Semnătură
4 Biți 2 Biți 1 Bit 1 Bit 1 Bit 1 Bit 2 Biți
Astfel, spre deosebire de structura de date fixă aici numărul de identificare este un
număr de client, codat cu 8 cifre BCD (4 Biți) și care rulează astfel de la 00000000 la
99999999. Poate fi presetat la momentul fabricării cu un număr unic, dar poate fi modificat
29
ulterior, mai ales dacă este prevăzut un număr de fabricație unic și care nu poate fi modificat
(DIF = 0C $, VIF =$78). Numărul de acces este descris mai sus în structura de date fixă.
Câmpul producătorului este codat binar nesemnat cu 2 biți. Acest ID al producătorului este
calculat din codul ASCII din EN 61107 ID-ul producătorului (trei litere mari) cu următoarea
formulă:
IEC 870 Man. ID = [ASCII (prima literă) - 64] • 32 • 32
+ [ASCII (a doua literă) - 64] • 32
+ [ASCII (a treia literă) - 64]
Câmpul versiunii specifică generația sau versiunea acestui contor și depinde de
producător. Spre deosebire de structura de date fixă, Mediul este codat cu un byte întreg în loc
de patru biți și cei mai mici doi biți ai stării câmpului sunt folosiți pentru a indica erorile de
aplicare. În afară de aceasta, semnificația biților individuali ai câmpului Status este aceeași cu
cea a structurii de date fixe. Semnătură rămâne rezervată pentru viitoarele aplicații de criptare,
iar până atunci este alocată valoarea 00 00 h [3].
2.4.3 Structura datelor variabile
Codurile câmpului CI 72h/76h sunt utilizate pentru a indica structura variabilă a

datelor în șiruri lungi (RSP_UD) după cum urmează:
Antet de date fix Blocuri de date variabile (înregistrări) MDH Date specifice Mfg.
12 Biți Număr variabil 1 Bit Număr variabil
Astfel, datele împreună cu informațiile privind codificarea, lungimea și tipul de date

sunt transmise în înregistrările de date. Cantitatea de blocuri de date transferate depinde de
spațiul disponibil în șirul de biți, care nu poate depăși lungimea de 255 biți, ținând cont de
câmpurile C, A, CI și blocul de date fixe.
Limita superioară a caracterelor din blocurile de date variabile este astfel de 240 de
biți. Grupul de utilizatori recomandă o lungime maximă totală de telegramă de 255 biți (234
biți pentru blocuri de date variabile) pentru a evita problemele de comunicare prin modem.
Antetul de date al producătorului (MDH) este format din caracterul 0Fh sau 1Fh și indică
începutul părții specifice a producătorului din datele utilizatorului și ar trebui omis, dacă nu
există datele specifice producătorului [3].
Blocul de informații de date

Fiecare înregistrare de date conține o valoare, cu descrierea sa, așa cum se arată în
Tabelul 2.10, o înregistrare de date, care constă dintr-un antet de înregistrare de date (DRH) și
datele reale.
Tabelul 2.10 Structura unei înregistrări de date (transmisă de la stânga la dreapta)

DIF DIFE VIF VIFE Date
1 Bit 0-10 (1 Bit fiecare) 1 Bit 0-10 (1 Bit fiecare) 0-N Biți
Blocul de informații de date DIB Blocul valorii informațiilor VIB
Antetul înregistrării datelor DRH
30
DRH, la rândul său, constă din DIB (blocul de informații despre date) pentru a descrie
lungimea, tipul și codarea datelor, iar VIB (blocul valorii informațiilor) pentru a da valoarea
unității și a multiplicatorului. DIB conține cel puțin un bit (DIF, câmp de informații despre
date) și poate fi extins cu maximum zece DIFE (extensii de câmp de informații de date).
Informațiile cuprinse într-un DIF sunt redate în Tabelul 2.11 [3]:
Tabel 2.11 Codificarea câmpului de informații despre date (DIF)
Bit 7 6 5 4 3 2 1
Bit de LSB stocare de Câmpul funcțional Câmp de date:Lungimea și
extensie numar codificarea datelor
Câmpul de date arată modul în care datele de la master trebuie interpretate în ceea ce privește
lungimea și codificarea.Câmpul funcției oferă tipul de date după cum se prezintă în Tabelul
2.12.
Tabel 2.12 Interpretarea tipului de date

Cod Descriere Cod Descriere
00b Valoare instantă 01b Valoare maximă
10b Valoare minimă 11b Valoarea în timpul stării de eroare
De asemenea câmpul de date poate avea diferite codificări în funcție de lungimea în

biți după cum se prezintă în Tabelul 2.13.
Tabelul 2.13 Codificări ale câmpului de date:

Lungimea în biți Codificare Semnificație Codificare Semnificație
0 0000 Nu există date 1000 Selecție pentru citire
8 0001 8 biți întregi 1001 BCD 2 cifre
32/N 0101 32 biți reali 1101 Lungime variabilă
64 0111 64 biți întregi 1111 Funcții speciale
Lungime variabilă
Cu câmpul de date = `1101b` pot fi utilizate mai multe tipuri de date cu lungime
variabilă. Lungimea datelor este dată după DRH cu primul bit de date reale, care este numit
LVAR.
Exemple:
LVAR = 02h: șirul ASCII urmează cu două caractere;
LVAR = 00h .. BFh :șir ASCII cu caractere LVAR;
LVAR = C0h .. CFh : număr positiv BCD (LVAR - C0h) • 2 cifre;
31
LVAR = D0h .. DFH : număr negativ de BCD cu (LVAR - D0h) • 2 cifre;

LVAR = E0h .. EFh : număr binar cu octeți (LVAR - E0h);
LVAR = F0h .. FAh : număr de puncte variabil cu (LVAR - F0h);
LVAR = FBh .. FFh : Rezervat;
De regulă, în toate câmpurile multibit, în modul 1 ultimul caracter, respectiv în modul 2,

primul caracter, este transmis primul [3].
Funcții speciale (câmp de date=1111b)

Dacă fluxul de date după DIF=$0F sau $1F sunt înregistrări de date specifice
producătorului, numărul de biți din aceste date poate fi calculat cu ajutorul câmpului L.
DIF 1Fh semnalează o cerere din partea dispozitivului slave către dispozitivul master
pentru a citi din nou dispozitivul slave. Dispozitvul master trebuie să citească dispozitivul
slave până când nu există DIF = 1Fh în cadrul telegramei de răspuns (citire cu mai multe
telegrame). Detalii privind răspunsurile la comanda DIF sunt prezentate în Tabelul 2.14.
Tabel 2.14 Răspunsuri la comanda DIF

DIF Funcție
0Fh Începutul structurilor de date specifice producătorului până la sfârșitul datelor utilizatorului
1Fh Aceeași semnificație ca DIF=0Fh+ mai multe înregistrări urmează în următoarea telegramă
2Fh Umplutură inactivă (nu trebuie interpretată), urmând bit=DIF
3Fh..6Fh Rezervat
7Fh Cerere de citire globală (toate stocările, unități, tarife, câmpuri funcționale)
Bit-ul 6 al DIF servește pentru a da numărul de stocare a datelor în cauză, și slave-ul

poate indica și transmite diverse contra-stări sau valori stocate, în ordinea în care apar. Acest
bit este cel mai puțin semnificativ bit din numărul de stocare și permite, prin urmare, să fie
date numerele de stocare 0 și 1 fără alte DIFE. În acest fel, numărul de stocare 0 reprezintă
valoarea reală. Dacă este necesar un număr mai mare de stocare, slave-ul permite unui DIFE
să urmeze DIF-ul și îl indică setând bitul de extensie.
Fiecare DIFE (maxim zece) conține din nou un bit de extensie pentru a arăta că este
trimis un DIFE suplimentar. Pe lângă oferirea următorului bit semnificativ al numărului de
stocare, acest DIFE permite transmiterea informațiilor despre tarifar și subunitate a
dispozitivului de la care provin datele. În acest fel, exact ca în cazul numărului de stocare, va
fi transmis următorul bit sau biții cei mai semnificativi. În tabelul 2.15 se prezintă codifcarea
unui DIFE.
Tabel 2.15 Codarea extensiei câmpului informațiilor de date (DIFE)
Bit 7 6 5 4 3 2 1 0
Bit de extensie Dispozitiv Tarifar Număr de stocare
(unitate)
32
Cu maximum zece DIFE care sunt furnizate, există 41 de biți pentru numărul de
stocare, 20 de biți pentru tarif și 10 biți pentru subunitatea contorului. Nu există o aplicație
care să poată fi utilizată în acest număr imens de biți [3].
Bloc de informații despre valoare (VIB).
După un DIF sau DIFE fără un bit de extensie setat, urmează VIB (blocul de
informații despre valoare). Acesta constă cel puțin din VIF (câmpul informațional valoric) și
poate fi extins cu maximum 10 extensii (VIFE). VIF și, de asemenea, VIFE arată cu ajutorul
unui set MSB, că va urma un VIFE. În câmpul de informații despre valoare VIF, ceilalți șapte
biți dau unitatea și multiplicatorul valorii transmise așa cum se prezintă în Tabelul 2.16.
Tabel 2.16 Codarea câmpului de informații despre valoare (VIF)
Bit 7 6 5 4 3 2 1 0
Bit de extensie Unitate și multiplicator (valoare)
Există cinci tipuri de codificare în funcție de VIF:

1. VIF primar: E000 0000b .. E111 1011b
2. VIF cu text simplu: E111 1100b

În cazul VIF = 7Ch / FCh, VIF adevărat este reprezentat de următorul șir ASCII cu
lungimea dată în primul bit. Ordinea de bit a caracterelor după bitul de lungime depinde de
secvența de biți utilizată. VIF-ul cu text simplu permite utilizatorului să codifice unități care
nu sunt incluse în tabelele VIF.
3. Extensie liniară VIF: FDh și FBh

În cazul VIF = FDh și VIF = FBh VIF adevărat este dat de următorul byte și codarea este
preluată din tabel pentru VIF secundar. Aceasta extinde VIF-urile disponibile cu alte 256 de
coduri.
4. Orice VIF: 7Eh / FEh

Acest cod VIF poate fi utilizat în direcția master-slave pentru selectarea citirilor tuturor
VIF-urilor.
5. Specific producătorului: 7Fh / FFh

În acest caz, restul înregistrărilor de date, inclusiv VIFE are codificarea specifică
producătorului.
VIFE poate fi utilizat pentru acțiunile care se fac cu datele pentru raportarea erorilor din
aplicație (slave-master) și pentru o îmbunătățire a VIF (VIF ortogonal). Ultima caracteristică
permite setarea VIF în raport cu unitățile fizice de bază (de ex. VIF = 10 litri, VIFE= pe oră)
sau codarea unităților indirecte, creșterile pulsului și schimbarea vitezei [3].
33
În cazul în care VIFE = FFh, următorul VIFE și datele acestui bloc, sunt specifice
producătorului, dar VIF-ul este codat normal. După un VIF sau VIFE cu un bit de extensie de
"0", blocul de informații despre valoare este închis precum și antetul înregistrării de date;
datele actuale urmează lungimea și codarea datelor anterioare [3].
2.4.4 Bloc de date specific producătorului
MDH este format din caracterul 0Fh sau 1Fh (DIF = 0Fh sau 1Fh) și indică faptul că
toate datele următoare sunt specifice producătorului. Când numărul de biți dat în câmpul de
lungime al protocolului de conectare nu a fost încă utilizat, datele specifice producătorului
urmează acest caracter, a cărui codare este lăsată la dispoziția producătorului.
Lungimea acestor date este calculată din câmpul L minus lungimea așa-numitelor date
standard (C-Field, A-Field, CI-Field și datele până la inclusiv blocul de date 0Fh). În cazul
MDH = 1Fh, dispozitivul slave semnalează dispozitivului master că dorește să fie citit încă o
dată (citire multitelegram). Dispozitivul master trebuie să citească datele până când nu există
MDH = 1Fh în telegrama de răspuns[2].
Exemplu pentru un RSP_UD cu răspuns la structura de date variabilă:
68 1F 1F 68 Antet al telegramei RSP_UD (lungime 1Fh=31d biți)

08 02 72 Câmp C=08(RSP), adresă 2, câmp CI 72H (variabilă, LSB primul)
78 56 34 12 Număr de identificare=12345678
24 40 01 07 ID producător=4024h (PAD în EN 61107),generația 1, apă
TC=55h=85d, Status=00h, Signature=0000h
55 00 00 00 TC = 55h = 85d, Status = 00h, Signature = 0000h
03 13 15 31 00 Bloc de date 1: unitate 0, număr de stocare 0, fără tarif, volum
instantaneu, 12565 l (24 biți întregi)
DA 02 3B 13 01 Bloc de date 2: unitate 0, număr de stocare 5, fără tarif, debitul
volumului maxim, 113 l/h (4 biți BCD)
8B 60 04 37 18 02 Bloc de date 3: unitate 1, număr de stocare 0, tarif 2, energie
instantanee, 218,37 kWh (6 biți BCD)
18 16 Verifică suma și semn de oprire
34
2.5. Configurarea componentelor dispozitivului slave
Mijloacele pentru configurarea componentelor dispozitivului slave, de exemplu setarea

adresei primare sau a adresei secundare, setarea baudrate-ului sau setarea altor date de
configurare în interiorul dipozitivului slave, sunt explicate în cele ce urmează.
Comutarea baudrate-ului
Toate dispozitivele slave trebuie să poată comunica cu dispozitivul master folosind
viteza minimă de transmisie de 300 baud. Baudrate împărțit între transmisie și recepție nu este
permis, dar pot exista dispozitive cu diferite viteze de transmisie.
În conexiunile punct la punct, dispozitivul slave este setat pe o altă viteză de emisie de
către o structură de control (SND_UD cu câmpul L = 3) cu adresa FEh și unul dintre codurile
de câmp CI prezentate în Tabelul 2.17 [3].
Tabel 2.17 CI-Coduri de câmp pentru comutarea Baudrate

Câmp CI B8h B9h BAh BBh BCh BDh BEh Bfh
Baud 300 600 1200 2400 4800 9600 19200 38400
Notă 1 1 1 1,2 2
Dispozitivul slave confirmă telegrama primită corect, prin transmiterea unui E5h cu
vechiul baudrate și folosește de acum încolo noul baudrate, dacă este capabil de acest lucru.
Dispozitivul master trebuie să cunoască cea mai mare valoare de baudrate disponibilă
în dispozitiv pentru a interzice utilizatorului să treacă la o viteză de transmisie, care nu este
disponibilă bus. În acest caz dispozitivul slave nu ar mai răspunde niciodată.
Mai jos este redat un exemplu pentru schimbarea baudrate-ului dispozitivului slave.
Dispozitivul master schimbă prin intermediul conexiunii „point to point” viteza dispozitivului
slave de la 2400 la 9600 Baud
Master către slave: 68 03 03 68 | 53 FE BD | 0E 16 cu 2400 baud
Slave către master: E5 cu 2400 baud
De acum dispozitivul slave comunica cu viteza de transmisie 9600 baud.
Scrierea datelor pe un dispozitiv slave
Dispozitivul master poate trimite date unui dispozitiv slave folosind comanda
SND_UD cu CI-Field 51h pentru modul 1 sau 55h pentru modul 2.
Structura de date pentru o telegramă de scriere este prezentată în Figura 2.6. Ordinea primelor
trei blocuri din următoarea figură poate fi inversată, dar “Datele doar pentru scriere” trebuie
să fie la sfârșitul telegramei. Toate înregistrările sunt opționale [3].
Fig.2.6 Structura de date pentru scrierea datelor

Înregistrarea adresei Înregistrarea identificării Înregistrări Date doar pentru
primare îmbunătățite normale de date scriere
35
- Înregistrarea adresei primare - este opțională și constă în trei biți:
DIF = 01h VIF = 7Ah Date = Adresa (1 bit binar)

Cu această înregistrare de date, o adresă primară poate fi atribuită unui dispozitiv slave
în conexiunile „point to point”. Dispozitivul master trebuie să cunoască toate adresele utilizate
din controler și să interzică stabilirea adresei unui slave la o adresă deja folosită. În caz
contrar, datele de pe ambele dispozitive slave cu aceeași adresă nu ar mai putea fi citite.
- Înregistrarea identificării îmbunătățite
Cu această înregistrare de date opțională, identificarea (adresa secundară) poate fi

modificată. Există două cazuri care trebuie diferențiate:
1) Datele sunt doar numărul de identificare

DIF=0 Ch VIF=79h Date= Nr. De identificare (8 cifre BCD)
2) Datele sunt identificate complet

DIF=07h VIF=79h Date=ID complet (număr întreg 64 biți)
Datele sunt înmagazinate exact ca în antetul de citire al unui protocol cu variabile de $72/$76,
cu biți mici pentru modul 1 și biți mari pentru modul 2:
Nr. identificare ID producător Generație Mediu
4 biți 2 biți 1bit 1 bit
-Înregistrări normale de date
Datele înregistrate, care pot fi citite cu comanda REQ_UD2, sunt trimise înapoi la
dispozitivul slave cu DIF și VIF primite și cu noul conținut de date. Funcții suplimentare pot
fi implementate folosind stratul de obiect generalizat.
- Date doar pentru scriere
Datele care nu pot fi citite din dispozitivul slave cu un bloc de date normal, pot fi
transmise folosind VIF = 7Fh pentru codificarea specifică producătorului. DIF trebuie să aibă
o valoare corespunzătoare tipului și lungimii datelor.
După ce a primit comada SND_UD corectă, fără nicio eroare în stratul de legătură de
date, dispozitivul slave trebuie să răspundă cu o confirmare (E5h). Dispozitivul slave decide
dacă schimbă variabilele sau nu după o scriere de date de la dispozitivul master. În cazul
erorilor în executarea părților sau a instrucțiunilor de scriere întregi, dispozitivul slave poate
decide dacă nu schimbă nicio variabilă sau o singură variabilă corectă. Dispozitivul slave
poate raporta aceste erori către dispozitivul master în următoarea telegramă folosind RSP_UD
[3].
36
Exemple:
1. Setare slave la adresa principală 8 fără a schimba altceva:
68 06 06 68 | 53 FE 51 | 01 7A 08 | 25 16
2. Setare identificare completă a slave-ului (ID = 01020304, Man = 4024h (PAD), Gen = 1,
Med = 4 (Căldură):
68 0D 0D 68 | 53 FE 51 | 07 79 04 03 02 01 24 40 01 04 | 95 16
3. Setarea numărul de identificare al slave-ului la „12345678” și contorul de 8 cifre BCD
(unitate 1 kWh) la 107 kWh.
68 0F 0F 68 | 53 FE 51| 0C 79 78 56 34 12 | 0C 06 07 01 00 00 | 55 16
Configurarea ieșirii datelor
În mod implicit, dispozitivul slave transmite toate datele sale cu un RSP_UD. Ar putea
fi util pentru unele aplicații să citească doar înregistrări de date selectate de pe unul sau mai
multe dispozitive. Există două moduri de a selecta înregistrările de date:
1. Selectarea fără câmpul de date specificat

Selectarea înregistrărilor de date dorite poate fi efectuată cu un SND_UD (CI-Field = 51h /
55h) și înregistrări de date care conțin câmpul de date 1000b, ceea ce înseamnă "selecție
pentru solicitarea de citire". Următorul VIF definește datele selectate așa cum sunt enumerate
în EN1434-3 și nu sunt transmise date. Câmpul de date de răspuns este determinat de
dispozitivul slave. Dispozitivul master poate selecta mai multe variabile trimițând mai multe
blocuri de date cu acest câmp de date în aceeași telegramă [3].
Valori multiple pot fi selectate cu următoarele metode:
 Orice VIF: Codul VIF $ 7E (orice VIF) este destinat în special pentru solicitarea de
citire a „tuturor VIF” de la slave și poate fi interpretat ca un wildcard de selecție
pentru câmpul cu informații despre valoare.
 Solicitare de citire globală: Codul DIF $7F este definit ca „selecția tuturor datelor
pentru solicitarea de citire”, adică toate numerele de stocare, unitățile,tarifele și
funcțiile. Dacă acest DIF este ultimul byte al datelor utilizatorului sau urmează VIF =
$7E, atunci toate datele sunt solicitate. Deci, selectarea tuturor datelor unui slave se
poate face cu un SND_UD și caracterul $7F ca date ale utilizatorului.Dacă urmează un
DIF inegal la $ 7E, atunci toate câmpurile acestui VIF sunt selectate pentru citire.
 Toate tarifele: Cel mai mare număr tarifar din evidența de selecție este definit ca
selectarea „tuturor tarifelor”. De exemplu, tariful 1111b (15) înseamnă selectarea
tuturor tarifelor dintr-o înregistrare cu două DIFE.
 Toate numerele de stocare: O selecție a tuturor numerelor de stocare se poate face cu
numărul maxim de stocare dacă există un minim DIFE. De exemplu, cel mai mare
număr de stocare este $1F (31) cu un DIFE și $1FF (511) cu două DIFE.
 Toate unitățile: Toate unitățile” pot fi selectate folosind un antet de înregistrare de date
cu cel puțin două DIFE și cel mai mare număr de unitate.
37
 Citire de înaltă rezoluție: Master-ul poate selecta slave-ul pentru a răspunde cu

rezoluția maximă la o valoare / unitate dată de un VIF cu „nnn” =000 (exponent
minim pentru codificarea intervalului). Apoi, contorul poate răspunde cu o rezoluție de
exemplu de 1 mWh (VIF = 0000000b) sau o valoare zecimală mai mare, dacă este
necesar. Valorile unității au fost alese astfel încât minimul lor să ofere o rezoluție
suficientă chiar și pentru calibrare. O solicitare de citire pentru un VIF cu "nnn" = max
(exponent maxim pentru codificarea intervalului) semnalează o solicitare pentru
rezoluția standard a contorului.
După următoarea comandă REQ_UD2, dispozitivul slave răspunde cu datele selectate în

formatul propriu, dacă datele solicitate sunt disponibile. În caz contrar, dispozitivul slave
transmite datele sale normale, iar dispozitivul master trebuie să afle că datele nu sunt cele
solicitate. Dacă există mai multe variabile cu VIF-ul selectat, dispozitivul ar trebui să trimită
toate aceste înregistrări de date [3].
2.Selecție cu câmpul de date specificat

Dispozitivul master este capabil să efectueze o solicitare de citire cu un câmp de date
specificat folosind acțiunea obiect „add to readout list” (VIFE = E000 1100b) din tabela VIFE
pentru acțiuni obiect. Dispozitivul master transmite un SND_UD (CI-Field = 51h/ 55h) cu o
înregistrare de date care constă din DIF-ul dorit (câmp de date), VIF și VIFE = 0Ch / 8Ch. Nu
există date care să urmeze acest VIFE și dispozitivul slave ar trebui să ignore câmpul de date
de la recepție. Dispozitivul slave ar trebui să transmită această înregistrare cu câmpul de date
solicitat de acum înainte, dacă este capabil de acest lucru. Dacă dispozitivul slave nu acceptă
acest câmp de date (codarea datelor), poate raporta o eroare de înregistrare folosind unul
dintre VIFE = E000 011x (clasa de date neimplementată sau dimensiunea datelor nu este
implementată) [3].
Deselectarea înregistrărilor de date

Dispozitivul master poate elibera o resetare a stratului de aplicație și, în special, o
retragere a dispozitivului slave la standardul RSP_UD-Telegram, prin transmiterea unei
comenzi SND_UD cu câmpul CI-Field $ 50. Înregistrările de date unice pot fi deselectate prin
transmiterea unei înregistrări de date cu DIF, VIF și VIFE pentru acțiunea obiectului „Delete
from Readout-List” (VIFE = E000 1101b).
Dacă datele selectate sunt acceptate de dispozitivul slave, dar dacă răspunsul este prea
lung pentru o telegramă RSP_UD (în special pentru citirea tuturor valorilor înregistrate),
dispozitivul slave transmite o înregistrare suplimentară de date, constând doar din DIF = $ 1F,
ceea ce înseamnă că mai multe înregistrări de date urmează următoarea în telegramă de
răspuns. În acest caz, dispozitivul master trebuie să citească din nou dispozitivul slave până
când telegrama răspuns este doar un $ E5 (fără date) sau nu există DIF = $ 1F în RSP_UD.
Pentru a evita pierderea de date dispozitivul slave ar trebui, în acest caz, să susțină
Frame Count Bit (FCB). Dacă dispozitivul master dorește să încheie prematur o astfel de
citire secvențială multitelegramă a datelor selectate, poate trimite o resetare a aplicației cu CI
= $50 în loc de REQ_UD2 [3].
38
Exemple:
1. Un dispozitiv slave cu adresa 7 trebuie configurat pentru a răspunde cu înregistrările de
date care conțin volum (VIF = 13h: volum, unitate 1l) și temperatură de curgere (VIF = 5Ah:
temperatură de curgere, unitate 0,1 ° C).
68 07 07 68 | 53 07 51 | 08 13 08 5A | 28 16
2. Un dispozitiv slave cu adresa 1 trebuie configurat pentru a răspunde cu toate numerele de

stocare, toate tarifele, și toate VIF-urile de la unitatea 0.
68 06 06 68 | 53 01 51 | C8 3F 7E | 2A 16
3. Un dispozitiv slave cu adresa 3 trebuie configurat pentru a răspunde cu toate datele pentru o
citire completă a tuturor celor disponibile. După aceea, dispozitivul master poate cere aleator
slave-ului pentru a obține datele.
68 04 04 68 | 53 03 51 | 7F | 26 16
39
CAPITOLUL 3
STUDIU DE CAZ, IMPLEMENTAREA UNEI APLICAȚII
DE SMART METERING
3.1. Implementarea soluției software
Soluția software utilizată pentru implementarea aplicației de smart metering este

realizată prin intermediul aplicației E!COCKPIT.
e!COCKPIT este un mediu de dezvoltare integrat compatibil cu orice sarcină de
automatizare, de la configuraţie hardware, programare, simulare şi vizualizare până la punerea
în funcţiune - un pachet de software complet integrat.
Configurare şi parametrizare
Programele de configurare integrate e!COCKPIT oferă instrumente şi spaţii de lucru
moderne, precum:
- Reprezentare grafică a topologiei de reţea: relaţiile complexe dintre dispozitivele
conectate în reţea şi stările lor curente pot fi identificate uşor şi intuitiv.
- Glisare şi fixare: Simplifică interacţiunea cu dispozitivele.
- Copiere şi lipire: Se pot copia uşor dispozitive individuale sau ramuri întregi de
reţea. Procesare în masă: se setează simultan valorile parametrilor pentru mai multe
dispozitive.
Programare
e!COCKPIT oferă opţiuni vaste pentru dezvoltarea de software: limbaje de
programare pentru PLC-uri conforme IEC 61131-3, precum Text structurat (ST), Schemă tip
scară (LD), Schemă sinoptică (FBD), Listă de instrucţiuni (IL), Tabel funcţii secvenţial (SFC)
şi Tabel funcţii continuu (CFC). Toate limbajele de programare pot fi combinate între ele.
Programele create pot fi depanate uşor pe PC-ul de proiectare prin simulare. Sunt incluse
paradigme noi precum programarea orientată pe obiecte.
Vizualizare
Interfeţele de utilizare avansate pentru controlarea şi monitorizarea utilajelor sunt
standard. În prezent, proiectarea pe bază de interfaţă om-maşină este un factor critic care
influenţează achiziţionarea unei întregi linii de automatizare.e!COCKPIT foloseşte procedura
glisare şi fixare pentru fluidizarea proiectării interfeţelor de utilizare moderne. Editorul cu
vizualizare integrată oferă acces la variabile de program IEC, simulare închisă a interfeţei om-
maşină şi a programelor pentru PLC-uri pe PC-ul de proiectare şi independenţă garantată de
limbaj cu set de caractere Unicode. De asemenea, sunt acceptate standarde curente precum
HTML5 şi CSS [6].
40
Diagnoză
Cunoaşterea în detaliu a stării curente a reţelei de automatizare este o necesitate

absolută pentru detectarea şi eliminarea rapidă a erorilor, fie în timpul dezvoltării în birou sau
direct la utilaj în timpul punerii în funcţiune. e!COCKPIT oferă opţiuni vaste de diagnostic în
acest scop, cu vizualizări individuale care afişează întotdeauna starea curentă a sistemelor de
control sub formă de tabele şi scheme. Pentru încadrarea proiectului în termenele limită,
mesajele de eroare sunt transmise direct şi clar. Iar funcţia de testare a cablajului structurat
identifică sistematic erorile de cablare [6].
Etapele implementării soluției software:
1. Conectarea controlerului PFC200 750-8212/000-100 la PC prin intermediul

comunicației seriale.
2. Creearea unui nou proiect în aplicația e!COCKPIT
3. Identificarea componentelor în aplicație (Figura 3.1)
Fig. 3.1 Componetele aplicației
41
4. Scrierea codului în aplicație
Pentru realizarea aceastei etape este posibilă utilizarea schemelor bloc funcționale
(Figura 3.2). Structura programului este construită pe 7 niveluri: pe primul nivel am
configurat componenta M-bus master. Această componentă are ca date de intrare interfața de
comunicație, adresa dispozitivului master M-bus și ca ieșire obiectul sStatus.
Pe nivelul 2 în diagramă se observă un temporizator care ne permite sa executăm
cereri de citire de date având un pas de citire/discretizare de date de 5 secunde. Pasul de
discretizare este ales de granularitatea datelor.
Conform principiilor de funcționare ale temporizatorului TON_0, după expirarea
intervalului impus, ieșirea Ton_0.Q setează variabila xStart_0 cu valoarea TRUE. Această
variabilă, odată setată TRUE declanșează citirea de date de pe nivelul 3.
Fig. 3.2 Utilizarea schemelor bloc pentru programarea dispozitivului
După terminarea citirii regiștrilor (Energy, Power, Voltage, Current) dispozitivului

slave acestea sunt transmise către dispozitivul master și stocate în vectorii typEnergy,
typPower, typVoltage, typCurrent. Datele achiziționate sunt prelucrate de 4 structuri/obiecte
42
de tip FuUnitConverter. După realizarea conversiei, obiectul FuUnit Converter încarca

valoarea în GVL.rValue_1 pentru typPower, GVL.rValue_2 pentru typVoltage,
GVL.rValue_3 pentru typEnergy, GVL.rValue_4 pentru typCurrent (Figura 3.2) sau scrierea
de cod (Figura 3.3) în editorul de text.
În Figura 3.3 se poate observa că sunt trecute inclusiv unitățile de masură ale
fiecărei valori transmise de dispozitivul slave.
Fig. 3.3 Liniile de cod utilizate pentru programarea dispozitivului
43
3.2. Implementarea soluției hardware

Montajul utilizat, așa cum apare în Figura 3.4, este format dintr-o sursă de alimentare
cu modul comutat 24V/2,5A EPSITRON ECO Power (vezi detalii tehnice mai jos), un
controler WAGO PFC200 750-8212/000-100, un modul M-Bus 753-649, un dispozitiv smart
meter Honeywell EEM 230D-M și o priză cu 2 consumatori.
Parametrii electrici pot fi vizualizați fie pe display-ul smart meterului sau pe aplicația
dezvoltată în limbajul de programare e!Cockpit.
Fig. 3.4 Instalatia experimentală
44
Soluția hardware este implementată folosind următoarele componente:
1. Sursă de alimentare cu modul comutat; EPSITRON ECO Power [7]
Figura 3.5 Sursă de alimentare
Sursă de alimentare cu modul comutat

Răcirea naturală prin convecție atunci când este montată pe
orizontală
Încapsulată pentru utilizare în dulapuri de control
Potrivit atât pentru funcționare în paralel, cât și în serie
Date tehnice:
Intrare
Faze 1
Tensiunea nominală de intrare Ui nom AC 110...240V
Interval tensiune de intrare AC 85 ... 264 V; DC 90 ... 373 V
Interval de frecvență de rețea nominală 47 ... 63 Hz; 0 Hz
Curent de intrare Ii ≤ 0,7 A (230 VAC); ≤ 1,2 A (115 VAC)
Curent de descărcare ≤ 1 mA
Curent de intrare ≤ 30 A
Factor de putere ≥ 0,5 (230 VAC)
Corecția factorului de putere Pasivă
Timpul de reținere a eșecului de la rețea ≥ 20 ms (230 VAC)
Ieșire
Tensiune nominală de ieșire DC 24 V (SELV)
Interval tensiune de ieșire DC 22 ... 28 V (reglabil)
Setare de bază DC 24 V
Curent nominal de ieșire 2,5 A (24 VCC)
Putere nominală de ieșire 60 W
Abaterea controlului ≤ 1%
Ondulația reziduală ≤ 100 mV (vârf la vârf)
Comportament la suprasarcină Putere constantă (în domeniul de
suprasarcină: 1,15 ... 1,4 x Io nom ); Oprire și
repornire automată în caz de scurtcircuit
Semnalizare și comunicare
Semnalizare 1 x LED DC OK (verde)
1 x LED de suprasarcină (roșu)
Indicator stare de funcționare LED verde (24 VCC OK)
LED roșu (supraîncărcare)
Eficiență/pierderi de putere
Pierdere de putere Pi ≤ 8,3 W (230 VAC; sarcină nominală)
Pierdere de putere(max.) Pi(max) 11,5 W (110 VAC / 24 V CC; 2,75 A)
Eficiență(tip) 86% (230 VAC)
45
Protecția prin siguranțe

Siguranță internă F 2,5 A / 250 VAC
Siguranță de rezervă obligatorie Pentru tensiunea de intrare continuă este
necesară o siguranță continuă DC.
Siguranță de rezervă recomandată Întrerupător: 10 A, 16 A;
Caracteristică de declanșare: B sau C
Date de conectare
Tip conexiune (1) Intrare/Ieșire
Tehnologie de conectare CAGE CLAMP
Conector WAGO Seria Wago 745
Conductor solid 0,08 ... 4 mm²
Conductor cu fir fin 0,08 ... 4 mm²
Lungimea de bandă 8...9 mm
Condiții de exploatare
Temperatura aerului din jur (funcționare) -10 ... 70 ° C
Temperatura aerului din jur (depozitare) -25 ... 85 ° C
Umiditate relativă ≤ 95% (nu se admite condens)
Reducrea randamentului de funcționare -3,3% / K (> 50 ° C; 230 VAC)
Grad de poluare 2
2. Controler PFC200 750-8212/000-100 [8]
Figura 3.6 Controller PFC200
PFC200 Controller este un PLC compact pentru sistemul

modular WAGO I / O. Pe lângă interfețele de rețea și fiedbus,
controlerul acceptă toate modulele digitale, analogice și de
specialitate găsite în seria 750/753.
Două interfețe ETHERNET și un comutator integrat permit
cablarea topologiei liniei.
Un server Web integrat oferă opțiuni de configurare a
utilizatorului, în timp ce afișează informații despre starea
PFC200.
Comunicare ETHERNET, RS-232 Interfață Serială

RS-485 Interfață Serială, EtherNet / IP TM
(slave), bibliotecă pentru e! RUNTIME
EtherCAT Master, MQTT
Protocoale ETHERNET DHCP,DNS,NTP,FTP,FTPS,SNMP,HTTP,
HTTPS,SSH
Vizualizare Web Visu
Sistem de operare Linux
Procesor Cortex A8; 1GHz
Mediul de programare e! COCKPIT (bazat pe CODESYS V3)
Opțiuni de configurare e! COCKPIT
46
WAGO-I / O-CHECK
Management bazat pe web
Biblioteca e! RUNTIME
CODESYS
Rata de transfer (comunicare) 10/100 Mbit /s
Rata Baud ETHERNET: 10/100 Mbit / s
Mediu de transmisie (comunicare/field bus) ETHERNET: Twisted Pair S-UTP; 100 Ω;
Cat. 5; 100 m lungimea maximă a cablului
Memorie principală (RAM) 512 MB
Memorie internă (flash) 4000 MB
Memorie hardware nevolatilă 128 Kbytes
Memorie de program, date 60 MB Program de memorie și date
(distribuite dinamic)
Memorie software nevolatilă 128 Kbytes
Număr de module pe nod (max.) 250
Număr de module fără extensie de bus (max.) 64
Imaginea procesului de intrare și ieșire 1000 Scrieri
(intern) (max.)
Indicatori LED (SYS; RUN; I / O; BT; U1 ... U6) roșu /
verde / portocaliu: Starea sistemului;
program; bus de date local; BACnet; starea
programabilă de către utilizator (poate fi
utilizată prin intermediul bibliotecii
CODESYS); LED (A, B) verde: starea
alimentării sistemului;
Tensiunea de alimentare (sistem) DC 24 V (-25 ... + 30%); prin conector
conectabil (conexiune CAGE CLAMP)
Curent de intrare (tip.) La sarcină nominală 550 mA
(24 V)
Curent total (alimentare sistem) 1.700 mA
Numărul de contacte de ieșire 3
Date de conectare
Tehnologia de conectare: comunicare / bus BACnet/IP: 2 x RJ-45;
RS-232 interfață serială: 1 port D-sub 9;
RS-485 interfață serială: 1 port D-sub 9;
Tehnologie de conectare: alimentare sistem 2 x CAGE CLAMP
Tehnologie de conectare: furnizare de câmp 6 x CAGE CLAMP
Tip conexiune Sistem/alimentare priză
Conductor solid 0,08 ... 2,5 mm²
Conductor cu fir fin 0,08 ... 2,5 mm²
Lungimea benzii 8 ... 9 mm
Tehnologie de conectare: Configurația 1 conector tip ”Tată”; 4 poli
dispozitivului
Temperatura aerului din jur (funcționare) 0 ... 55 ° C
Tipul de protecție IP20
Grad de poluare (5) 2 conform IEC 61131-2
47
Altitudine de operare fără decalaj de temperatură: 0 ... 2000 m; cu

decalaj de temperatură: 2000 ... 5000 m (0,5
K / 100 m); 5000 m (max.)
Umiditate relativă (fără condens) 95%
3. Dispozitv M-Bus Master 753-649 [9]
Figura 3.7 Dispozitiv M-Bus Master 753-649
Modulul M-Bus 753-649 acționează ca un master M-Bus,

permițând conectarea directă a dispozitivelo slave M-Bus la sistemul I /
O WAGO 750. Dispozitivul master M-Bus comunică cu dispozitivele
slave și formează interfața dintre M-Bus și software-ul de procesare. La
cerere, dispozitivul master citește datele privind consumul de energie
prin intermediul liniei M-Bus cu 2 fire, transmitând aceste date către
sistemul de control de nivel superior pentru mai multă procesare sau
vizualizare. În mod alternativ, interogările PLC pot fi implementate prin
intermediul PLC folosind blocuri funcționale IEC 61131-3 sau printr-o
aplicație PC.
Dispozitivele slave M-Bus sunt alimentate prin intermediul M-Bus master. Nu este
necesară utilizarea unui convertor de nivel separat.Atât transmiterea semnalului, cât și starea
de funcționare, precum și comunicarea M-Bus locală fără probleme, sunt indicate prin LED-
uri monocromatice și multicolore.Modulele de conexiune M-Bus sunt protejate de
scurtcircuit.
Date tehnice
Specificul dispozitivului Lungimea liniei: până la 1000m la 9600
baud; până la 2000m la 2400 baud; până la
6000 m at 300 baud; Distanță master/slave:
până la 500 m la 9600 baud; până la 1000 m
la 2400 sau 300 baud; Dispozitive M-Bus
(max.): 40 (1.5 mA fiecare);
Valoare curentului de prag: approx. 120 mA;
Timp minim de stingere 500 ms
Tip conexiune Stea sau triunghi
Tensiune de ieșire 23,4...25,2 V; pentru alimentarea
dispozitivelor slave
Rata de transfer Baud 300 Baud … 9,6 kBd (2400 baud (standard))
Canale de transmisie 1, bidirecțional
Lățimea semnalului de date 24 biți
Punere în funcțiune WAGO-I/O-PRO V2.3, e!COCKPIT
Tensiune alimentare 5V
Consum de energie (alimentare 5V) 40 mA
48
Tensiunea de alimentare (în rețea) 24 V (-2.5 … +5 %)

Consum de energie, alimentare în rețea 130 mA
(modul fără încărcătură externa)
Izolație 500V (sistem/rețea)
Date de conectare
Tehnologie de conectare: intrări / ieșiri 8 x CAGE CLAMP
Tip conexiune (1) Intrări / ieșiri
Conductor solid 0,08 ... 2,5 mm²
Conductor cu fir fin 0,08 ... 2,5 mm²
Lungimea benzii 8 ... 9 mm
Cerință de conectare (tip de cablu admis) 2 linii, protejate sau neprotejate
Temperatura aerului din jur (funcționare) 0 ... 55 ° C
Altitudine de operare 0 ... 2000 m
Poziție de montare orizontal (în picioare / culcat); vertical
Umiditate relativă (fără condens) 95 %
Dispozitiv Honeywell EEM 230D-M [10]
Figura 3.8 Controller Honeywell EEM 230D-M
Contor de energie electrică cu interfață M-Bus

integrată.
Contorul de energie electrică cu o interfață M-Bus
integrată permite citirea directă a tuturor datelor relevante,
cum ar fi energia (totală și parțială), curent, tensiune, putere
activă și reactivă.
Date tehnice
Tensiune de fucționare 230 V, 50 Hz
Toleranță –20% / +15%
Curent de referință/măsură Iref = 5 A / Imax = 32 A
Curent de pornire/minim Ist = 20 mA / Imin = 0,25 A
Consum de curent Activ 0,4 W pe fază
Gama de numărare 00000.00…99999.99
100000.0…999999.9
Display LCD, cu cifre înalte de 5mm
49
Izolație 4 kV/50 Hz
Date de conectare
Conexiuni terminale circuit principal Conductor max. 6 mm²
Conexiuni terminale circuit de control Conductor max. 2,5 mm²
Temperatura aerului din jur (funcționare) -25 ... 55 ° C
Umiditate relativă (fără condens) 95 % la 25°…+40 °C
3.3. Prelucrarea datelor măsurate
Se observă în figurile 3.9-3.12 că cele mai importante valori sunt conținute în regiștrii
sValue și sUnit. Registrul sValue înregistrează valoarea citită folosind formatul STRING, iar
sUnit stochează unitatea de măsură. Pentru vizualizarea datelor într-un format comprehensiv
de către utilizatorii de rând am realizat o aplicație Visualization care permite interpretarea
rezultatelor în timp real (Figura 3.13).
În urma implementării soluției software s-au obținut următoarele date pentru prelucrare:
 Date referitoare la consumul de curent se pot vizualiza în Figura 3.9, sValue
reprezentând valoarea numerică a parametrului monitorizat, în timp ce sUnit
reprezintă unitatea de masură.
Fig 3.9 Monitorizarea consumului de curent
 Date referitoare la puterea consumată se pot vizualiza în Figura 3.10, sValue

50
Fig 3.10 Monitorizarea puterii consumate
 Date referitoare la tensiunea din rețea se pot vizualiza în Figura 3.11, sValue
Fig 3.11 Monitorizarea tenisunii
 Date referitoare la intensitatea curentului din rețea se pot vizualiza în Figura 3.12,
sValue reprezentând valoarea numerică a parametrului monitorizat, în timp ce sUnit
51
Fig 3.12 Monitorizarea intensității
Vizualizarea parametrilor înregistrați de la dispozitivele master-slave cu ajutorul

funcției Visualization din aplicația E!cockpit este următoarea:
Fig. 3.13 Funcția Visualization
Principalii parametrii monitorizați au fost puterea, tensiunea, intensitatea și energia

consumată de dispozitivele conectate în priza smart-meterului.
52
CAPITOLUL 4
IMPLEMENTAREA SOLUȚIEI DE IoT PENTRU STOCAREA ȘI
PROCESAREA DATELOR
4.1. Configurarea soluției IoT pentru stocarea datelor
Pentru stocarea datelor pe platformele Cloud de tip IoT, au fost analizate 2 platforme:
Platforma Ubidots
Ubidots este o platformă care facilitează dezvoltarea proceselor IoT. Platforma

Ubidots permite trimiterea datelor în Cloud de pe orice dispozitiv cu conexiune la internet. Se
pot configura alarme și acțiuni pe baza datelor colectate în timp real și se pot debloca valorile
datelor prin intermediul instrumentelor vizuale.
Ubidots oferă o plaformă de tip API REST (Application Programming Interface
reprezintă un set de definiții de sub-programe, protocoale și unelte pentru programarea de
aplicații și software. Un API poate fi pentru un sistem web, sistem de operare, sistem de baze
de date, Hardware sau biblioteci software; REST- Representational State Transfer - este o
modalitate pentru două sisteme de computer de a comunica prin HTTP într-un mod similar cu
browserele web și serverele) care permite citirea și scrierea datelor disponibile: surse de date,
variabile, valori, evenimente și informații. Pentru stocarea surselor de date pot fi utilizate
protocoalele HTTP cât și HTTPS pentru a crește securitatea datelor schimbate între platforma
Ubidots și dispozitivele Internet of Things, sunt utilizate două chei de criptare: una publică și
una privată.
Datele sunt copiate de două ori și depozitate utilizând formatul criptat sau nu, alegerea
aparținând programatorului. În plus, se pot personaliza grupuri de permisiuni pentru fiecare
modul al platformei, în acest fel informațiile potrivite vor fi afișate utilizatorului potrivit.
Platforma Ubidots are un instrument interactiv de vizualizare care permite selectarea
perioadelor de interes pentru utilizator. În plus soluția oferă posibilitatea de a descărca
paramaterii monitorizați în formatele csv sau xslx. De asemenea platforma Ubidots oferă și
alte funcționalități precum transmiterea de alerte prin e-mail, sms a unor valori importante
pentru utilizator.
Cum functioneaza Ubidots?
De fiecare dată când un dispozitiv actualizează o valoare preluata de dispozitivele IoT,
se creează o structura de date denumită "dot".
53
Fig 4.1. Ierarhia datelor Ubidots [12]
Așa cum apare în Figura 4.1 ierarhia datelor Ubidots are pe nivelul superior
dispozitivul Internet of Things care generează mai multe serii de date. După fiecare citire
datele sunt afișate fie sub formă grafică fie sub formă tabelară. [11]
Platforma Wago Cloud

Prin intermediul acestei platforme este posibilă colectarea, analiza și gestionarea
datelor într-un mod centralizat. Această platformă oferă posibilitatea de a monitoriza și
controla de la distanță diferitele dispozitive existente în clădirile rezidențiale sau terțiare.
Aplicația Wago Cloud a fost dezvoltată utilizând tehnologia Microsoft Azure. Această
platformă are 4 meniuri principale: meniul de configurare a dispozitivului Wago, accesul de la
distanță la resursele echipamentului, vizualizare și alarme.
Fig 4.2 - Realizarea comunicării dintre dispozitiv și cloud
54
Cum comunică dispozitivele cu platforma WAGO cloud?

Într-o primă etapă semnalele electrice provenite de la modulele controlerului sub
forma de curent și tensiuni, reprezentate în format analogic sunt converite la un format digital
și stocate în memoria RAM a controlerului PFC. De obicei, informațiile colectate sunt
reprezentate pe 12/16/24 biți, oferind o eroare extrem de mică în urma conversiei semnalului
analogic în semnal digital.
Odată ce valorile sunt stocate în memoria RAM acestea sunt prelucrate și încărcate în
regiștrii de date care ajung să fie încărcate pe platforma WagoCloud (Figura 4.2). Ca și în
cazul Ubidots, platforma Wago Cloud utilizează doua chei de conectare le resursele
platformei. ID-ul dispozitivului și cheia de activare generate de platforma WagoCloud sunt
încărcate și în controlerul PFC prin intermediul interfeței de configurare web a acestuia.
În plus platforma permite setarea de diferite funcții precum transmiterea de notificari
prin e-mail atunci când apar anumite elemente de interes pentru utilizator [12].
În Figura 4.3, în secțiunea settings se alege platforma de tip cloud, denumirea
platformei sub forma de Ip sau adresa Web, ID-ul dispozitivului și cheia de activare. După
resetarea controlerului în secțiunea status se observă că, conexiunea a fost realizată cu succes
iar intervalul de transfer al datelor este de 120 secunde.
Fig 4.3 Configurarea datelor de acces pentru stocarea parametrilor în platforma Wago
Cloud
Introducerea în cloud a cheii de activare pentru a se realiza conexiunea dispozitivului

master cu platforma de stocare a datelor (Figura 4.4)
55
Fig 4.4 Cheia de activare și ID Device
Confirmarea realizării comunicației între controler și platforma cloud (Figura 4.5):
Fig 4.5 Comunicația între dispozitiv și platforma Wago Cloud
56
Pentru încărcarea datelor pe platforma Wago Cloud, în aplicația e!Cockpit este

necesară utilizarea următoarelor linii de cod pentru publicarea lor în cloud (Figura 4.6):
Fig 4.6 Liniile de cod utilizate pentru încărcarea datelor pe platforma Wago Cloud
După cum se poate observa în Figura 4.6, am utilizat un interval de publicare al

datelor de 5 secunde. Am creat două colecții de date preluate pentru publicarea lor în cloud. În
prima colecție de date, am ales pentru stocare valorile respective pentru puterea consumată și
tensiune, iar în a doua colecție de date, am selectat valorile pentru energie și intensitatea
curentului electric.
57
4.2. Implementarea soluției de procesare a datelor
În urma încărcării datelor pe platforma Wago Cloud, acestea sunt stocate și oferă
posibilitatea vizualizării lor atât în timp real, cât și posibilitatea accesării datelor din trecut.
Platforma oferă posibilitatea vizualizării sub forma de tabel (Figura 4.7) sau grafic (Figura
4.8, 4.9, 4.10, 4.11).
Fig 4.7 Afișarea în timp real sub formă de tabel a parametrilor citiți:
În urma procesării datelor încărcate pe platorma WAGO Cloud se poate observa

(Figura 4.8) variația în timp a valorii tensiunii electrice. Această variție prezintă valorile
tensiunii si fluctuațiile acesteia în functie de momentul zilei și de încărcarea rețelei. Conform
standardului EN 50160 valoarea medie a tensiunii în 95% din timp ar trebui sa fie între 90-
110% din valoarea tensiunii nominale [13].
Fig. 4.8 Variația tensiunii în timp
58
În Figura 4.9 se poate observa variația consumului de putere în funcție de momentul

respectiv al zilei și echipamentele electronice conectate la rețeaua electrică proprie.
Fig. 4.9 Variația consumului de putere
În Figura 4.10 se poate observa variația consumului de energie în funcție de momentul

respectiv al zilei și echipamentele electronice conectate la rețeaua electrică proprie.
Fig. 4.10 Variația consumului de energie
59
În Figura 4.11 se poate observa variația intensității curentului electric în funcție de

momentul respectiv al zilei și echipamentele electronice conectate la rețeaua electrică proprie.
Fig. 4.11 Variația intensității
Pentru simularea de situații reale am recurs la întreruperea alimentării diferitelor

dispozitive conectate la instalația experimentală. Astfel s-au putut observa variații ale
consumului de energie și a intensității curentului electric.
60
CONCLUZII
1. În prezenta lucrare protocolul M-Bus a fost impementat cu succes pentru obținerea

datelor de la dispozitivele de tip master-slave, programând controlerul în aplicația
e!Cockpit. În această aplicație (e!Cockpit) s-a utilizat ca metodă de obținere a datelor
atât schema bloc, cât și codarea în aplicație. În aplicația e!Cockpit se pot vizualiza în
timp real parametrii monitorizați prin intermediul funcției Visualisation.
2. Datele preluate de la controler prin intermediul protocolului M-Bus au fost încărcate

pe platforma Wago Cloud, de tip Internet of Things pentru a putea fi vizualizate în
orice moment al zilei de către utilizator. În urma stocării datelor pe platforma Wago
Cloud se pot vizualiza fluctuațiile parametrilor în funcție de diferiți factori.
3. Platformele de tip Internet of Things pot realiza fără întreruperi integrarea diverselor
dispozitive echipate cu capabilități de detectare, identificare, procesare, comunicare și
acționare. În timp ce conectivitatea și achiziția de date sunt strict necesare pentru
Internet of Things, acestea nu ar trebui să fie un scop în sine ci un mijloc de evoluție
tehnologică.
4. Un avantaj al utilizării platformelor de tip Internet of Things îl reprezintă posibilitatea

setării de alarme în cazul depășirii unor valori stabilite de utilizator. Astfel, platforma
poate emite notificări (de exemplu trimiterea unui e-mail) utilizatorului pentru
înștiințarea acestuia.
5. Smart-metering (contorizarea inteligentă) creează noi oportunități în domeniul

furnizării și administrării utilităților publice, domeniu aflat în plină ascensiune la nivel
mondial. Cele mai multe schimbări se vor produce prin introducerea tehnologiilor
digitale moderne în domeniul producției, transportului și consumului de energie
electrică.
6. Utilizarea dispozitivelor de tip master-slave pentru citirea parametrilor electrici poate

reprezenta o soluție de viitor pentru furnizorii de energie electrică, deoarece astfel se
poate verifica oricând consumul de energie al utilizatorilor. Totodată, furnizorul poate
preconiza mult mai usor consumul de energie electrică necesar a fi achiziționat,
respectiv poate elimina cheltuielile necesare utilizării agenților de teren pentru citirea
periodică a contoarelor, economisind astfel timp și bani.
61
7. Această aplicație poate ajuta la educarea populației deoarece permite monitorizarea

consumului de energie electrică, prin crearea posibilităților de a identifica eventualele
vârfuri ale consumurilor, cu implicații în reducerea valorii facturilor de electricitate.
De asemenea, prin această aplicație se poate vizualiza în timp real efectul acțiunilor
utilizatorului asupra consumului de electricitate.
62
BIBLIOGRAFIE
1. Vladimir Tanasiev curs de Programarea Microprocesoarelor si Microcontrolerelor,

semestrul I anul 2019
2. OMS Group, Open Metering System Specification, Vol 2, 2014.
3. The M-Bus: A Documentation - https://m-bus.com/assets/downloads/MBDOC48.PDF
4. IBM Marketing Cloud, 2017 „Data never sleeps”
5. https://www.coursehero.com/file/18978144/MBDOC48/
6. https://www.wago.com/ro/software/e-cockpit/p/2759-101_1110-3000
7.https://www.wago.com/ro/power-supplies-modules/switched-mode-power-supply/p/787-
712
8. https://www.wago.com/ro/plcs-controllers/controller-pfc200/p/750-8212_000-100
9. https://www.wago.com/ro/io-systems/m-bus-master/p/753-649
10.https://products.ecc.emea.honeywell.com/europe/pdf/eem230-d-m-p26-587-en01-
ge51r0617.pdf
11. https://ubidots.com/about/
12. https://www.wago.com/global/software/wago-cloud/p/2759-1061_651-050
13.https://copperalliance.org.uk/uploads/2018/03/542-standard-en-50160-voltage-
characteristics-in.pdf
63

Toader Andrei Proiect de Diploma

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Toader Andrei Proiect de Diploma

Încărcat de

Drepturi de autor:

Formate disponibile

Universitatea POLITEHNICA din Bucureşti

Autor: Andrei M. TOADER

Cadru didactic îndrumător: Conf. Dr. Ing. Vladimir TANASIEV

Implementarea protocolului M-bus pentru o

Universitatea POLITEHNICA din București

pentru obținerea titlului de

Specializarea: Informatică industrială

Susținut în Iulie, în fața comisiei de examinare

Prof. dr. ing. Constantin BULAC Președinte

Această lucrare a fost pregătită în cadrul Facultății de Energetică a UPB

1.1. Funcții de bază ale sistemului Bus......................................................... 6

2.1. Nivelul fizic............................................................................................... 12

2.4.4 Bloc de date specific producătorului............................................. 34

3.1. Implementarea soluției software............................................................ 40

4.1. Configurarea soluției IoT pentru stocarea datelor.............................. 53

Indiferent de domeniul de activitate, de industria în care se profesează, de momentul

1.1. Funcții de bază ale sistemului Bus

M-bus (Meter-Bus) este un standard european ce a fost dezvoltat pentru a satisface

În majoritatea reţelelor locale, una din următoarele topologii exemplificate în Figura

Fig. 1.1 Topologii de rețea

Stea: Fiecare componentă este conectată la o unitate de procesare centrală cu o linie

Fig. 1.2 Clasificarea tehnicilor de sincronizare

Acolo unde există o confirmare a semnalului (handshake), expeditorul arată cu un

1.2. Modelul de referință OSI

Acest model grupează protocoalele de comunicare în 7 niveluri, fiecare având o

Fiecare nivel, cu excepţia nivelului 1, obține setul de date necesar de pe nivelul

- caracterul complet al informațiilor și securitatea transportului în stratul 4;

Tabel 1.1 Reparția pe straturi a protocolului M-bus

Stratul legăturii de date

1.3. M-bus și modelul OSI

Fig. 1.3 Repartiția pe straturi a protocolului M-bus conform modelului OSI

Traseul urmat de date de la transmitor la receptor se realizează conform celor

Fig. 1.4 Transmiterea datelor în conformitate cu modelul OSI

La partea de transmitere a informațiilor (overhead), care este necesară pentru transmisie

2.1. Nivelul fizic

M-bus este un sistem ierarhic, cu comunicarea controlată de un master (logică centrală de

Fig. 2.1 Reprezentarea principiului de funcționare al sistemului M-Bus

Transferul de biţi master-slave este realizat prin intermediul a 2 tensiuni. O valoarea

Fig. 2.2 Reprezentarea biților în protocolul M-Bus

2.1.2 Comunicarea prin cablu (M-Bus)

2.1.2.1 Specificații electrice

2.1.2.2 Conexiuni hardware și cablu

2.1.3 Comunicarea wireless (wM-Bus)

2.1.3.1 Moduri și cerințe

2.1.3.2 Transmisie sincronă versus asincronă

Fig. 2.3 Numărul de acces pentru transmisii sincrone și asincrone

Tabel 2.1 Intervalul de actualizare al datelor de consum pentru diferite medii

2.2. Nivelul de date

Acest nivel are responsabilitatea de a asigura o conexiune sigură între doua

Fig. 2.4 Transmiterea caracacterelor între dispozitivele master - slave

2.3. Formatul telegramelor

Fig. 2.5 – Formatul telegramelor în protocolul M-Bus

Single Character (Caracter unic)

Short Frame (Structură scurtă)

Control Frame (Structură de control)

Long Frame (Strucură lungă)

2.3.1 Specificul secțiunilor

În această secțiune, vor fi explicate secțiunile utilizate pentru formarea telegramelor.

Secțiunea C (secțiune de control, secțiune funcțională)

Tabelul 2.2 Codarea secțunii de control

Tabelul 2.3 prezintă codurile de funcții utilizate în apelurile și indicațiile de răspuns.

Nume Binarul din C Hex. Din C Telegramă Descriere

A field (secțiune de adresare)

CI field (secțiune informațională de control)