Wybór systemu SCADA – czym się kierować?

Najprostszym interfejsem są po prostu przyciski i lampki dostępne na pulpicie szafki sterującej. Takie rozwiązanie umożliwia co prawda proste sterowanie, jednak nie nadaje się do linii produkcyjnych z uwagi na brak możliwości zaawansowanej parametryzacji. Dodatkowo koszt modułów wejść/wyjść sterownika PLC, który obsługiwałby wspomniane przyciski i lampki jest znaczący w porównaniu z prostym, graficznym panelem operatorskim, podłączonym wprost do sterownika kontrolującego maszynę, poprzez kabel sieciowy czy nawet najprostsze połączenie RS.

Niestety, funkcjonalność panelu operatorskiego wraz z działającą na nim aplikacją graficzną – nazywaną często aplikacją HMI (ang. Human Machine Interface) – może okazać się niewystarczająca do zaawansowanego sterowania. Nawet nowe funkcjonalności implementowane przez producentów paneli operatorskich nie gwarantują spełnienia założeń i oczekiwań użytkownika systemu, szczególnie przy większych aplikacjach. W takim przypadku zastosowanym rozwiązaniem interfejsu sterowania powinien być system SCADA.

Porównanie HMI vs SCADA

Oczywiście system oparty na panelach operatorskich jest tańszy i pozwala realizować lokalne sterowanie maszyną. Problem pojawia się, kiedy chcielibyśmy połączyć nasz system sterowania i zarządzania tak, by móc uzyskać globalną, zdalną kontrolę z monitorowaniem parametrów historycznych. W szczególności kiedy myślimy o przyszłościowej możliwości wdrożenia systemu zarządzania produkcją, systemów klasy MES (ang. Manufacturing Execution System) określanym w języku polskim jako System Realizacji Produkcji lub po prostu zbierania archiwalnych danych procesowych. W takiej sytuacji wybór powinien być oczywisty. Implementacja systemu SCADA – choćby jednostkowych aplikacji – pozwoli nam na późniejszą – łatwą i tańszą implementację informatycznego systemu nadrzędnego, co jest trudne do osiągnięcia przy wykorzystaniu tylko i wyłącznie paneli operatorskich.

Producenci paneli mogliby nie zgodzić się z twierdzeniem, że panele operatorskie nie mają zaawansowanych możliwości archiwizacji i zdalnego dostępu. Jest to po części prawda, jednak „diabeł tkwi w szczegółach”. Należy pamiętać, że panele operatorskie są zarządzane przez system operacyjny własny lub często Windows CE czy Linux w wersji embedded. Nie mają twardych dysków, a jedynie karty pamięci. Zdalny dostęp do aplikacji najczęściej możliwy jest tylko poprzez program, który przejmuje lub duplikuje pulpit jak VNC. Zdarza się, że taka funkcjonalność może wymagać dodatkowych płatnych licencji.

Archiwizacja danych najczęściej dokonuje się albo w formacie zamkniętym – binarnym (który później należy konwertować np. do programu Excel), albo do plików tekstowych czy formatu plików csv, które są zapisywane na zewnętrznej karcie pamięci lub pamięci masowej USB. Zdalny dostęp do archiwum jest więc utrudniony. Takie rozwiązanie wymusza także potrzebę zgrywania i synchronizowania archiwum z plikami historycznymi, o czym nie zawsze pamięta się w aplikacjach produkcyjnych. Kiedy dochodzi do zapełnienia pamięci lub jej uszkodzenia, dalsza archiwizacja staje się tymczasowo niedostępna, gubiąc bezpowrotnie dane procesowe. Myślę, iż tego, że nie jest to system redundantny, dodawać nie trzeba.

Panele operatorskie mają również swoje zalety i z ekonomicznego punktu widzenia są niezastąpione, w szczególności w aplikacjach małych, autonomicznych, niewymagających zasobów sprzętowych, czy o ograniczonej funkcjonalności archiwizacji danych. Poniżej przedstawiono porównanie systemów HMI i SCADA.

	HMI	SCADA
Hardware	panel operatorski	komputer klasy PC bądź serwer
Monitor	wbudowany, najczęściej dotykowy	zewnętrzny lub wbudowany, może być dotykowy
System operacyjny	własny, Windows CE, Linux	Windows, Windows Serwer, rzadko Linux
Licencjonowanie (liczba zmiennych)	praktycznie nielimitowane, ale z ograniczeniami max., zależnymi od typu panelu na ekran i aplikacji	limitowane zależnie od licencji
Możliwości archiwizacji i wdrożenia receptur	małe i ograniczone	duże
Połączenia z zewn. aplikacjami	rzadko stosowane, OPC (może być dodatkowo płatne)	bazy danych, Office, VBS, C, .Net, OPC (najczęściej w ramach licencji)
Praca typu klient–serwer	tak – z ograniczeniami	tak – praca na wielu serwerach, opcjonalnie klient WWW
Zasięg aplikacji	mały	duży
Współpraca z bazami danymi	ograniczona i w praktyce niewykorzystywana	tak – najczęściej MSSQL, Oracle, PostgreSQL, mySQL, FireBird.
Interfejsy komunikacyjne	Ethernet, RS (z wbudowanymi protokołami, np. MPI, Profibus)	Ethernet, RS, niektóre protokoły wymagają zewnętrznych konwerterów

Szerokie spektrum wyboru funkcji

W przypadku, kiedy użytkownik chciałby zarządzać produkcją, monitorować parametry, współczynniki jakościowe, archiwizować dane w sposób ciągły i dostępny on-line, przeprowadzać automatyczny audyt zmian parametrów, monitorować pracę i wydajność pracowników czy wykonywać raporty produkcyjne – tak naprawdę nie powinien zastanawiać się, CZY wybrać system SCADA, ale JAKI system SCADA będzie dla niego najlepszy.

Wybór odpowiedniego systemu SCADA, który będzie spełniał założenia i oczekiwania, nie jest łatwy, a nieznajomość funkcjonalności poszczególnych systemów SCADA dostarczanych przez różnych producentów oprogramowania może doprowadzić do braku możliwości rozbudowy aplikacji lub zakupu dodatkowych licencji, które u innych producentów byłyby zawarte w wariancie podstawowym. Może także spowodować, że mimo zakupu dodatkowych licencji nadal nie osiągniemy zamierzonego poziomu informatycznego zarządzania procesami technologicznymi.

Czasy, kiedy system SCADA rozumiano jedynie jako aplikację wizualizacji i kontroli procesów minęły dawno temu. Możliwości sprzętowe i rozwój tego typu aplikacji spowodował, że wizualizacja jest tylko dodatkiem do szeregu innych, ważniejszych funkcjonalności, niezbędnych lub ułatwiających zarządzanie parkiem maszyn. Zdarza się nawet, że moduł graficzny aplikacji jest wyłączany z premedytacją, a system działa jako usługa na serwerze. Część graficzną interfejsu sterowania można zastąpić innymi elementami, np. panelem operatorskim, a pozostałe funkcjonalności – tylko przez opracowanie od podstaw dedykowanych aplikacji.

Projektowanie z potencjałem

Integrator automatyki przemysłowej stara się podczas projektowania systemu automatyki wyjaśnić użytkownikowi, dlaczego czasami warto zapłacić więcej na początku użytkowania za system SCADA czy platformę komputerowo-serwerową, by później zaprojektowany system był na tyle otwarty, aby w przyszłości można było implementować nawet te rozwiązania informatyczne, których do tej pory użytkownik nie potrzebował lub brakowało mu na nie funduszy.

To pracownicy docelowego zakładu użytkują system i to im powinno zależeć na tym, by w sposób ciągły, prosty, szybki i ekonomiczny zarządzać platformą SCADA. Firmy integratorskie, które projektują aplikacje SCADA, największy zysk czerpią z przygotowania aplikacji, poszczególnych modułów funkcyjnych i integracji przygotowanego systemu ze stosowanym w firmie systemem informatycznym. Marża licencji odsprzedawanych docelowemu użytkownikowi jest z reguły sprawą drugorzędną. Dlatego też dla deweloperów, w przeciwieństwie do użytkownika, wybór konkretnego systemu SCADA nie jest najistotniejszy. Najważniejsze, by użytkownik rozumiał, jakie funkcje oferuje dany system SCADA. Decyzja o wyborze potrzebnych funkcjonalności jest jedną z ważniejszych, jakie należy podjąć już na początku. Firma integratorska powinna jedynie służyć użytkownikowi radą i ofertą dostępnych rozwiązań.

To samo dotyczy systemu MES. Pojęcie funkcjonalności zarządzania produkcją jest bardzo szerokie i może być interpretowane jako pojedynczy moduł funkcjonalności, ale również jako ogromna struktura informatyczna wraz z obsługującymi ją serwerami.

Co wpływa na wybór dostawcy?

Jak wybrać odpowiedni system, by można było zintegrować go z systemem informatycznym czy też z większym systemem ERP (ang. Enterprise Resource Planning) przedsiębiorstwa?

Wdrożonego w przedsiębiorstwie systemu ERP nikt nie chce zmieniać, ponieważ wydano na ten cel olbrzymie fundusze, a jego zmiana czy zaawansowana modyfikacja pochłonęłyby następne. Dlatego też tak ważne jest utrzymanie określonego standardu producenta lub jego szybka zmiana, jeśli pierwszy wybór okazał się niedostateczny.

Najczęściej wybór systemu SCADA jest podyktowany wprowadzeniem w zakładzie standardu stosowanego przez jednego dostawcę oprogramowania lub też ofertą wyboru integratora systemów automatyki. Standaryzacja oprogramowania jest bardzo dobrym rozwiązaniem, ułatwiającym integrowanie tego typu aplikacji i co ważniejsze – serwis. Z punktu widzenia utrzymania ruchu nie ma nic gorszego niż synchronizacja platform dostarczanych przez kilku producentów. Często zdarza się, że łączenie aplikacji i wymiana danych między nimi jest trudna do realizacji albo i niemożliwa. Ujednolicenie oprogramowania aplikacji SCADA może wpłynąć również na ograniczenie kosztów licencyjnych, a głównie licencji deweloperskich (niezbędnych do edycji projektów), których wymaga się do każdej platformy osobno.

Pytania, które ułatwią podjęcie decyzji

Kolejnym krokiem doboru oprogramowania aplikacji SCADA są elementy funkcjonalności, które użytkownikowi wydają się niezbędne. Słowo „wydają się” jest tu użyte z premedytacją, ponieważ z reguły użytkownik docelowy nie potrafi określić wszystkich, a rozbudowa tej listy jest często kontynuowana po rozmowach projektowych z integratorem. Poniżej przedstawiam propozycję pytań pomagających w doborze funkcjonalności. Odpowiedzi na nie determinują wybór producenta systemu SCADA.

• Ciągła, pewna i wydajna archiwizacja wartości procesowych i alarmów: czy podgląd wartości archiwalnych powinien odbywać się tylko w aplikacji SCADA, czy też powinien być otwarty i dostępny dla innych aplikacji?
• Czy system informatyczny ma analizować, wyliczać i wyświetlać inne wartości, jak np. moc czy energię, na podstawie już zebranych danych, sporządzać wykresy czasowe i wykresy zależności wielu wartości lub grup urządzeń? Czy ma monitorować i wyświetlać pomiary np. mediów, wyliczać ich zużycie i zapotrzebowanie, wyliczać koszty jednostkowe zużycia na wyprodukowany element czy określony czas produkcji?
• Czy system ma kontrolować jakość, wydajność i czas pracy operatorów?
• Czy system ma automatycznie przeprowadzać audyt zmiany parametrów potrzebnych do osiągnięcia jakości i wydajności?
• Czy system ma monitorować i wyliczać współczynniki produkcyjne, jak czas postojów, awarii, dostępności, wykorzystania maszyny, kontrolowania norm wydajnościowych albo porównywać pracę różnych operatorów?
• Czy system ma śledzić wyprodukowane partie ze względu np. na czas wyprodukowania, koszt jednostkowy, zużycie materiałów, rodzaj materiałów, osoby wykonującej, aktualne wartości, np. podczas ważenia itp.?
• Czy podczas produkcji wykorzystywany będzie system receptur – począwszy od najprostszych zestawów parametrów – jak również produkcja na bazie wstępnie przygotowanych list w systemie ERP, planowanie wykonania takich receptur, ich kolejkowanie itp.?

System bazodanowy

Interfejs graficzny można zaprojektować w każdym systemie SCADA tak, by wyglądał praktycznie identycznie. Jednak oprócz modułu graficznego, najczęściej wykorzystywaną funkcjonalnością jest ciągła i pewna archiwizacja danych produkcyjnych wszelkiego rodzaju, również tych opisanych wcześniej. To, że dane zostaną „gdzieś” zapisane i staną się danymi archiwalnymi – to tylko część sukcesu. Wartości procesowe mogą przecież zostać zapisane nawet przez panel operatorski. Ważny jest jednak ich format i możliwość wykorzystania w otwarty, swobodny, dowolny sposób, nawet w przyszłości, jeszcze nieznany dla użytkownika w chwili wdrożenia.

Najlepszym, spełniającym te kryteria sposobem składowania danych z aplikacji SCADA jest system bazodanowy. Dobrze zaprojektowany gwarantuje pewność zapisu, otwartość dla innych aplikacji i sporządzanie wielu różnych raportów z tych samych danych. Składowanie danych w bazie danych jest często złożonym problemem, ze względu na dobór platformy informatycznej. Decydując się na system bazodanowy, stajemy więc przed wyborem odpowiedniej bazy danych, czyli producenta oprogramowania baz danych.

Nie każdy producent oprogramowania SCADA umożliwia swobodny zapis własnych struktur danych, a jeśli to umożliwia, to wiąże się to z licencją na tworzenie własnego archiwum. Mamy więc wybór między wykorzystaniem mechanizmów tworzenia aplikacji bazodanowych na warunkach producenta systemu SCADA i zakupem odpowiednich licencji, a stworzeniem własnego systemu bazodanowego i mechanizmów dostępu do baz oraz połączenia go z aplikacją SCADA.

Z reguły w przedsiębiorstwie istnieje już system informatyczny oparty na oprogramowaniu baz danych konkretnego producenta. Dlaczego go nie wykorzystać i nie gromadzić danych w miejscu dostępu wszystkich aplikacji przemysłowo-biurowych? W naszej historii integratora automatyki nigdy żaden z użytkowników nie zapytał nas o dobór oprogramowania bazy danych, a oszczędności licencyjne powstałe z wykorzystania istniejących rozwiązań często są większe niż przygotowanie samej aplikacji.

Niestety bardzo często, decydując się na konkretne oprogramowanie SCADA, zmuszeni jesteśmy do kupienia licencji konkretnego producenta baz danych. W przypadku, kiedy użytkownik nie stosuje tego oprogramowania w przedsiębiorstwie, i tak ponosi koszt licencji silnika bazy, mimo że go nie wykorzysta. Jeśli przynajmniej system bazodanowy jest tego samego producenta, co używany w przedsiębiorstwie do tej pory – wtedy, mimo kosztów licencyjnych, mamy możliwość bezproblemowej implementacji bazy – zmniejszając obciążenie serwera danych firmy i łatwość synchronizacji.

Należałoby więc rozważyć istniejące rozwiązania oprogramowania SCADA, które nie wymagają licencji na serwer baz danych i dają możliwość wyboru zarówno producenta baz, jak i miejsca składowania tabel z danymi (inne serwery). Chociaż takie oprogramowanie istnieje, niestety nie stało się standardem producentów systemów SCADA.
Pamiętajmy jednak, że w przypadku kiedy serwer baz danych nie jest dołączany do oprogramowania SCADA jako integralna część, mimo oszczędności na licencjach tego serwera, system bazodanowy i tak może być potrzebny. Wtedy musimy zastanowić się:

• czy wykorzystujemy oprogramowanie baz danych tego samego producenta, które funkcjonują już w przedsiębiorstwie,
• czy wykorzystujemy zapas licencji, które w przedsiębiorstwie mogą już być zakupione a nie są wykorzystywane,
• na jakiej platformie systemu operacyjnego (np. Windows, Linux) chcemy umieścić nasze bazy produkcyjne,
• czy użyjemy darmowych rozwiązań serwerów baz danych, które często są wystarczające do zastosowań produkcyjnych – wtedy nie ponosimy żadnych dodatkowych kosztów licencyjnych.

Najlepiej wziąć pod uwagę również zdanie pracowników z działu IT, ponieważ to oni najlepiej wiedzą, z jakich zasobów można skorzystać i pomogą w podjęciu decyzji.

Możliwości komunikacyjne

Kolejną ważną kwestią podczas wyboru producenta systemu SCADA jest sposób komunikacji ze stosowanymi sterownikami PLC na maszynach – czyli ze źródłami danych, które chcemy wyświetlać i archiwizować w naszym systemie SCADA/MES. Na rynku oprogramowania SCADA często można spotkać systemy, które mają bardzo ograniczone możliwości komunikacyjne ze sterownikami PLC pochodzącymi od różnych producentów. Może okazać się, że wybrany przez użytkownika system SCADA połączy się z wieloma sterownikami PLC, ale nie ze wszystkimi. Należy więc sprawdzić, jakie sterowniki PLC (jakich producentów) użytkownik posiada już w maszynach i czy wybrany system SCADA ma wbudowane drivery komunikacyjne do wszystkich sterowników, z których chcemy odczytywać informacje.

Specyficznym driverem komunikacyjnym, wykorzystywanym w aplikacjach SCADA, jest tzw. serwer i klient OPC (ang. OLE for Process Control), który umożliwia komunikację z innymi aplikacjami, integrując np. skoroszyt Excel wprost z systemem, co umożliwia tworzenie raportów w środowisku Office. Jeżeli OPC jest częścią systemu SCADA, może być również dostawcą danych ze sterowników dla innych aplikacji wizualizacji, które nie mają możliwości bezpośredniego odczytu. Takie właśnie rozwiązanie często stosuje się w aplikacjach jako „pomost” komunikacyjny między różnymi producentami oprogramowania SCADA. Uważam jednak, że rozwiązanie to powinno być stosowane w ostateczności, a nie jako podstawowe.

Inne rozwiązania

Warto zwrócić uwagę na aplikacje typu SCADA, które są własnoręcznie pisane przez integratorów automatyki. Ich rozwój jest może wolniejszy niż produktów większych firm, ale bardzo często taka aplikacja w zupełności wystarczy do zastosowania konkretnych rozwiązań, a cena jest znacznie mniejsza. Jednak w tej sytuacji użytkownik jest „skazany” na firmę, przez którą aplikacja została napisana, a jakikolwiek serwis i rozbudowa może być utrudniona. Często takie aplikacje nie mają dedykowanych driverów komunikacyjnych i używają wspomnianego drivera OPC, za który – w przypadku komercyjnym – również trzeba zapłacić. W sytuacji wykorzystania darmowego rozwiązania OPC może okazać się, że komunikacja będzie niestabilna i nie zagwarantuje ciągłości pracy.

Raportowanie

Następnym trudnym zagadnieniem związanym z doborem systemu SCADA jest możliwość wykorzystania modułu raportowania. Wcześniej lub później każdy użytkownik systemu SCADA, mający system bazodanowy zbierania informacji, będzie potrzebować odpowiedniego systemu raportowania danych. Z wieloletnich doświadczeń podczas wykorzystywania komercyjnych aplikacji wynika, że funkcja tworzenia raportów, opartych na module wbudowanym w system SCADA, nie spełnia do końca oczekiwanych wymagań, a co najwyżej jest wydrukiem aktualnych danych, np. etykiet. Wielu producentów oprogramowania SCADA umożliwia również zakup dodatkowego licencjonowanego modułu raportowania, często mającego w nazwie słowo

Niektórzy dostawcy wprost informują, że zalecają użycie zewnętrznej komercyjnej aplikacji raportowania. I tu znów pojawia się pytanie, czy przedsiębiorstwo używa jakiejkolwiek komercyjnej aplikacji, umożliwiającej własne tworzenie nowych raportów, albo czy stosowane środowisko do tworzenia raportów będzie kompatybilne z systemem SCADA.

Integratorzy często stawiają na możliwość przygotowania otwartych raportów, które można edytować, bądź stworzyć nowe bez dodatkowych licencji, a ich koszt związany jest tylko i wyłącznie z pracami programistycznymi, które można wykonać również samodzielnie. Uniwersalność funkcji raportowania to właśnie nieograniczona możliwość ich przygotowania, równoczesny dostęp dla wielu użytkowników, wyświetlanie w aplikacji niezależnej od wizualizacji, np. w przeglądarce internetowej, zdalny dostęp itp.

Aby uzyskać raporty spełniające powyższe założenia i bazujące bez ograniczeń na zalogowanych danych historycznych, należy zadbać o prawidłową budowę systemu bazodanowego, który umożliwi udostępnianie danych pod wieloma aspektami.

Platformy serwerowe

Ostatnim ważnym punktem doboru systemu SCADA jest możliwość instalacji aplikacji na platformach serwerowych, praca multiserwerowa i multikliencka. Podczas obsługi przez system SCADA wielu maszyn i linii produkcyjnych, może okazać się, że komputer, na którym zainstalowaliśmy aplikację będzie tak obciążony, iż po prostu nie będzie w stanie poprawnie pracować. Dlatego warto zastanowić się nad inwestycją w serwerowe platformy komputerowe, zamiast serwery desktopowe. Takie rozwiązania są oczywiście droższe, jednak mniej zawodne z uwagi na wyprowadzenie umiejscowienia serwerów z obszaru produkcji. Jeżeli uszkodzi się komputer wizualizujący aplikację na produkcji, możemy go podmienić bez dodatkowego przygotowania. Jeżeli natomiast uszkodzeniu ulegnie desktopowy komputer aplikacji działający na produkcji, spowoduje to długotrwały przestój produkcyjny, a dane zebrane w systemie mogą być już nie do odzyskania.

Platformy serwerowe umożliwiają również zdecentralizowanie funkcji systemu SCADA, co zmniejsza obciążenie jednostkowe komputera obsługującego system. W dzisiejszych rozwiązaniach informatycznych coraz częściej stosuje się wirtualizację serwerów, która połączona z redundancją daje ponad 99 proc. szans na bezawaryjną pracę. Dlatego też, decydując się na platformy serwerowe, należy wykorzystać wirtualizację, która umożliwia łatwe przeniesienie serwerów na inną platformę sprzętową i ułatwia wykonanie kopii zapasowej.

Licencje na oprogramowanie

Przy wyborze wariantów danego oprogramowania należy bardzo wnikliwie przyjrzeć się zagadnieniom licencjonowania rozwiązań producentów oprogramowania i „wyłuskać” koszty wszystkich licencji, które będą niezbędne w pracy systemu. Czasami warto zapłacić więcej, uzyskując większą funkcjonalność i gwarantowany serwis producenta, niż korzystać z własnych aplikacji firm wdrożeniowych. Wszystko zależy oczywiście od ceny i możliwości.

Niestety, mimo skrupulatnych wyliczeń i planowania zakupu licencji oprogramowania, może okazać się, że użytkownik nie wziął pod uwagę licencji dodatkowych – często znaczących dla budżetu. Przykładem są licencje dostępowe do systemu operacyjnego serwera Windows i serwera baz danych MS SQL czy Oracle (w przypadku wersji komercyjnych). Takie licencje mogą kosztować więcej niż przygotowana aplikacja. Są one niezależne od oprogramowania SCADA, a integrator nie musi ich zapewniać, by rozliczyć się ze swojej części umowy przygotowania aplikacji. Niestety, z doświadczenia wiemy, że rzadko dokonuje się audytów licencji serwerowych. Powinny one leżeć w gestii działu IT, choć często nie chce on mieć z częścią produkcyjną nic wspólnego. Brak świadomości użytkownika co do konieczności posiadania licencji nie usprawiedliwia go i powoduje, że prawo łamane jest przez niego, a nie przez integratora.

Podsumowanie

Aby wybrać odpowiedniego dostawcę oprogramowania SCADA, należy zwrócić uwagę, w jakim systemie operacyjnym możemy tę aplikację zainstalować. Bardzo ważny jest dobór serwera bazy danych, z którą system będzie współpracował. Warto zrobić rozeznanie, czy możliwe jest wykorzystanie własnych, już istniejących zasobów sprzętowych, programowych i licencyjnych. Należy zadbać o przygotowanie odpowiedniej produkcyjnej struktury bazodanowej, która będzie źródłem raportów i potwierdzić, że wybrane technologie pisania raportów będą mogły współpracować z naszym systemem SCADA. Dlatego tak ważne jest, by użytkownik zdawał sobie sprawę z tego, czego oczekuje od systemu SCADA i firmy integratorskiej.

Kiedy użytkownik, dzięki własnemu zaangażowaniu, osiągnie założoną funkcjonalność systemu przygotowanego specjalnie z myślą o pracy w jego przedsiębiorstwie, uzyska prosty dostęp do wygenerowanych informacji. Użytkownik może z czasem rozbudowywać system, a także przesunąć na później koszty związane z tą rozbudową. W przeciwnym razie zapłaci za system, z którego nie będzie umiał do końca korzystać, a analiza nadmiaru informacji wygenerowanych przez system będzie całkowicie nieopłacalna w stosunku do straconego czasu.

source: "Automatyka" 10/2015