Grupa FFU przedstawia się jako problem sterowania na długo przed tym, zanim stanie się problemem przepływu powietrza. Gdy urządzenia zostaną podłączone do bramy sieciowej lub systemu zarządzania budynkiem, projekt musi odpowiedzieć na inne pytanie niż “czy każde urządzenie działa?” — musi odpowiedzieć na pytanie “czy system sterowania wie jednoznacznie, które urządzenie jest które, do której strefy należy i co się dzieje, gdy coś pójdzie nie tak?”. Błąd w tym zakresie zazwyczaj nie ujawnia się podczas uruchamiania pojedynczego urządzenia; pojawia się później, gdy alarm sygnalizuje lokalizację, która nie odpowiada już układowi zgodnemu z dokumentacją powykonawczą, lub gdy polecenie strefowe dociera do niewłaściwej grupy urządzeń.

Należy przyporządkować każdy adres FFU do konkretnej lokalizacji fizycznej i strefy operacyjnej

Każda jednostka FFU w sieci wymaga adresu, ale sam adres nie dostarcza systemowi sterowania żadnych informacji o tym, gdzie znajduje się dana jednostka, jakie ma zadania do wykonania ani od jakich innych jednostek jest zależna w celu zapewnienia skoordynowanej reakcji. Adres jest identyfikatorem komunikacyjnym; powiązanie między tym identyfikatorem a kontekstem fizycznym i funkcjonalnym stanowi odrębną informację, którą należy celowo tworzyć i utrzymywać. Tam, gdzie takie powiązanie nie istnieje w postaci odrębnego, dostępnego do odwołania rejestru, logika sterowania i rzeczywisty układ pomieszczeń mają tendencję do rozbiegania się w miarę upływu czasu, zwłaszcza gdy urządzenia są wymieniane, ponownie okablowywane lub przypisywane do innej strefy w trakcie cyklu życia projektu.

Mapowanie wymaga przypisania do każdego adresu co najmniej czterech elementów: fizycznej lokalizacji urządzenia, strefy operacyjnej, do której należy, sterownika, któremu podlega, oraz obwodu zasilającego, z którego czerpie energię. Każdy z tych elementów wpływa na interpretację sygnału pochodzącego z danego urządzenia. Sygnał stanu z urządzenia oznacza jedną rzecz, jeśli znany jest kontekst strefy, a inną, jeśli nie jest — zgłoszona awaria bez kontekstu strefy informuje operatora, że coś jest nie tak, ale nie wyjaśnia, co to “nie tak” oznacza dla procesu, który chroni dana strefa. Podobnie znajomość obwodu zasilającego ma znaczenie, ponieważ urządzenie, które przestaje działać z powodu usterki okablowania, nie powinno być diagnozowane ani traktowane w taki sam sposób jak urządzenie, które przestaje działać z powodu usterki komunikacyjnej, nawet jeśli z punktu widzenia samego statusu oba mogą wyglądać identycznie.

Samo grupowanie strefowe zasługuje na odrębną uwagę, niezależną od adresu. Dwa urządzenia FFU mogą znajdować się w tym samym pomieszczeniu fizycznym, a mimo to należeć do różnych stref operacyjnych, jeśli obsługują różne procesy, mają różne granice kwalifikacyjne lub różne wymagania dotyczące reakcji na awarie. Z drugiej strony urządzenia w sąsiednich pomieszczeniach mogą należeć do tej samej strefy operacyjnej, jeśli oczekuje się, że będą wspólnie reagować na jedną decyzję sterującą. Przypisanie do strefy powinno opierać się na chronionym procesie, a nie na fizycznym układzie kanałów wentylacyjnych czy okablowania, ponieważ układ fizyczny służy jedynie wygodzie realizacji, podczas gdy przypisanie do strefy jest decyzją sterującą mającą wpływ na zachowanie systemu zarówno podczas normalnej pracy, jak i w przypadku awarii.

Przed rozpoczęciem programowania ten rejestr adresowy — zawierający informacje o lokalizacji, strefie, sterowniku i obwodzie zasilającym dla każdego fizycznego urządzenia — musi istnieć w formie dokumentu, z którym zespoły odpowiedzialne za uruchomienie i sterowanie mogą się zapoznać, a nie jako informacje odtworzone nieformalnie na podstawie rysunków lub notatek terenowych. Potwierdzenie, że rejestr ten istnieje i że jest kompletny dla każdego urządzenia w grupie, stanowi warunek wstępny dla wszystkich dalszych czynności związanych z konfiguracją sterowania.

Zdefiniuj polecenia, sygnały stanu, alarmy i punkty trendu dla każdego interfejsu

Gdy tożsamość każdej jednostki i kontekst strefy zostaną ustalone, kolejną decyzją jest określenie, co faktycznie przepływa przez interfejs między elementami sterującymi modułu FFU a otaczającymi je systemami — sterownik urządzenia, dowolna bramka oraz system zarządzania budynkiem. Zazwyczaj konieczne jest jednoznaczne zdefiniowanie czterech kategorii informacji: poleceń wysyłanych do urządzeń, sygnałów stanu zwracanych przez nie, alarmów wymagających reakcji oraz wartości trendów lub wartości zarejestrowanych, przechowywanych do późniejszego przeglądu. Traktowanie tych elementów jako jednego, niepodzielonego strumienia danych powoduje niejasność co do znaczenia poszczególnych punktów oraz tego, kto powinien podjąć odpowiednie działania w związku z nimi.

Polecenia i sygnały stanu nie są lustrzanymi odbiciami siebie nawzajem, mimo że często przechodzą tę samą fizyczną ścieżkę. Polecenie informuje urządzenie lub strefę, co ma zrobić; sygnał stanu informuje o tym, co faktycznie się dzieje. W przypadku gdy system sterowania łączy te dwa elementy — na przykład poprzez wnioskowanie, że polecenie zostało pomyślnie wykonane, zamiast potwierdzać to za pomocą niezależnego punktu stanu — projekt traci możliwość rozróżnienia między “system o to poprosił” a “system zweryfikował, że to się wydarzyło”. To rozróżnienie ma największe znaczenie właśnie wtedy, gdy coś zawiodło, a jest to moment, w którym najtrudniej jest je odtworzyć po fakcie, jeśli nie zostało wbudowane od samego początku.

Alarmy wymagają odrębnej definicji, niezależnej od zwykłego stanu, ponieważ alarm oznacza konieczność podjęcia odpowiednich działań, podczas gdy sygnał stanu może mieć charakter wyłącznie informacyjny. To, jakie warunki powodują wygenerowanie alarmu, w którym momencie logiki sterowania alarm ten jest uruchamiany oraz dokąd jest kierowany – to wszystko są decyzje specyficzne dla danego projektu, zależne od tego, jak chroniony proces reaguje na występujący stan awarii. Z kolei punkty trendu służą z kolei zupełnie innemu celowi: są one przechowywane do celów analizy, a nie wykorzystywane do podejmowania działań w czasie rzeczywistym, więc ich wartość zależy od tego, co jest rejestrowane, z jaką rozdzielczością i przez jak długi czas, a nie od natychmiastowej reakcji.

Kwestia własności przewija się we wszystkich czterech kategoriach. W odniesieniu do każdego punktu — polecenia, stanu, alarmu lub trendu — w ramach projektu należy ustalić, który system go rejestruje, który system jest dla niego wiążący oraz do którego systemu powinien zwrócić się osoba weryfikująca, gdyby kiedykolwiek pojawiły się wątpliwości co do zarejestrowanej wartości. Określenie tego na poziomie interfejsu, przed sfinalizowaniem harmonogramu sterowania, pozwala uniknąć sytuacji, w której ten sam sygnał wydaje się pochodzić z dwóch systemów, przy czym nie ma uzgodnionego zapisu określającego, który z nich ma charakter wiążący.

Przypisz uprawnienia do kontrolerów urządzeń, bram sieciowych i systemu zarządzania budynkiem (BMS)

Architektura sterowania z sterownik urządzenia, bramka oraz system zarządzania budynkiem tworzy trzy warstwy, z których każda może w uzasadniony sposób przypisywać sobie odpowiedzialność za daną decyzję lub dany element danych. Odpowiedzialność musi zostać przypisana w sposób wyraźny, ponieważ samo istnienie ścieżki danych między warstwami nie pozwala ustalić, która warstwa ma charakter rozstrzygający w przypadku rozbieżności wartości lub konieczności wydania polecenia.

Sterownik urządzenia znajduje się zazwyczaj najbliżej fizycznego sprzętu i ma najbardziej bezpośredni wgląd w jego rzeczywisty stan pracy. Bramka, o ile istnieje, przekształca i agreguje informacje między sterownikiem urządzenia a systemem BMS, a tym samym stanowi punkt, w którym dane mogą ulec opóźnieniu, przekształceniu lub utracie, jeśli jej rola nie jest jasno określona. System BMS znajduje się najdalej od fizycznego urządzenia i zazwyczaj ma najszerszy ogląd sytuacji w poszczególnych strefach, ale ten szeroki ogląd jest tak dokładny, jak dane, które otrzymuje przez niższe warstwy. Żadna z tych trzech pozycji nie jest automatycznie “właściwą” do podjęcia konkretnej decyzji; właściwy podmiot zależą od tego, czego wymaga dana decyzja — natychmiastowa reakcja fizyczna przemawia za podjęciem decyzji na poziomie bliskim urządzenia, podczas gdy koordynacja między strefami przemawia za podjęciem decyzji na poziomie systemu BMS.

W przypadku gdy przynależność nie jest wyraźnie określona, system sterowania może wykazywać sprzeczne zachowania: polecenie wydane na poziomie systemu BMS może zostać lokalnie nadpisane w sterowniku urządzenia bez pozostawienia śladu tego nadpisania, lub brama może buforować zmianę stanu na tyle długo, że system BMS podejmuje działania na podstawie nieaktualnych informacji. Żaden z tych trybów awarii nie wymaga nieprawidłowego działania jakiegokolwiek pojedynczego komponentu — oba mogą wystąpić, nawet jeśli każdy komponent działa dokładnie zgodnie z projektem, po prostu dlatego, że przypisanie uprawnień nigdy nie zostało wyraźnie określone dla danego punktu danych lub danej ścieżki poleceń.

Przypisanie odpowiedzialności oznacza również podjęcie decyzji dotyczących sytuacji, w których warstwy nie są ze sobą zgodne — czy decydujące znaczenie mają lokalne odczyty kontrolera urządzenia, czy bramka może podstawić wartość domyślną w przypadku braku łączności z urządzeniem oraz czy system BMS wyświetla wartość, której nie jest w stanie samodzielnie zweryfikować. Decyzje te powinny znaleźć się w schemacie sterowania obok rejestru adresowania i definicji punktów, ponieważ określają one sposób działania pozostałej części systemu po ustanowieniu prawidłowego przepływu danych.

Określ sposób działania strefy w przypadku awarii komunikacji, zasilania i urządzenia

Adresowanie, definicje punktów oraz przypisania własności opisują, jak system powinien zachowywać się w normalnych warunkach. Zachowanie w przypadku awarii stanowi odrębną specyfikację i nie można go automatycznie wywnioskować z logiki działania w trybie normalnym — system, który działa poprawnie, gdy wszystkie elementy komunikują się ze sobą, nie ma z tego powodu zdefiniowanego zachowania na wypadek, gdyby jakiś element przestał się komunikować, utracił zasilanie lub z innych powodów stał się niedostępny.

W grupach FFU powtarzają się trzy rodzaje awarii: utrata łączności z urządzeniem, brak zasilania urządzenia oraz sytuacja, w której urządzenie jest po prostu niedostępne z jakiegoś innego powodu. Każda z nich ma inną przyczynę, a traktowanie ich jako zamiennych prowadzi do reakcji systemu sterowania, która może być nieodpowiednia przynajmniej w jednym z tych przypadków. Utrata łączności niekoniecznie oznacza, że wentylator przestał cyrkulować powietrze; utrata zasilania prawie na pewno to oznacza; natomiast zgłoszona niedostępność urządzenia za pośrednictwem innego mechanizmu może, ale nie musi, odpowiadać rzeczywistej zmianie w przepływie powietrza. Ponieważ fizyczne konsekwencje różnią się w tych trzech przypadkach, zaprogramowana reakcja strefy nie powinna domyślnie przyjmować identycznego zachowania dla wszystkich trzech sytuacji tylko dlatego, że z punktu widzenia systemu sterowania wszystkie one są “usterkami”.

Prawidłowe zachowanie strefy w przypadku każdej usterki zależy od procesu, który strefa chroni, oraz od własnej oceny ryzyka danego obiektu, a nie od ogólnego ustawienia domyślnego, które miałoby pasować do każdego projektu. W przypadku gdy strefa chroni proces, który nie toleruje żadnej przerwy w skoordynowanym przepływie powietrza, utrata łączności z pojedynczym urządzeniem może wymagać natychmiastowego uruchomienia alarmu na poziomie strefy oraz wydania zdefiniowanego polecenia awaryjnego do pozostałych urządzeń, nawet przed potwierdzeniem przyczyny zdarzenia. W przypadku gdy strefa chroni proces mniej wrażliwy, tę samą utratę łączności można obsłużyć za pomocą opóźnionego alarmu, który daje czas na odróżnienie przejściowego problemu sieciowego od rzeczywistej awarii urządzenia, unikając w ten sposób niepotrzebnej reakcji całej strefy na sytuację, która rozwiązuje się sama. Żadne z tych podejść nie jest uniwersalnie poprawne; każde z nich stanowi decyzję, która zależy od chronionego procesu oraz konsekwencji fałszywej reakcji w porównaniu z opóźnioną reakcją.

To właśnie w tym miejscu decyzja dotycząca podziału na strefy, podjęta wcześniej podczas przypisywania adresów do stref operacyjnych, określa zakres reakcji na awarię. Usterka w jednostce przypisanej do ściśle wyodrębnionej strefy nie powinna automatycznie powodować rozprzestrzenienia się reakcji na jednostki w sąsiedniej strefie, chyba że sam proces wymaga skoordynowanego działania ponad tą granicą. Wyraźne określenie tego zakresu dla każdego z trzech typów usterek pozwala harmonogramowi sterowania zdefiniować konkretną reakcję, zamiast pozostawiać ustalenie rzeczywistego zachowania dopiero w momencie wystąpienia usterki podczas pracy.

Podczas odbioru obiektu należy sprawdzić adresowanie, trasowanie alarmów oraz zarejestrowane dane

Każda podjęta wcześniej decyzja — rejestr adresów, definicje punktów, przypisania własności oraz zachowanie w przypadku awarii — istnieje w formie papierowej jako zatwierdzony schemat sterowania, dopóki nie zostanie zweryfikowana w odniesieniu do zainstalowanego systemu. Odbiór obiektu jest to etap, na którym w ramach projektu potwierdza się, że to, co zostało określone w specyfikacji, faktycznie zostało zbudowane i zaprogramowane, a weryfikacja ta musi być przeprowadzana punkt po punkcie, a nie oparta na założeniu, że system wydaje się działać.

Weryfikacja adresowania polega na potwierdzeniu, że adres każdej fizycznej jednostki FFU, zgłoszony przez system sterowania, faktycznie odpowiada lokalizacji, strefie, sterownikowi i obwodowi zasilającemu zapisanym w rejestrze. Kontrola ta jest konieczna, ponieważ czynności związane z instalacją i uruchomieniem — zmiana okablowania, wymiana urządzenia lub zmiana oznaczeń — mogą w sposób niezauważalny zakłócić powiązanie między fizycznym urządzeniem a jego zarejestrowaną tożsamością, nie powodując żadnych widocznych objawów, dopóki alarm lub polecenie nie zostanie skierowane do niewłaściwego miejsca.

Weryfikacja poleceń strefowych polega na sprawdzeniu, czy polecenie wydane dla danej strefy faktycznie dociera do jednostek przypisanych do tej strefy i czy są one przez nie wykonywane, przy czym dotyczy to wyłącznie tych jednostek. Potwierdza to, że decyzja dotycząca podziału na strefy, podjęta na etapie mapowania adresów, została prawidłowo wdrożona w zaprogramowanej logice, a nie tylko odnotowana na papierze.

Weryfikacja trasy alarmowej polega na sprawdzeniu, czy wcześniej zdefiniowane ścieżki alarmowe — czyli warunki wywołujące alarm oraz sposób jego przekazywania między sterownikami FFU a systemem BMS — działają zgodnie z założeniami nie tylko w normalnych warunkach pracy, ale również w warunkach testowych. Ścieżka alarmowa, która nigdy nie została przetestowana, nie daje pewności, że alarm zostanie poprawnie przekazany w przypadku wystąpienia rzeczywistej usterki, ponieważ awarie ścieżek alarmowych często przebiegają bez widocznych objawów, a nie w sposób oczywisty.

Weryfikacja zarejestrowanych wartości polega na sprawdzeniu, czy tendencja oraz dane zarejestrowane dostępne na styku układów sterowania FFU i systemu BMS są zgodne z tym, co określono w harmonogramie sterowania — czy są to właściwe punkty pomiarowe, pochodzące z właściwego źródła i zachowane w formie umożliwiającej późniejszą analizę przez osobę sprawdzającą. W ten sposób zamyka się pętlę powracającą do przypisania odpowiedzialności, ponieważ zarejestrowana wartość ma znaczenie tylko wtedy, gdy jej wiarygodne źródło zostało ustalone z wyprzedzeniem. Potwierdzenie tych czterech obszarów w odniesieniu do zatwierdzonego harmonogramu sterowania na tym etapie pozwala projektowi traktować działanie systemu sterowania w przyszłości jako ustalone, a nie jako założone.

Często zadawane pytania

Q: Co należy naprawić przed rozpoczęciem ostatecznego przypisywania adresów do jednostek FFU?
A: W rejestrze adresowania należy ustalić identyfikator fizycznej lokalizacji, strefę działania, sterownik oraz powiązania obwodów zasilających dla każdego urządzenia. Jeśli którekolwiek z tych przyporządkowań ulegają jeszcze zmianom, należy traktować odnośne adresy jako tymczasowe do czasu ostatecznego ustalenia układu; w przeciwnym razie późniejsze zmiana mapowania może spowodować odłączenie tras alarmowych i dokumentacji odbiorczej od zainstalowanego urządzenia.

Q: Czy dane z każdego punktu kontrolnego FFU muszą być przesyłane do systemu BMS?
A: Nie. Należy wybrać polecenia, sygnały stanu, alarmy i wartości trendów niezbędne do realizacji planu eksploatacji i monitorowania obiektu, a następnie odnotować źródło, miejsce docelowe oraz właściciela każdego wybranego punktu. Interfejs o niejasnej przynależności może sprawić, że zarówno zespół odpowiedzialny za sterowanie jednostkami FFU, jak i zespół BMS będą zakładać, że to druga strona zajmie się jego konfiguracją lub weryfikacją.

Q: W jaki sposób w ramach projektu należy dobrać sposób działania strefy w przypadku awarii systemu komunikacyjnego, zasilania lub urządzenia?
A: Należy określić sposób reagowania na każdy rodzaj awarii na podstawie oceny ryzyka chronionego procesu i obiektu, a także oddzielnie odnotować przewidywane zachowanie strefy w zatwierdzonym harmonogramie sterowania. Należy stosować jedno wspólne rozwiązanie awaryjne tylko wtedy, gdy w ramach projektu ustalono, że różne awarie mają takie same konsekwencje; w przeciwnym razie zamierzony sposób reagowania może pozostać nieujawniony aż do momentu przeprowadzenia testów odbiorczych.

Q: Jakie kwestie należy uzgodnić między dostawcą elementów sterujących a integratorem systemu BMS przed sporządzeniem oferty?
A: Należy dostarczyć rejestr adresowy oraz listę punktów interfejsu, a następnie przypisać właścicieli dla każdego polecenia, sygnału stanu, alarmu i wartości trendu w kontrolerze urządzenia, bramce i systemie BMS. Należy rozwiązać kwestię nieprzypisanych punktów oraz określić wymagane zachowanie w przypadku awarii przed ostatecznym ustaleniem zakresu prac i wyceny, tak aby prace związane z uruchomieniem nie zostały rozdzielone między poszczególne pakiety.

Q: W jaki sposób nabywca może uniknąć pozornie pomyślnej transakcji, za którą kryje się błąd w zakresie integracji kontroli?
A: Należy wykorzystać zatwierdzony harmonogram sterowania jako podstawę odbioru i przetestować mapowanie adresów fizycznych, polecenia strefowe, ścieżki alarmowe oraz zarejestrowane wartości w całym systemie. Należy zapisać oczekiwane i zaobserwowane wyniki dla każdego sprawdzenia; sama reakcja systemu w czasie rzeczywistym nie jest wystarczająca, gdy adres, miejsce docelowe lub zapisana wartość nie są zgodne z zatwierdzonym harmonogramem.