Michał Zalewski
Słowo „integracja” jest ostatnio tak samo modne, jak określenia: inteligentny budynek, Internet Rzeczy. Temat jest obszerny, sedno integracji i sposoby jej wdrażania można opisywać bez końca. Postaram się omówić pokrótce podstawową moim zdaniem fazę procesu integracji, a mianowicie projektowanie.
Należałoby zacząć od odpowiedzi na pytanie, co to w zasadzie jest owa integracja. Przeszukując zakamarki Internetu, nie znalazłem takowej, w mojej świadomości inżyniera też żadna jednoznaczna definicja się nie utrwaliła. Czy można więc omawiać coś, co jest niezdefiniowane? O tym, że normy i np. warunki techniczne w ogóle tego pojęcia nie określają, już nawet nie wspomnę. Skoro zdecydowałem się temat poruszyć, czuję się też zobowiązany do zaproponowania swojej definicji. Oto owoc moich przemyśleń:
Integracja dwóch niezależnych systemów to takie ich połączenie, dzięki któremu osiągamy dodatkowe funkcjonalności niedostępne dla systemów niezintegrowanych.
Słowo „dodatkowe” jest moim zdaniem kluczowe w tej definicji. Jeżeli dzięki integracji nie osiągamy dodatkowych funkcjonalności, należy zastanowić się nad używaniem tego słowa w dokumentacji projektowej. Być może wtedy okaże się, że mamy do czynienia z fanaberią. Sformułowanie: „integracja pojawia się w dokumentacji” nie jest przejęzyczeniem. Jakże często jedynym miejscem, w którym definiuje się w dokumentacji zakres i poziom integracji, jest właśnie taki zapis: system X należy zintegrować z systemem Y i na tym koniec! I radź sobie, wykonawco. Dlaczego tak się dzieje? Według mnie z dwóch powodów. Jednego bardzo smutnego: osoba, która to napisała, nie ma pojęcia, o czym mówi. Uważa, że wystarczy magiczny zapis i wszystko samo się jakoś wymyśli. Drugi powód, trochę mniej smutny, to brak czasu lub nie do końca sprecyzowane oczekiwania przyszłego użytkownika.
Projektant, który podejmuje się zaprojektowania integracji systemów, niezależnie od fazy projektu, musi przede wszystkim wykazać się ogromną wiedzą na temat systemów, które zamierza zintegrować, a także umiejętnością wsparcia dla przyszłego użytkownika w specyfikacji oczekiwań. Zadanie to idealnie wpisuje się w podejście znane ze zręcznych technik zarządzania projektami IT: to programista określa użytkownikowi funkcjonalność, jaką on otrzyma. Gdy to po raz pierwszy usłyszałem, byłem zaskoczony, ale teraz uważam, że jest w nim sporo sensu.
Gigantyczny rozwój technologii informatycznych powoduje, że nawet najlepiej technicznie przygotowany użytkownik nie jest w stanie optymalnie określić swoich oczekiwać. Rola projektanta z tego zakresu jest zatem ogromna, pomaga precyzyjna znajomość budynku, świadomość potrzeb operacyjnych użytkownika, a przede wszystkim znajomość systemów, od których jesteśmy zależni lub na które chcemy wpływać dzięki integracji.
Niby proste, tylko jak to zrobić? Jest kilka kroków koniecznych do wykonania, które zaprowadzą nas do celu. Zacznijmy od tego, że projektant musi uświadomić sobie, że tematem trzeba się dokładnie, dogłębnie zająć, nie wolno poprzestać na jednym zdaniu-sloganie w części opisowej, które przytoczyłem wyżej. Kto ograniczy się do takich zapisów albo – co gorsze, ale też spotykane – narysuje kreskę łączącą na schemacie blokowym dwa niezależne systemy i uważa, że to oznacza ich integrację, musi zdawać sobie sprawę, że pakuje projekt w poważne kłopoty. I każdy, kto zaakceptuje takie zapisy (inwestor, główny projektant, nadzór), podobnie wprowadza projekt na drogę do problemów. Zakwestionowanie wykonania umowy przez wykonawcę jest najmniejszą z możliwych konsekwencji.
Opisałem w poprzednim artykule przykład o integracji wind z systemem kontroli dostępu. Zapraszam przy okazji do lektury, przypomnę jedną uwagę w nim zamieszczoną: nieodpowiedni dobór producentów systemów, które będziemy integrowali, może nawet uniemożliwić osiągnięcie celów integracji. To jest fakt, który dobitnie dowodzi, że tematem integracji należy zająć się dogłębnie już w fazie wstępnego doboru urządzeń i systemów. Jeżeli projektant będzie rzeczywiście przekonany o wadze tematu, nie zadowoli się lakoniczną informacją w opisie, to oznacza, że zaczęliśmy zbliżać się do sukcesu. Z tej wewnętrznej motywacji projektanta powinna wyłonić się konieczność zadawania pytań, by uzyskać od zamawiającego i jego służb technicznych jak najwięcej informacji operacyjnych i funkcjonalnych. Pomaga również zapoznanie się z innymi obiektami zamawiającego, rozmowa ze służbami technicznymi, ustalenie, co działa dobrze, a z czym mają problemy. Ta faza, odpowiednio wcześnie rozpoczęta, na pewno spotka się z wielkim oporem: Już teraz mam zastawiać się, jak będą działały służby ochrony? Nawet nie zaczęliśmy wykopów pod fundamenty, a pytacie mnie o integrację systemów? Napiszcie w koncepcji, że mają być zintegrowane, potem się wymyśli.
Takie słowa usłyszymy na 99 proc. Ale musimy zadawać pytania po to, by przypominać, że temat jest ważny. Gdy po raz pierwszy będziemy o to pytali, osoba w przyszłości odpowiedzialna za eksploatację budynku w projekcie nawet nie istnieje. I teraz musi „wejść do gry” doświadczony inżynier, który opracuje zręby rozwiązań, będzie potrafił określić elementy konieczne do ustalenia już na początku i takie, które można dookreślić później. Ważne, by opracować listę parametrów integracji. Z pewnością będzie się ona zmieniała w trakcie dopracowywania kolejnych elementów, ale finalnie będzie idealną check-listą do weryfikacji wykonania zadania. A że warto o to zadbać, postaram się uzasadnić kilkoma przykładami.
Integracja lokalnych sterowników urządzeń klimatyzacji w pomieszczeniach z nadrzędnym systemem BMS
Można zaprojektować pełną integrację opartą na protokołach komunikacyjnych – rozwiązanie maksymalnie bogate, ale po pierwsze kosztowne, bo narzucające konieczność wyposażenia wszystkich sterowników w karty komunikacyjne, po drugie uruchomieniowo wymagające odpowiednio skoordynowanego programowania po stronie zarówno urządzeń, jak i systemu nadrzędnego. A finalnie może się okazać, że użytkownikowi zależało tylko na prostej funkcjonalności ON/OFF, takiej zgody na pracę urządzeń, jak funkcja automatycznego wyłączenia zapomnianych urządzeń po godzinach pracy. Natomiast monitorowania parametrów w systemie nadrzędnym nie planował. Trzeba ustalić to na początku, zamiast z góry zakładać pełną funkcjonalność…
W funkcjonalności systemów zabezpieczeń częstym pomysłem i hasłem w projekcie jest integracja systemów CCTV z innymi systemami, np. KD lub SSWiN. Dobry pomysł, ale sloganowo potraktowany może wpędzić w kłopoty. Przykład: system CCTV zostanie zintegrowany z systemami KD i SSWIN w celu uruchomienia nagrywania z większą rozdzielczością zdarzeń alarmowych na obrazie z określonej kamery. To funkcjonalność zbędna w przypadku systemu CCTV z porządną analityką obrazu i detekcją ruchu, dodatkowo z programowaną długością pamięci wstecznej kamery, wręcz nie do osiągnięcia poprzez integrację, natomiast niezbędna dla kamer obrotowych ze zmiennym zoomem. Ta sama funkcjonalność, inny system CCTV i albo fanaberia, albo konieczność i efektywne podniesienie funkcjonalności, idealnie wpisujące się w zaproponowaną definicję integracji.
I inny przykład: integracja systemów SSP w różnych budynkach w obiektach rozproszonych
Użytkownik zakłada centralne pomieszczenie ochrony i operowanie z tego pomieszczenia funkcjami Potwierdzenie oraz Kasowanie. Takie rozwiązanie może się okazać wręcz niezgodne z zasadami sztuki. Nie wolno umożliwić służbom technicznym kasowania alarmu z poziomu innego budynku. Jeżeli funkcjonalność zostanie zaimplementowana bez dokładnego uzgodnienia z rzeczoznawcą ppoż., możemy narazić się na zarzut błędu technicznego.
Prawidłowe określenie wszystkich potrzeb na początku projektu oszczędzi mnóstwo czasu. Inżynier odpowiedzialny za integrację doskonale wie, o czym piszę, ale rzadko dostrzega potrzebę omówienia tego z użytkownikiem, przedstawienia mu „plusów i minusów”. A jeżeli dostrzega, to trudno mu się z tym przebić na wczesnym etapie inwestycji. Z braku komunikacji wynikają kłopoty techniczne. Z kolei zaimplementowanie maksymalnej funkcjonalności, niepotrzebnie dublującej różne funkcje systemu, trudno nazwać optymalnym projektowaniem. W większości umów na prace projektowe taki obowiązek jest zapisany, więc projektant może narazić się na zarzut nierzetelnego projektowania. I nie są to słowa bezpodstawne.
Gdy już przebrniemy przez fazę uzgodnień funkcjonalnych, „wyciągniemy” od użytkownika informacje operacyjne, zapiszemy je w formie uzgodnionych parametrów integracji, reszta pójdzie jak z płatka. Wystarczy podzielić te uzgodnienia na poszczególne systemy, rozesłać je do odpowiednich branżystów z prośbą o potwierdzenie, że zaproponowane przez nich urządzenia czy systemy będą zaprojektowane w sposób pozwalający na uzyskanie odpowiedniej funkcjonalności. To faza równie trudna jak poprzednia i równie potrzebna. Najczęściej odpowiedzią na prośbę o uzgodnienia jest: odszukaj w kartach katalogowych urządzeń. Projektant integracji nie może zaakceptować takiej odpowiedzi. Trzeba wymagać koordynacji, co nie oznacza, że np. projektant wentylacji może nie analizować założeń integracji i funkcjonalności z tego wynikających.
Należy dopilnować, by w założeniach integracji nie było np. płynnej regulacji wentylacji 0…100% dla urządzeń z lokalną automatyką urządzeń pracujących ON/OFF lub co najwyżej ze skokową regulacją, co się zdarza. I odwrotnie – sterowanie ON/OFF oświetleniem w systemie nadrzędnym, a po stronie elektrycznej system Dali i oprawy typu dim. To prosta ścieżka do zarzutów o nierzetelność projektu.
Kolejny krok po uzgodnieniu funkcjonalności – należy dokładnie zaprojektować interfejs do połączenia poszczególnych systemów, prawidłowo określić protokoły komunikacyjne lub liczba sygnałów dla interfejsów twardodrutowych. Faza ta jest bardzo trudna, wymaga ciągłej komunikacji pomiędzy projektantami poszczególnych systemów, informowania o ewentualnych zmianach urządzeń, a także, na co czasem nie można liczyć, o wszelkich zmianach oprogramowania w przypadku integracji programowej urządzeń. Jednak dopiero po tych uzgodnieniach można założyć, że faza projektowania dobiegła końca. Teraz już tylko najprostsze, czyli wybudowanie i uruchomienie.
To oczywiście mała prowokacja. Wiadomo że uruchomienie jest jeszcze trudniejsze niż projektowanie, ale bez prawidłowego projektu uruchomienie może okazać się niewykonalne! Ale to temat na inną dyskusję. Nie da się jednak zacząć uruchomień, jeżeli projektant zapomni o jeszcze jednym elemencie: odpowiednio zaplanowanym i skoordynowanym systemie okablowania budynku, tym bardziej że według założeń systemy będą integrowane z wykorzystaniem systemu okablowania strukturalnego wspólnego dla wszystkich systemów. To kolejny ważny element do skoordynowanego zaprojektowania.
Podsumowując, integracja może być zarówno koniecznością, jak i fanaberią lub kłopotem. Wszystko zależy od projektanta integracji, od jego doświadczenia, wiedzy, ale również umiejętności komunikacyjnych, które są niezbędne dla zapewnienia wsparcia użytkownika przy doprecyzowaniu wymagań. Wszystko sprowadza się do zamiany zdania: system X należy zintegrować z systemem Y na skoordynowany projekt integracji systemów. Marzy mi się, by ten artykuł rozpoczął wielobranżową dyskusję na temat integracji…
 |
|
