Un grup de FFU se manifestă ca o problemă de control cu mult înainte de a se manifesta ca o problemă legată de fluxul de aer. Odată ce unitățile sunt conectate în rețea la un gateway sau la un sistem de gestionare a clădirii, proiectul trebuie să răspundă la o întrebare diferită de “funcționează fiecare unitate?” — trebuie să răspundă la întrebarea “sistemul de control știe, fără niciun dubiu, care este fiecare unitate, cărei zone îi aparține și ce se întâmplă când apare o problemă?” O greșeală în acest sens nu se manifestă de obicei în timpul punerii în funcțiune a unei singure unități; ea apare mai târziu, când o alarmă semnalează o locație care nu mai corespunde planului de execuție sau când o comandă de zonă ajunge la un grup greșit de unități.

Asociați fiecare adresă FFU cu o locație fizică și o zonă de operare

Fiecare FFU dintr-o rețea are nevoie de o adresă, dar adresa în sine nu oferă sistemului de control nicio informație despre locul în care se află unitatea respectivă, despre ce ar trebui să facă sau de ce alte unități depinde pentru un răspuns coordonat. Adresa este un identificator de comunicare; corespondența dintre acest identificator și contextul fizic și funcțional este o informație separată care trebuie creată și menținută în mod deliberat. În cazul în care această corespondență nu există sub forma unui registru distinct, care poate fi consultat, logica de control și configurația reală a încăperii tind să se îndepărteze una de cealaltă în timp, mai ales pe măsură ce unitățile sunt înlocuite, recablate sau realocate într-o zonă diferită pe parcursul ciclului de viață al proiectului.

Maparea necesită cel puțin patru elemente asociate fiecărei adrese: locația fizică a unității, zona de funcționare din care face parte, controlerul căruia îi raportează și circuitul de alimentare care o alimentează. Fiecare dintre aceste elemente modifică interpretarea unui semnal provenit de la unitatea respectivă. Un semnal de stare provenit de la o unitate înseamnă un lucru dacă contextul zonei este cunoscut și altceva dacă nu este — o defecțiune raportată fără contextul zonei îi indică operatorului că ceva nu este în regulă, dar nu și ce înseamnă acea “anomalie” pentru procesul pe care zona îl protejează. În mod similar, cunoașterea circuitului de alimentare este importantă deoarece o unitate care nu mai transmite semnale din cauza unei probleme de cablare nu ar trebui diagnosticată sau tratată în același mod ca o unitate care nu mai transmite semnale din cauza unei probleme de comunicare, chiar dacă ambele pot părea identice din punct de vedere strict al stării.

Gruparea pe zone merită o atenție separată față de adresă. Două unități FFU pot împărți același spațiu fizic și totuși să aparțină unor zone de funcționare diferite, dacă susțin procese diferite, limite de calificare diferite sau cerințe diferite privind răspunsul la defecțiuni. În schimb, unitățile din încăperi adiacente pot aparține aceleiași zone de funcționare dacă se preconizează că vor răspunde împreună la o singură decizie de control. Alocarea zonelor ar trebui să urmeze procesul protejat, nu dispunerea fizică a conductelor sau a cablajului, deoarece dispunerea fizică reprezintă o facilitate de instalare, în timp ce alocarea zonelor este o decizie de control cu consecințe asupra modului în care sistemul se comportă în condiții normale de funcționare și în caz de defecțiune.

Înainte de începerea programării, acest registru de adresare — care conține locația, zona, controlerul și circuitul de alimentare pentru fiecare unitate fizică — trebuie să existe sub forma unui document pe care echipele de punere în funcțiune și de control să îl poată verifica, și nu ca informații reconstituite în mod informal pe baza desenelor tehnice sau a notelor de teren. Confirmarea existenței acestui registru și a faptului că este complet pentru fiecare unitate din grup reprezintă o condiție prealabilă pentru toate etapele ulterioare ale configurării sistemului de control.

Definiți comenzi, semnale de stare, alarme și puncte de tendință pentru fiecare interfață

Odată stabilite identitatea fiecărei unități și contextul zonei, următoarea decizie este ce anume trece efectiv prin interfața dintre sistemele de comandă ale FFU și sistemele din jurul acestora — controlerul unității, orice gateway și sistemul de gestionare a clădirii. De obicei, sunt necesare definiții explicite pentru patru categorii de informații: comenzile trimise către unități, semnalele de stare primite de la acestea, alarmele care necesită o reacție și valorile de tendință sau cele înregistrate, păstrate pentru o analiză ulterioară. Tratarea acestora ca un singur flux de date nediferențiat creează ambiguitate cu privire la semnificația fiecărui punct și la persoana care trebuie să ia măsuri în consecință.

Comenzile și semnalele de stare nu sunt imagini oglindite una față de cealaltă, chiar dacă adesea parcurg aceeași cale fizică. O comandă indică unei unități sau unei zone ce trebuie să facă; un semnal de stare raportează ceea ce se întâmplă efectiv. Atunci când un sistem de control le combină pe cele două — de exemplu, deducând că o comandă a fost executată cu succes în loc să o confirme printr-un punct de stare independent — un proiect își pierde capacitatea de a face distincția între “sistemul a solicitat acest lucru” și “sistemul a verificat că acest lucru s-a întâmplat”. Această distincție contează cel mai mult tocmai atunci când ceva a eșuat, moment în care distincția este cea mai greu de reconstituit după fapt, dacă nu a fost integrată încă de la început.

Alarmele necesită o definiție proprie, distinctă de starea obișnuită, deoarece o alarmă implică o reacție necesară, în timp ce un semnal de stare poate fi pur informativ. Condițiile care generează o alarmă, momentul din logica de control în care aceasta este declanșată și destinația către care este redirecționată sunt decizii specifice fiecărui proiect, care depind de modul în care procesul protejat răspunde la condiția de defect subiacentă. Punctele de tendință, la rândul lor, au un scop diferit: ele sunt păstrate pentru analiză ulterioară, mai degrabă decât pentru a se acționa în timp real, astfel încât valoarea lor depinde de ceea ce este înregistrat, la ce rezoluție și pentru cât timp, mai degrabă decât de un răspuns imediat.

Problema proprietății se regăsește în toate cele patru categorii. Pentru fiecare element — comandă, stare, alarmă sau tendință — proiectul trebuie să știe care sistem îl înregistrează, care sistem este de referință pentru acesta și la ce sistem trebuie să apeleze un verificator în cazul în care valoarea înregistrată este vreodată pusă sub semnul întrebării. Definirea acestui aspect la nivel de interfață, înainte de finalizarea schemei de control, evită situația în care același semnal pare să provină de la două sisteme, fără a exista o înțelegere comună cu privire la care dintre ele are prioritate.

Atribuiți drepturile de proprietate pentru controlerele de unitate, gateway-urile și sistemul de gestionare a clădirii (BMS)

O arhitectură de control cu un un controler de unitate, o poartă de comunicații și un sistem de gestionare a clădirii creează trei straturi, fiecare dintre ele putând revendica în mod plauzibil responsabilitatea pentru o anumită decizie sau pentru o anumită informație. Responsabilitatea trebuie atribuită în mod explicit, deoarece simpla existență a unei căi de date între straturi nu stabilește care strat are autoritate atunci când valorile nu coincid sau când trebuie emisă o comandă.

Controlerul unității este, de obicei, cel mai apropiat de echipamentul fizic și are o imagine cât se poate de imediată asupra stării sale reale de funcționare. Gateway-ul, acolo unde există, traduce și agregă informațiile între controlerul unității și BMS și, prin aceasta, introduce un punct în care datele pot fi întârziate, transformate sau pierdute dacă rolul său nu este clar delimitat. Sistemul BMS se află cel mai departe de unitatea fizică și are, de obicei, cea mai cuprinzătoare imagine de ansamblu asupra zonelor, dar această imagine de ansamblu este la fel de precisă pe cât sunt datele pe care le primește prin intermediul straturilor de sub el. Niciuna dintre aceste trei poziții nu este în mod automat cea “corectă” pentru a deține responsabilitatea unei anumite decizii; responsabilitatea corectă depinde de ceea ce necesită decizia — un răspuns fizic imediat favorizează asumarea responsabilității aproape de unitate, în timp ce coordonarea între zone favorizează asumarea responsabilității la nivelul sistemului BMS.

În cazul în care atribuirea autorității rămâne implicită, un sistem de control poate manifesta un comportament contradictoriu: o comandă emisă la nivelul BMS ar putea fi anulată local la nivelul controlerului unității fără ca această anulare să fie înregistrată, sau o poartă de comunicație ar putea stoca temporar o schimbare de stare suficient de mult timp încât BMS să acționeze pe baza unor informații învechite. Niciunul dintre aceste moduri de defectare nu presupune funcționarea defectuoasă a vreunei componente — ambele pot apărea chiar dacă fiecare componentă funcționează exact conform proiectării, pur și simplu deoarece atribuirea autorității nu a fost niciodată explicită pentru acel punct de date sau acea cale de comandă.

Atribuirea responsabilității implică, de asemenea, stabilirea modului în care se procedează atunci când straturile sunt în contradicție — dacă are prioritate citirea locală a controlerului unității, dacă gateway-ul are permisiunea de a substitui o valoare implicită atunci când nu poate comunica cu unitatea și dacă sistemul de gestionare a clădirii (BMS) afișează o valoare pe care nu o poate verifica el însuși. Aceste decizii își au locul în schema de control, alături de registrul de adresare și de definițiile punctelor, deoarece ele determină modul în care se comportă restul sistemului odată ce fluxul de date se desfășoară corect.

Specificați comportamentul zonei în cazul defecțiunilor de comunicații, de alimentare și ale unității

Adresarea, definițiile punctelor și atribuirea proprietății descriu modul în care sistemul ar trebui să se comporte în condiții normale. Comportamentul în caz de defecțiune constituie o specificație separată și nu poate fi dedus automat din logica de funcționare normală — un sistem care funcționează corect atunci când toate componentele comunică între ele nu are, prin urmare, un comportament definit pentru situațiile în care o unitate încetează să mai comunice, rămâne fără alimentare sau devine indisponibilă din orice alt motiv.

Trei tipuri de defecțiuni apar frecvent în cadrul grupurilor de FFU: pierderea comunicării cu o unitate, întreruperea alimentării cu energie a unei unități și o unitate care pur și simplu nu este disponibilă din alte motive. Fiecare dintre acestea are o cauză diferită, iar tratarea lor ca fiind interschimbabile generează un răspuns de control care poate fi inadecvat pentru cel puțin una dintre ele. O pierdere a comunicării nu înseamnă neapărat că ventilatorul a încetat să mai circule aerul; o întrerupere a alimentării cu energie electrică înseamnă aproape sigur acest lucru; iar o unitate semnalată ca fiind indisponibilă prin intermediul unui alt mecanism poate corespunde sau nu unei modificări efective a fluxului de aer. Deoarece consecința fizică diferă în aceste trei cazuri, răspunsul programat al zonei nu ar trebui să adopte în mod implicit un comportament identic pentru toate cele trei situații doar pentru că toate sunt considerate “defecțiuni” din punctul de vedere al sistemului de control.

Comportamentul corect al zonei pentru fiecare defecțiune depinde de procesul pe care îl protejează zona și de propria evaluare a riscurilor efectuată la fața locului, nu de o setare implicită generală valabilă pentru fiecare proiect. În cazul în care o zonă protejează un proces care nu poate tolera nicio întrerupere a fluxului coordonat de aer, pierderea comunicării unei singure unități poate necesita declanșarea unei alarme imediate la nivel de zonă și a unei comenzi de rezervă definite către unitățile rămase, chiar înainte de confirmarea cauzei care stă la baza problemei. În cazul în care zona protejează un proces mai puțin sensibil, aceeași pierdere a comunicării ar putea fi gestionată printr-o alarmă întârziată, care oferă timp suficient pentru a distinge o problemă tranzitorie a rețelei de o defecțiune reală a unității, evitând astfel o reacție inutilă la nivel de zonă față de o situație care se rezolvă de la sine. Niciuna dintre aceste abordări nu este universal corectă; fiecare reprezintă o decizie care depinde de procesul protejat și de consecințele unei reacții false în comparație cu cele ale unei reacții întârziate.

Tot aici, decizia de zonare a proiectului, luată anterior în momentul asociării adreselor cu zonele de operare, determină domeniul de aplicare al răspunsului la defecțiuni. O defecțiune într-o unitate alocată unei zone strict delimitate nu ar trebui să propage automat un răspuns către unitățile dintr-o zonă adiacentă, cu excepția cazului în care procesul în sine necesită un comportament coordonat peste acea graniță. Specificarea explicită a acestui domeniu de aplicare, pentru fiecare dintre cele trei tipuri de defecțiuni, este ceea ce permite programului de control să stabilească un răspuns definit, în loc să lase comportamentul real să fie descoperit abia atunci când apare o defecțiune în timpul funcționării.

Verificați adresarea, rutarea alarmelor și datele înregistrate în momentul recepției la fața locului

Fiecare decizie luată anterior — registrul de adrese, definițiile punctelor, atribuirea drepturilor de proprietate și comportamentul în caz de defecțiune — există pe hârtie sub forma schemei de control aprobate până când este verificată în raport cu sistemul instalat. Acceptarea amplasamentului este momentul în care se confirmă că ceea ce a fost specificat corespunde cu ceea ce a fost efectiv construit și programat, iar această verificare trebuie efectuată punct cu punct, fără a se pleca de la presupunerea că sistemul pare să funcționeze.

Verificarea adresării înseamnă confirmarea faptului că adresa fiecărei unități FFU fizice, așa cum este raportată de sistemul de control, corespunde efectiv locației, zonei, controlerului și circuitului de alimentare înregistrate în registru. Această verificare este necesară deoarece activitățile de instalare și punere în funcțiune — refacerea cablajului, înlocuirea unităților sau reetichetarea — pot perturba în mod imperceptibil corespondența dintre o unitate fizică și identitatea sa înregistrată, fără a produce vreun simptom vizibil până în momentul în care o alarmă sau o comandă este direcționată greșit.

Verificarea comenzilor de zonă înseamnă testarea faptului că o comandă transmisă către o anumită zonă ajunge efectiv la unitățile asociate acelei zone și este executată de acestea, și numai de acestea. Acest lucru confirmă faptul că decizia de împărțire în zone luată în etapa de asociere a adreselor a fost transpusă corect în logica programată, și nu doar consemnată.

Verificarea rutării alarmelor înseamnă testarea faptului că traseele de alarmă definite anterior — adică ce condiții generează o alarmă și pe ce traseu este dirijată acea alarmă între sistemele de control ale FFU și BMS — se comportă conform specificațiilor în condiții de testare, nu doar în condiții normale de funcționare. Un traseu de alarmă care nu a fost niciodată testat nu oferă nicio garanție că va funcționa corect atunci când apare o defecțiune reală, întrucât modul de defectare al unui traseu de alarmă este adesea ascuns, nu evident.

Verificarea valorilor înregistrate înseamnă verificarea faptului că tendința și datele înregistrate disponibile la interfața dintre sistemele de control ale FFU și BMS corespund cu ceea ce a specificat programul de control — punctele corecte, din sursa corectă, păstrate într-o formă pe care un verificator o poate consulta ulterior. Acest lucru închide bucla înapoi la atribuirea responsabilității, deoarece o valoare înregistrată este utilă doar dacă sursa sa oficială a fost stabilită în prealabil. Confirmarea acestor patru aspecte în raport cu programul de control aprobat, în această etapă, este ceea ce permite proiectului să trateze comportamentul sistemului de control ca fiind stabilit, și nu doar presupus, pe viitor.

Întrebări frecvente

Q: Ce trebuie rezolvat înainte de începerea adresării finale a unităților FFU?
A: Stabiliți identificatorul locației fizice, zona de funcționare, controlerul și relația cu circuitul de alimentare pentru fiecare unitate din registrul de adresare. Dacă vreuna dintre aceste alocări este încă în curs de modificare, mențineți adresele afectate ca provizorii până la stabilirea definitivă a configurației; în caz contrar, o remapare ulterioară poate duce la deconectarea rutelor de alarmă și a înregistrărilor de acceptare de la unitatea instalată.

Q: Este necesar ca fiecare punct de control FFU să fie transmis către sistemul de gestionare a clădirii (BMS)?
A: Nu. Selectați comenzile, semnalele de stare, alarmele și valorile de tendință necesare pentru planul de operare și monitorizare a amplasamentului, apoi înregistrați sursa, destinația și proprietarul fiecărui punct selectat. O interfață a cărei proprietate nu este clară poate determina atât echipa responsabilă de controlul FFU, cât și echipa BMS să presupună că cealaltă parte se va ocupa de configurarea sau verificarea acesteia.

Q: Cum ar trebui proiectul să aleagă comportamentul zonei în cazul unei defecțiuni la nivel de comunicații, alimentare sau unitate?
A: Stabiliți răspunsul pentru fiecare tip de defecțiune pe baza procesului de protecție și a evaluării riscurilor la fața locului și consemnați separat comportamentul preconizat al zonei în planul de control aprobat. Utilizați o singură soluție de rezervă comună numai în cazul în care proiectul a stabilit că diferitele defecțiuni au aceeași consecință; în caz contrar, răspunsul prevăzut poate fi ascuns până la testarea de acceptare.

Q: Ce aspecte trebuie stabilite între furnizorul de sisteme de control și integratorul BMS înainte de întocmirea ofertei?
A: Furnizați registrul de adresare și lista punctelor de interfață, apoi atribuiți proprietatea pentru fiecare comandă, semnal de stare, alarmă și valoare de tendință la nivelul controlerului unității, al gateway-ului și al sistemului BMS. Rezolvați problema punctelor nealocate și stabiliți comportamentul necesar în caz de defecțiune înainte de finalizarea definiției domeniului de aplicare și a stabilirii prețurilor, astfel încât lucrările de punere în funcțiune să nu rămână în sarcina altor pachete.

Q: Cum poate un cumpărător să evite o tranzacție aparent reușită, care ascunde o eroare de integrare a controlului?
A: Utilizați schema de control aprobată ca bază de acceptare și testați corespondența adreselor fizice, comenzile de zonă, traseele de alarmă și valorile înregistrate de la un capăt la altul. Înregistrați rezultatul așteptat și cel observat pentru fiecare verificare; un răspuns în timp real nu este suficient atunci când adresa, destinația sau valoarea stocată nu corespund schemei aprobate.