Z Jakubem Bartkowiakiem, dyrektorem Działu Oprogramowania w Ela-compil, rozmawia Jan T. Grusznic, zastępca redaktora naczelnego „a&s Polska”.

Od lat obserwujemy pozytywny trend związany ze zintegrowanymi systemami zabezpieczeń. Łącząc sygnały z wielu podsystemów, znacząco ograniczają one ryzyko wystąpienia zdarzeń niepożądanych, takich jak pożar lub włamanie. Ponadto ułatwiają zarządzanie obiektem i wpływają na jego funkcjonalność. GEMOS jest jednym z takich systemów. Co go wyróżnia na tle konkurencji?

Jest kilka elementów. Przede wszystkim liczba różnych podsystemów, które jest w stanie połączyć. Architektura systemu wymusza, żeby każda integracja była samodzielnym modułem, dzięki czemu jej rozwój jest niezależny od rozwoju rdzenia systemu, a raz stworzona może być  ponownie użyta. W ten sposób system doczekał się ponad 750 różnych takich modułów. Drugim ważnym atutem jest jego uniwersalność i elastyczność. Nie ma takich samych instalacji systemu GEMOS, a jest ich ponad tysiąc. Należy podkreślić różnicę pomiędzy systemami, które są tworzone pod kątem klienta, a systemami takimi jak GEMOS, które są konfigurowane pod jego kątem. W pierwszym przypadku producent tworzy wariację swojego produktu, która ma własny cykl życia i nadaje się do użytku tylko w docelowym projekcie. System GEMOS natomiast zawsze jest ten sam, a jego rozbudowane możliwości konfiguracji zapewniają uzyskanie pożądanego poziomu integracji. Dzięki takiemu podejściu klienci mogą szybciej aktualizować system, a producent może planować dalszy rozwój oprogramowania.

Ostatni argument jest dyskusyjny, ale postaram się go obronić. Chodzi o fakt, że GEMOS działa w przeglądarce internetowej. Jako główną zaletę takiej architektury najczęściej podaje się brak konieczności instalowania dodatkowego oprogramowania na stacji klienckiej, ponieważ przeglądarka praktycznie zawsze w komputerze jest zainstalowana. Ułatwia nam to życie i ma jeszcze jedną zaletę. Zadajmy sobie pytanie, z jakich aplikacji na co dzień korzystamy i ile spośród nich obsługujemy lub moglibyśmy obsługiwać przez przeglądarkę. Dzisiaj Internet zdominował nasze życie, a rozbudowane aplikacje przeglądarkowe zadomowiły się i zaczęły wypierać klasyczne. Przeglądarki dają dziś ogromne możliwości. Są nawet dostępne komputery, takie jak Google Chromebook, w których pełnią one funkcję systemu operacyjnego. Rynek aplikacji dostępnych przez przeglądarkę rozwija się dynamicznie. Ten trend sugeruje, że wkrótce nasi użytkownicy będą korzystać wyłącznie z aplikacji dostępnych przez przeglądarkę lub ze smartfonu i powoli zapomną, jak wyglądają klasyczne aplikacje desktopowe lub jak się je instaluje. GEMOS może na tym tylko skorzystać.

Tyle że typowy interfejs użytkownika platformy PSIM prezentuje się dość siermiężnie w porównaniu do obecnie dostępnych aplikacji przeglądarkowych. Choć na tegorocznych targach w Essen pokazaliście, że można wprowadzić nową jakość w sposobie prezentacji planów i danych. Na czym polega GEMOS MOSAIC i  skąd pomysł na jego stworzenie? 

W naszej branży takie rzeczy, jak wygląd czy intuicyjność obsługi interfejsu użytkownika aplikacji, często niestety schodzą na dalszy plan. Liczy się przede wszystkim wywiązanie z zapisów zawartych w SIWZ. Poza tym trudno byłoby je opisać, ponieważ to kwestia percepcji i subiektywnej opinii. Każdego interfejsu użytkownika można się przecież nauczyć, a systemów PSIM nie wdraża się bez serii szkoleń. Warto jednak zatrzymać się na chwilę i przyjrzeć systemom typu smart home, które są de facto rodzajem PSIM w skali mikro. Co prawda oferują ubogą funkcjonalność w porównaniu do PSIM, ale zwykle ich interfejs użytkownika stoi na wysokim poziomie. Może to wynikać stąd, że klientem końcowym jest zwykle tzw. pokolenie plug-and-play, które kupuje oczami i oczekuje, że bez szkolenia czy instrukcji obsługi będą mogli korzystać z aplikacji.

Ta obserwacja była zalążkiem pomysłu stworzenia nowego modułu wizualizacji planów w GEMOS, który wyglądem i intuicyjnością obsługi nie odstawałby od nowoczesnych aplikacji internetowych. Chcieliśmy zaprzeczyć tezie, że sposób działania nie jest tak ważny, i udowodnić, że nasza branża doceni te same aspekty, które wymuszają klienci indywidualni. Tak powstał moduł MOSAIC, który wnosi nową jakość do wizualizacji planów w GEMOS. Wspiera różne formaty map w sposób zunifikowany, oferując płynność obsługi, znacznie większy zakres przybliżania, animacje, poruszające się punkty, dynamiczne rysowanie stref, wykrywanie kolizji, obsługę ekranów dotykowych i wiele innych funkcji, zachowując przy tym wsteczną kompatybilność z dotychczasowymi rozwiązaniami. To na początek, bo dopiero się rozkręcamy.

Ale, ale… Przecież to samo można osiągnąć, stosując grafikę wektorową?

Z grafiki wektorowej korzystaliśmy od dawna. W 2005 r. na konferencji SVG Open prezentowano korzyści z zastosowania wektorowego formatu SVG w przeglądarkach internetowych właśnie na przykładzie systemu GEMOS. Należy dodać, że natywne wsparcie dla tego formatu pojawiło się w pierwszych przeglądarkach dopiero trzy lata później. Dzisiaj format SVG nie wymaga instalowania jakichkolwiek dodatków, jednak użycie go do wizualizacji planów w przeglądarce internetowej nadal stanowi wyzwanie. Trzeba zmierzyć się z problemami wydajności, kontrolą tego, co jest wyświetlane, detekcją interakcji z użytkownikiem i wieloma innymi. Pracując nad modułem MOSAIC, zdecydowaliśmy, że wspierane dotychczas wektorowe formaty SVG oraz DWG będą nadal używane, ale jedynie jako punkt wyjścia do konwersji na format docelowy. Umożliwia to aktualizację i użycie tego modułu przez obecnych klientów, jak również nie wprowadza nowych nieznanych standardów.

A propos standardów. Coraz częściej w urządzeniach zabezpieczeń technicznych dostępne są otwarte standardy komunikacji. Przykładem może być ONVIF, który w tym roku skończył 10 lat. Czy popularyzacja otwartych standardów wymiany informacji pomaga w integracji?

Zdecydowanie pomaga, pod warunkiem że standardy te nie są ściśle powiązane z konkretnym językiem programowania lub platformą, a producenci systemów prawidłowo z nich korzystają. Za pozytywny przykład niech posłuży wspomniany standard ONVIF spopularyzowany w CCTV. Nie jestem zwolennikiem formatu XML i protokołu SOAP, ale muszę przyznać, że od czasu, gdy zaczął być powszechnie stosowany, wysterowanie pozycji predefiniowanej w kamerze czy uzyskanie adresu strumienia wideo nie stanowi już problemu. Nie trzeba się w tym celu kontaktować z producentem lub stosować specjalnie stworzonych do tego celu rozwiązań.

Negatywnym przykładem jest, moim zdaniem, standard OPC DA, bardzo popularny w automatyce budynkowej, stosowany również na rynku security. Już na starcie integrator jest zmuszony do korzystania wyłącznie z systemu Windows, ponieważ na nim standard został oparty. Potem nie jest łatwiej. Konfigurowanie zdalnego połączenia z serwerem OPC przypomina czasami drogę przez mękę. Problemów można by uniknąć, instalując różne programy firm trzecich, które wszystko za nas zrobią i podadzą informacje w bardziej przyjazny sposób – ale nie po to stosuje się standardy, żeby ich potem unikać.

Każdy standard jest inny, więc nie można jednoznacznie powiedzieć, że ich użycie zawsze ułatwi wszystkim życie. Jeżeli integrator nie ma wsparcia programistycznego, wtedy na pewno będzie preferował standardy otwarte. Jeżeli natomiast dysponuje działem programistów, skomplikowany otwarty standard może okazać się czasem bardziej pracochłonny niż zaimplementowanie i użycie optymalnego natywnego protokołu komunikacyjnego producenta.

Czyli jednak protokół natywny góruje nad otwartym? 

Na pewno protokoły natywne, czyli stworzone przez producentów systemów, są optymalnie dopasowane i często „lżejsze” niż otwarte uniwersalne protokoły ze swoimi „ciężkimi” warstwami abstrakcji. Przykładowo, przesłanie prostej wartości do systemu integrującego przy użyciu protokołu BACnet wymaga implementacji całego stosu komunikacyjnego i wsparcie tego standardu przynajmniej w minimalnym zakresie. W przypadku protokołu natywnego, jeżeli system jest prosty, producent może wysłać wartość opakowaną w bajty kontrolne i na tym koniec. Integracja byłaby na pewno szybsza w drugim przypadku i wymagałaby minimalnego wysiłku programisty. Ale uwaga: nawet najprostszy protokół natywny może okazać się bezużyteczny, gdy integrator dysponuje tylko gotową platformą, w którą nie może ingerować.

Są też wady protokołów natywnych, które uwidoczniają się przede wszystkim w dwóch przypadkach. Po pierwsze, gdy protokół jest bardzo rozbudowany i skomplikowany. Jeżeli producent dostarcza pakiet SDK, większego problemu nie ma. Jeśli natomiast na integratora spada konieczność implementacji protokołu zgodnie z jego 200-stronicową specyfikacją, którą uzyskał po podpisaniu NDA (umowy poufności – przyp. redakcji), to koszty integracji znacząco rosną, ponieważ próżno szukać w Internecie przykładów wdrożeń. Drugim przypadkiem, często spędzającym sen z powiek, jest sytuacja, kiedy protokół na pierwszy rzut oka wydaje się prosty i czytelny. Ale gdy nie zastosowano w nim logicznych reguł lub jest pełen wyjątków, gdy brakuje powtarzających się schematów, wtedy implementacja staje się problematyczna i podatna na błędy.

Raporty, które publikujemy na łamach a&s alarmują o rosnącym niebezpieczeństwie cyberataków na urządzenia przemysłowe oraz elementy platformy PSIM jako najbardziej podatne. Jako szef działu programistów jak oceniasz to zagrożenie? Na co zwracać uwagę, administrując takim systemem, by ryzyko skutecznego ataku było mniejsze? 

Zagrożenie jest jak najbardziej realne, zwłaszcza gdy wydaje się nam, że skoro system nie jest podłączony do Internetu, to jest bezpieczny. Często spotykam się ze stanowczym sprzeciwem podłączania jakichkolwiek komponentów systemów do Internetu ze względu na przepisy bezpieczeństwa. Moim zdaniem to wylewanie dziecka z kąpielą, a takie przepisy są drogą na skróty. Korzystanie w obiekcie z sieci Wi-Fi, portów USB, komputerów przenośnych, brak polityki aktualizacji systemów operacyjnych czy też obecność sieci VPN łączącej rozproszone lokalizacje już stanowi punkty ataku i zagrożenie. Prawda jest taka, że samo ukrywanie się nie spowoduje, że będziemy bezpieczniejsi. Spójrzmy natomiast, co w efekcie takiej polityki tracimy. Dzisiaj moc obliczeniowa, jaką udostępniają nam operatorzy chmur, daje nowe możliwości, których nie bylibyśmy w stanie uzyskać, korzystając wyłącznie z zasobów lokalnych. Przykładem jest Microsoft, który intensywnie rozwija własną chmurę i planuje wykorzystanie dobrodziejstw sztucznej inteligencji i uczenia maszynowego do wspomagania procesów np. w fabrykach. Zamiast na ślepo blokować jakikolwiek ruch z i do Internetu, zdecydowanie lepszym rozwiązaniem jest zatrudnienie specjalistów ds. bezpieczeństwa IT i okresowe zamawianie testów. Nie należy myśleć, że „nikt mnie nie zaatakuje”, a raczej, że „kiedy mnie zaatakują, wiem, jak mam się bronić”.

Wracając do rozwoju oprogramowania: słyszałem, że po sukcesie MOSAIC Ela-compil otrzymała większą swobodę w tworzeniu kolejnych innowacji dla systemu GEMOS. Możesz zdradzić, nad czym obecnie pracujesz?

Przygoda z MOSAIC zaczynała się niepozornie, był to projekt wymyślony na przerwie kawowej i realizowany początkowo w wolnym czasie jako prosty proof-of-concept. Szybko zyskał jednak zainteresowanie i fakt prezentowania niedawno efektów naszej ciężkiej pracy na najważniejszej imprezie w branży, czyli targach Security w Essen, był zwieńczeniem naszego sukcesu. Z uwagi na potencjał, jaki oferuje MOSAIC, zaczęliśmy być zasypywani pomysłami nowych funkcjonalności, a w przyszłym roku, gdy moduł trafi do obecnych i nowych klientów, pomysłów będzie na pewno jeszcze więcej. Przygotowujemy się na dalszy jego rozwój, ale na horyzoncie mamy już kolejny, znacznie większy projekt. MOSAIC miał wprowadzić nową jakość do interfejsu użytkownika platformy GEMOS i to się udało, ale stanowi on sam w sobie tylko jedną z części całego systemu. Pora zrobić kolejny krok i zabrać się kompleksowo za pozostałe. Zdradzić mogę, że nie tylko ja podzielam ten pogląd i przyszły rok zapowiada się bardzo pracowicie!

Dziękuję za rozmowę.

Ela-compil

ul. Szczepanowskiego 8, 60-541 Poznań

tel. 61 869 38 50

office@ela.pl