Chmura w automatyce przemysłowej

O przenikaniu technologii biurowych do automatyki
Jako człowiekowi związanemu z automatyką przemysłową, trudno mi się pogodzić z myślą, że postęp w naszej dziedzinie odchodzi od zastosowań biznesowych. Niestety, najpierw wyprodukowano programowalny kalkulator, a dopiero później sterownik PLC, najpierw wykorzystano komputer osobisty – zwany pecetem ­– do tworzenia faktur, a dopiero znacznie później postawiono na nim pierwszy system SCADA. Spróbujmy się zatem zastanowić, jakie szanse powodzenia ma koncepcja przetwarzania w chmurze, która staje się coraz bardziej popularna w zastosowaniach do zarządzania przedsiębiorstwem. Może koncepcję przetwarzania w chmurze da się efektywnie wykorzystać do dalszego unowocześniania naszego oręża, co w konsekwencji pozwoli zmniejszyć koszty produkcji oraz zapewnić większe bezpieczeństwo dostaw.
Co to jest chmura
W przedsiębiorstwach produkcyjnych i u operatorów różnego rodzaju sieci wykorzystywanych do przesyłu energii, takich jak sieci elektroenergetyczne, cieplne, paliwowe, itp., systemy informatyczne są powszechnie stosowane, aby zapewnić poprawność przebiegu zachodzących w nich procesów. Z uwagi na materię swojego oddziaływania można je podzielić na systemy:

  • wspierające procesy biznesowe – zarządzanie procesami biznesowymi,
  • kontrolujące procesy technologiczne – zarządzanie procesami technologicznymi.

Każdą z powyższych grup możemy dalej dzielić z uwagi na sposób i zakres działania. Przykładowo mamy zrealizowane na sterownikach PLC układy automatycznej regulacji do kontroli przebiegu procesu technologicznego (automatyka) i zarządzanie relacjami z klientami określane skrótem CRM (ang. Customer Relationship Management) (biznes). Na pierwszy rzut oka może się wydawać, że ich zastosowania są tak odległe od siebie, że szukanie pomiędzy nimi jakichkolwiek relacji, w szczególności w zakresie ich rozwoju i wdrażania, nie ma większego sensu. Jednak artykułując tę tezę, natychmiast na myśl nasuwa mi się szybko rozwijająca się koncepcja sieci inteligentnych, przykładowo elektroenergetycznych (Smart Grid). W założeniu do tej idei przyjmuje się, że proces optymalizacji zużycia energii leży również, a może głównie, po stronie klientów – jej odbiorców, a do tego potrzebne jest udostępnienie im odpowiednich danych uzyskanych na podstawie pomiarów wielkości fizycznych.
Integracja różnych systemów informatycznych to temat na osobny artykuł. Teraz odwołuję się do niej jedynie, aby pokazać, że niektóre nasze utarte przekonania z czasem muszą zostać zweryfikowane. Pierwotnym jednak powodem jest próba wykorzystania kojarzenia zastosowań domenowych (klas systemów) do analizy przydatności koncepcji przetwarzania w chmurze w obszarze zarządzania procesami technologicznymi. I tu natrafiamy na dwie przeszkody. Pierwszą jest fakt, że koncepcja chmury nie jest „tematyczna”, to znaczy nie możemy dla niej określić sposobu i zakresu jej działania. Drugie utrudnienie wynika z tego, że pomimo powszechnego przekonania o jej użyteczności i ważności dla dalszego rozwoju systemów informatycznych, merytoryczna wiedza na ten temat jest umiarkowanie powszechna i spójna.
Skoro chmura nie jest klasą zastosowań, spróbujemy zdefiniować paradygmat stanowiący bazę tej dziedziny wiedzy. W dwuczłonowej nazwie „przetwarzanie w chmurze” kluczowe znaczenie ma słowo chmura, które pochodzi od piktogramu powszechnie używanego do reprezentowania pewnej infrastruktury komunikacyjnej, wykorzystywanej pomiędzy konsumentem pewnej usługi (klientem) i jej oferentem (serwerem) (rysunek 1). Role serwera i klienta mogą być względem siebie bardziej lub mniej symetryczne, ale zawsze potrzebują wymieniać się danymi, żeby ze sobą współdziałać. W zależności od wzajemnej lokalizacji serwera i klienta w omawianym przypadku chmura może reprezentować w skrajnych przypadkach sieć wewnętrzną – zakładową lub cały Internet. Dla lepszego zrozumienia ważnym pytaniem jest, jakie ten piktogram ma dla nas znaczenie – czemu w jego miejsce nie stosujemy przykładowo prostej kreski, która reprezentuje umowny „drut”, albo sześcioboku, który symbolizuje „czarną skrzynkę”. Odpowiedź jest następująca: ponieważ dzięki niemu chcemy wyrazić:

  • abstrakcyjność reprezentowanej infrastruktury (dlatego nie „pudełko”), co oznacza chęć pominięcia szczegółów nieistotnych dla omawianego zagadnienia, którym w tym przypadku jest współdziałanie klienta z serwerem – nie jest dla nas istotne, jaka droga, jakie urządzenia i jakie protokoły są wykorzystane do zapewnienia komunikacji – komunikacja po prostu jest, jest przezroczysta i wystarczająco wydajna;
  • wirtualność reprezentowanej infrastruktury, co oznacza, że infrastruktury nie wykorzystujemy na wyłączność (dlatego nie „drut”) naszej komunikacji – współdzielimy ją, natomiast w zamian możemy ją wykorzystywać według naszych potrzeb.

Powyższe stwierdzenia nie oznaczają, że nie wiemy, jak działa infrastruktura reprezentowana przez chmurę i z jakich komponentów jest zbudowana, a tylko to, że na potrzeby prowadzonej analizy współdziałania klienta z serwerem te szczegóły zaniedbujemy. Nie oznacza to również, że komunikacja klienta z serwerem może liczyć na nieograniczoną przepustowość. Oznacza natomiast, że wykorzystując pewien współczynnik jednoczesności, można okresowo dopasować wykorzystanie zasobów do potrzeb ich użytkowników. Powszechność wykorzystania infrastruktury pozwala również na zastosowanie rozwiązań nadmiarowych, które poprawiają niezawodność i dostępność.
Innymi słowy, abstrakcyjność i wirtualizacja pozwala na traktowanie reprezentowanej przez chmurę infrastruktury nie jako pewnej rzeczy, ale jako pewnej usługi, którą ktoś – przykładowo kolega z innego działu lub dostawca Internetu – świadczy na naszą rzecz. Ta wydawałoby się mało istotna dla omawianego zagadnienia współdziałania klienta z serwerem, znaczeniowa zmiana ma ogromne konsekwencje. To tak, jakby rozważając podróż z umownego punktu A do punktu B, mieć własny samochód albo go wypożyczyć. W obu przypadkach podróż będzie przebiegała dokładnie tak samo, ale….
Dla lepszego zrozumienia koncepcji chmury ważne jest, aby zauważyć, że jej symbol oraz powyższe rozważania nadają się dobrze do reprezentowania dowolnej infrastruktury. Może to być zarówno sieć wewnętrzna (a nawet lokalna), jak i Internet lub jakieś rozwiązanie hybrydowe. Możemy zatem również stwierdzić, że pojęcie to jest swobodnie skalowalne.
Wytłumaczenie znaczenia słowa chmura to dopiero połowa sukcesu. Pozostało jeszcze słowo „przetwarzanie”. Aby przybliżyć jego znaczenie, wystarczy wyobrazić sobie, że w chmurze „ginie” nie tylko infrastruktura komunikacyjna, ale również serwer wraz z oferowanymi na nim usługami (rysunek 2). Taki model jest szczególnie przydatny, gdy chcemy skoncentrować naszą uwagę wyłącznie na zaspokajaniu potrzeb klienta, a nie na szczegółach związanych z tym, jak i przez kogo są one zaspokajane.
Rodzaje chmur
Pochłonięcie przez chmurę serwera z oferowanymi na nim usługami powoduje, że do powyższych rozważań powinniśmy dodać jeszcze jeden punkt swobody – zakres usług świadczonych dla naszego zastosowania lub inaczej – co jest nasze, a co abstrakcyjne i wirtualne. Tak uogólniając, możemy wprowadzić klasyfikację świadczonych usług w następujących warstwach:

  • w warstwie aplikacyjnej: oprogramowanie jako usługa (ang. Software as a Service (SaaS)),
  • w warstwie systemowej: platforma jako usługa (ang. Platform as a Service (PaaS))
  • w warstwie infrastruktury: infrastruktura jako usługa ang. Infrastructure as a Service (IaaS)

Ponieważ w każdym z wymienionych przypadków usługa musi być świadczona selektywnie, można zdefiniować jeszcze jeden obszar: tożsamość jako usługa (ang. Identity as a Service IDaaS). Ta usługa pozwala na realizację uwierzytelniania i autoryzacji w systemach rozproszonych. Dostępność takiej usługi może być czynnikiem decydującym o powodzeniu takich projektów, jak np. inteligentne sieci, gdzie spodziewamy się milionów autonomicznych użytkowników, dla których trzeba selektywnie dostarczyć usługi na wybranym poziomie.
Dziś już każdy automatyk bez trudu może sobie wyobrazić możliwość wykorzystania publicznej infrastruktury komunikacyjnej (np. sieci GPRS) do odczytania danych pomiarowych z odległego obiektu lub nawet zdalnego jego sterowania/ parametryzowania. Jeśli tak, to idźmy dalej i wyobraźmy sobie urządzenie pomiarowe jako abstrakcyjne i wirtualne – czyli usługę. Przesada?! Może i przesada, ale ja umiem sobie wyobrazić sytuację, w której do optymalizacji temperatury wody zasilającej miejski system ciepłowniczy wykorzystywane są dane z ciepłomierzy odbiorców, które to dane pomiarowe przedsiębiorstwo ciepłownicze kupuje od niezależnego usługodawcy, np. spółki miejskiej. Spółka taka może przykładowo zdalnie odczytywać urządzenia pomiarowe dla wszystkich mediów i publikować dane procesowe selektywnie właśnie w chmurze. Zastosowanie takich danych jest bardzo szerokie – poniżej kilka przykładów:

  • automatyzacja fakturowania,
  • dobór mocy zamówionej,
  • kontrola poprawności pracy sieci,
  • optymalizacja procesów przesyłu i wytwarzania,
  • samokontrola odbiorców,
  • optymalizacja temperatury zasilającej.

Jest to  krok w kierunku inteligentnego miasta. Ktoś powie: daleko posunięta futurologia. Być może, ale w badaniu potencjału możliwych zastosowań chmury nie możemy pominąć tego aspektu, tym bardziej że jest on dziś realizowalny technicznie oraz ekologicznie i finansowo uzasadniony.
Moim kolegom z zakładów produkcyjnych przytoczony przykład może wydawać się mało przydatny. Już słyszę argument, że w systemach o takiej skali rozproszenia może i to ma sens, ale u mnie maszyna na „make packu” (produkcja i pakowanie) nie może być traktowana jako abstrakcyjna i wirtualna usługa! Czyżby?! Ja bez trudu widzę oczami wyobraźni technologa siedzącego przed ekranem systemu ERP lub MES (lub jakiejś ich hybrydy), wykorzystującego zmienne opublikowane w przestrzeni adresowej OPC Unified Architecture*, który – wykorzystując dane bieżącej oceny jakości produktu – parametryzuje proces produkcyjny, wprowadzając korekty nastaw bezpośrednio do maszyny. W innym scenariuszu może on bezpośrednio decydować o wykorzystaniu poszczególnych maszyn do produkcji, by sprostać zapotrzebowaniu otrzymanemu właśnie z działu eksportu. Dla niego ta maszyna to zbiór zmiennych i właściwości w jakiejś abstrakcyjnej przestrzeni danych, którą możemy dopasować do jego indywidualnych potrzeb (lub raczej potrzeb jego ERP-a) – czyli zbudować wirtualny model informacyjny.
Jeszcze raz należy podkreślić, że koncepcja chmury jest skalowalna z punktu widzenia praw własności do infrastruktury oferowanej jako usługa. W przypadku danych z maszyny udostępnianych w ramach tego samego przedsiębiorstwa tworzona jest „chmura prywatna”. Jeśli funkcje system ERP lub dane z liczników zużycia energii będą oferowane przez zewnętrznego usługodawcę, będziemy mówili o „chmurze publicznej”. Istnieje też możliwość wykorzystywania usług jednocześnie z chmury prywatnej, jak i publicznej, co w efekcie daje architekturę mieszaną.
Innymi słowy, przetwarzanie w chmurze to sposób myślenia i szukania rozwiązań z wykorzystaniem komponentów, bez względu na prawa własności. Jeśli zakładamy wykorzystanie istotnego dla naszego rozwiązania komponentu, nie mając do niego prawa własności, musimy mieć inny ekwiwalentny sposób zagwarantowania sobie jego dostępności. Jest nim umowa utrzymania i systematycznego poprawiania poziomu jakości usług (ang. Service Level Agreement SLA) ustalonego między klientem a usługodawcą.
Omówienie zagadnienia współpracy pomiędzy usługodawcą i usługobiorcą na bazie umowy SLA wykracza poza ramy tego artykułu. Warto tu jedynie zwrócić uwagę na dodatkowe wymagania, jakie mają systemy automatyki przemysłowej, a mianowicie muszą one oddziaływać na proces w czasie rzeczywistym. Oznacza to, że w analizie poprawności ich działania w kontekście całego rozwiązania trzeba uwzględnić czynnik czasu. Skoro tak, to decydując się na wykorzystanie usługi, czynnik czasu musi być włączony w negocjacje dotyczącewarunków technicznych SLA. Może on być uwzględniony w różny sposób, przykładowo jako gwarantowana przepustowość, opóźnienie mniejsze niż itp.
W powyższych przykładach ilustrujących koncepcję przetwarzania w chmurze rozważania koncentrowały się na zastosowaniach, w których infrastruktura jest udostępniana jako usługa. Jednak koncepcja przetwarzania w chmurze może być również atrakcyjna na wyższych poziomach. W klasie zastosowań platforma jako usługa zwykle dostajemy wirtualny komputer z zainstalowanym systemem operacyjnym. Komputer taki „gości” i współdzieli z innymi maszynami wirtualnymi pewien fizyczny klaster komputerowy o dużej wydajności i łatwości skalowania takich jego zasobów, jak ilość pamięci, procesorów itp. Może to być bardzo dobre rozwiązanie dla realizacji stacji operatorskich wykorzystujących oprogramowanie klasy SCADA lub HMI. Rozwiązanie takie zresztą stosowałem już wiele lat temu, jeszcze kiedy pojęcie chmury nie było znane.
Innym rozwiązaniem już stosowanym, a kandydującym do klasy platforma jako usługa jest centralny serwer komunikacyjny i archiwizacyjny, który odpowiedzialny jest za dwukierunkową komunikację z urządzeniami procesowymi z wykorzystaniem różnych protokołów i dostępnych mediów komunikacyjnych. W takim rozwiązaniu dane procesowe są archiwizowane i publikowane tak, by mogły być wykorzystane do różnych zastosowań przez różne systemy, które mają do tych danych dostęp. W rezultacie otrzymujemy wirtualny obraz procesu technologicznego (ang. process observer) – przykładowo wirtualną maszynę na wspomnianym wcześniej make packu. By był on użyteczny, dane procesowe muszą być publikowane wraz z metadanymi opisującymi ich znaczenie (semantykę). Przykładowo napięcie elektryczne to dana – zmienna procesowa, natomiast symboliczna nazwa, lokalizacja geograficzna pomiaru, jednostka miary itp. to metadane – właściwości, bez których taki pomiar może mieć ograniczoną przydatność.
Do tematyki publikowania danych procesowych i ogólniej komunikacji z chmurą jeszcze wrócę. Teraz jednak proponuję poświęcić chwilę na analizę przypadku, który ilustruje opisany powyżej model udostępniania i wykorzystywania danych. W miejskich systemach ciepłowniczych ciepło jest wytwarzane w elektrociepłowniach lub ciepłowniach i przesyłane poprzez sieć do odbiorców, którzy je odbierają w ilości potrzebnej im w danej chwili. Niewykorzystane ciepło wraca do producenta lub po drodze jest rozpraszane do otoczenia. Nikogo nie zdziwi pewnie stwierdzenie, że optymalizacja całego procesu musi być realizowana z uwzględnieniem procesu produkcyjnego (w tym produkcji w skojarzeniu energii elektrycznej) i zjawisk towarzyszących przesyłowi ciepła (w tym strat i zapewnienia ciągłości dostaw). Aby kontrolować produkcję, potrzebne są dane z jednostek wytwórczych i możliwość sterowania nimi. Jeśli sieć jest zasilona z kilku źródeł, dodatkowo dochodzi konieczność sterowania ich obciążeniem. Do kontroli strat i kontroli jakości dostaw potrzebne są dane z punktów poboru i newralgicznych punktów sieci. Tak się jednak złożyło, że w naszym kraju większość przedsiębiorstw ciepłowniczych będących operatorami sieci ciepłowniczych i producentami ciepła to firmy niezależne z punktu widzenia prawa handlowego. To skutecznie blokuje możliwość szukania wspólnych rozwiązań, ponieważ trudno jest wykazać sensowność nakładów inwestycyjnych po stronie dystrybutora, które to nakłady będą wykorzystywane biznesowo przez wytwórcę. Jak przełamać impas? Wykorzystanie koncepcji chmury wydaje się tu rozwiązaniem idealnym. Zgodnie z opisem powyżej operator sieci inwestuje w systemy pomiarowe oraz możliwość sterowania siecią i oferuje pewnąabstrakcyjną i wirtualną sieć ciepłowniczą producentowi, który na tej platformie – dostępnej jako usługa (więc bez prawa własności) – buduje rozwiązania optymalizujące, korzystając z danych i możliwości rekonfiguracji sieci do swoich potrzeb. Dla tych, którzy pomyśleli, że autor tego artykułu zbytnio się zapędził w opisy przyszłościowe, dodam, że rozwiązanie takie funkcjonuje w systemie ciepłowniczym miasta Łodzi od 2001 r. Z tą tylko różnicą, że tam nie trzeba było odwoływać się do koncepcji chmury, bo operator sieci i producent to jedna firma i nie ma potrzeby rozwiązywania problemu „rozdzielności majątkowej”.
Ponadto w przytoczonym rozwiązaniu koncepcja przetwarzania w chmurze nie mogła być zastosowana, ponieważ nie była jeszcze znana. Tu istotne spostrzeżenie, które prowadzi do wniosku, że skoro bez znajomości samej koncepcji powstało rozwiązanie gotowe do przeniesienia do chmury wyłącznie na bazie zdroworozsądkowego podejścia do projektowania, mamy dowód wprost, że paradygmat przetwarzania w chmurze jest naturalną konsekwencją tego, co się dzieje w rzeczywistości, a nie wydumanym pojęciem.
Skoro tak dobrze poszło w warstwie infrastruktury i platformy, to może również dla udostępniania oprogramowania jako usługa w chmurze znajdziemy przykłady potwierdzające możliwość technicznej realizacji w niedalekiej przyszłości i pożyteczne z punktu widzenia poprawy zarządzania procesami technologicznymi. Na myśl przychodzi wiele pomysłów, ale co do dwóch mampewność, że mogą być zrealizowane na przestrzeni raczej miesięcy niż lat. Są to:

  • zarządzanie cyklem życia i konserwacją zasobów (maszyn, urządzeń, infrastruktury itp.) oraz prognozowanie ich awarii,
  • systemy kontroli i rozliczania emisji spalin.

W obu przypadkach oprogramowanie „zanurzone” w chmurze pobiera systematycznie nieprzetworzone dane procesowe, przetwarza je, archiwizuje, by w końcu wygenerować raport zawierający propozycje planu remontów, ostrzeżenia o możliwości wystąpienia awarii czy wyliczenie opłat za wyemitowane spaliny i wytyczne pozwalające minimalizować tę emisję.
Licencje na takie oprogramowanie są warte nawet kilka milionów złotych i bardzo wymagające z punktu widzenia platformy systemowej, na której mogą być realizowane. Dodatkowo oprogramowanie takie jest bardzo kosztowne w utrzymaniu z uwagi na kwalifikacje zespołu utrzymania. Wszystko to stwarza barierę masy krytycznej, która praktycznie eliminuje możliwość stosowania go w małych i średnich przedsiębiorstwach. Udostępnienie oprogramowania w chmurze daje możliwość skalowania do faktycznych potrzeb i dopasowania opłat za usługę do faktycznego wykorzystania, a nie do faktycznych możliwości oprogramowania. W konsekwencji staje się rozwiązaniem biznesowo akceptowalnym.
Komunikacja z chmurą
Nasuwa się wniosek, że koncepcję chmury należy rozpatrywać wyłącznie z organizacyjnego punktu widzenia, bo czymże różni się samochód własny od wynajętego. Samochód niczym, ale samochód nie należy do klasy rozwiązań, które analizujemy. Lepiej wróćmy do wcześniejszego przykładu maszyny produkcyjnej na hali maszyn będącej typowo w kompetencji automatyków, a jednocześnie sterowanej/zarządzanej przez technologów. Załóżmy, że oferuje ona łącze z protokołem klasy Modbus i interfejsem szeregowym. Czy w takim środowisku technicznym możemy zapewnić:

  • wymaganą przez technologa abstrakcję (model danych), która pozwoli mu wykonać zadanie poprawy jakości i jednocześnie zagwarantować, że nie zepsuje on kosztownej maszyny,
  • wirtualizację, więc jednoczesny wzajemnie wyłączny dostęp SCADA automatyka i ERP-a technologa.

Po wielekroć nie. Ten rodzaj protokołu wymusza tylko jednego klienta (ang. single master), więc jednoczesne korzystanie przez dwie aplikacje z tych samych danych jest wykluczone – zawłaszczanie. Takie rozwiązanie wymusza, że technolog jest raczej za ścianą, niż na innym kontynencie – brak skalowalności. Rozwiązanie nie zapewnia żadnej kontroli dostępu do rejestrów sterownika – brak kontroli zakresu świadczonych usług. Reasumując, złamaliśmy wszystkie zasady tworzące paradygmat przetwarzania w chmurze, a w końcu wykazaliśmy brak technicznych możliwości świadczenia przez automatyka usługi na rzecz technologa. Sam sobie zaprzeczyłem?! Popatrzmy na rysunek 3, gdzie pomiędzy użytkownikami a sterownikiem maszyny umieszczono dodatkowy komponent – serwer, z którego wystają charakterystyczne symbole interfejsów o kształcie „lizaka”. To podejście rozwiązuje problem braku abstrakcji, ponieważ z definicji interfejs jest abstrakcyjny – to zestaw funkcji i struktur danych, które może wykorzystać klient zgodnie ze swoimi potrzebami. Definicja interfejsu jest abstrakcyjna: mówi, co można wykorzystać, ale nie określa, jak funkcje zostały zrealizowane i jak powstają dane, ale to akurat dla ich użytkownika nie jest istotne. Jednak to jest jeszcze zbyt mało, aby otrzymać rozwiązanie gotowe na zanurzenie w chmurze. By spełnić wymóg wirtualizacji, musimy umieć zapewnić dla każdego użytkownika inny interfejs, dopasowany do jego indywidualnych potrzeb. Tylko tyle i aż tyle, żeby spełnić warunek konieczny – techniczną gotowość. Dopiero spełnienie powyższych wymogów pozwoli rozważać możliwość i sens wdrożenia odpowiedniej organizacji na zasadach usługodawca/usługobiorca.
Wiedząc już, że naszym celem jest swobodnie definiowalny interfejs wystający z chmury (rysunek 4), w następnym kroku musimy odpowiedzieć na pytanie, jak ten cel osiągnąć, a lista życzeń jest następująca:

  • swobodnie definiowalny model informacyjny: serwer musi mieć wbudowane mechanizmy tworzenia modelu danych metodami inżynierskimi, a nie programistycznymi;
  • model dostępny w przestrzeni adresowej: gdy mówimy o danych procesowych, to zawsze mamy na myśli trzy ich atrybuty: wartość, adres i jakość, z których adres ma dla omawianej koncepcji szczególne znaczenie, ponieważ zapewnia selektywny dostęp;
  • komunikacja na bazie technologii internetowych: jeśli pomiędzy klientem a serwerem będzie coś więcej niż tylko sieć lokalna, to możemy prawie na pewno przyjąć konieczność pokonania po drodze jakiejś zapory ogniowej (ang. firewall), a to oznacza, że wszystkie protokoły z wyjątkiem HTTP i SMTP będą skutecznie na niej zablokowane; SMTP się nie nadaje, więc wyboru nie ma i zostaje protokół przeglądarek internetowych wraz z bazującą na nim mocarną technologią Web-service;
  • otwartość na przyszłość: technologia internetowa do komunikacji wydaje się dziś nie mieć konkurencji, ale znamy wiele technologii, które „umarły zbyt młodo”, by choćby dostać się do muzeum; zatem w celu zapewnienia długowieczności naszych inwestycji rozwiązanie musi być łatwo przenośne na inne technologie komunikacyjne, czyli należy postępować zgodnie z kolejnym paradygmatem SOA (ang. Service Oriented Architecture – architektura zorientowana na usługę, więc komunikacja definiowana w kontekście danych i funkcji, a nie technologii komunikacyjnych);
  • klient jako wtyczka do serwera: rozwiązanie powinno być klasy plug-and-play, aby nie uzależniać się od konkretnych dostawców i zapewnić ich współdziałanie metodami inżynierskimi, a nie programistycznymi;
  • skalowalność: trzeba tu rozważyć dwie skrajności – serwer wbudowany do sterownika maszyny (mamy limit zasobów) i na drugim krańcu serwer obsługujący kilkaset tysięcy sterowników (mamy problemy z wydajnością);
  • BEZPIECZEŃSTWO: na myśl o konieczności wykorzystywania technologii internetowych każdemu automatykowi cierpnie skóra i jest to normalne zjawisko. Dlatego słowo klucz w tym punkcie napisałem wielkimi literami. Ranga problemu jest duża, choć często w naszym środowisku przewartościowana i wykorzystywana raczej jako rezultat fobii, niż faktycznego zagrożenia, niemniej należy uwzględnić konieczność skalowalności do potrzeb w tym zakresie.

To nie wszystko, ale czuję narastający niepokój Czytelnika o to, czy wdrożenie tych postulatów nie będzie wymagało uprzedniego uzyskania przez każdego z automatyków stopnia doktora habilitowanego z informatyki. I tu mam dwie bardzo dobre wiadomości.
Po pierwsze jest już opublikowany standard o nazwie OPC Unified Architecture, autoryzowany przez międzynarodowe stowarzyszenie OPC Foundation zrzeszające ponad 450 firm z branży automatyki, ale nie tylko – wymienię tu tylko dla przykładu IBM, Microsoft, SAP. Innymi słowy mamy rozwiązanie spełniające powyższe postulaty i nie trzeba niczego wymyślać – ono po prostu jest i należy je tylko zastosować.
Po drugie powyższy standard został już zaimplementowany i jest dostępny w postaci wielu produktów, w tym takich, które zostały wielokrotnie nagrodzone przez redakcję Control Engineering w konkursie „Produkt roku”.
Powyższy standard umożliwia realizację wielu scenariuszy zapewnienia komunikacji pomiędzy sterownikami będącymi źródłem danych procesowych i użytkownikami, którzy konsumują te dane po ich przetworzeniu przez systemy o różnym przeznaczeniu. Omówienie tego tematu wymaga jednak osobnego artykułu.
Podsumowując powyższe rozważania, podkreślić trzeba raz jeszcze, że przetwarzanie w chmurze jest koncepcją organizacyjną, wdrożenie której bazuje jednak na wielu rozwiązaniach technicznych. Co więcej, przetwarzanie w chmurze nie jest realną alternatywą dla rozwiązań aktualnie stosowanych, ale możliwością znacznego rozszerzenia kompetencji systemów automatyki w celu dalszego minimalizowania kosztów, zmniejszania awaryjności i poprawiania jakości produkcji oraz dystrybucji. Umożliwia skalowanie poziome, a więc rozszerzenie automatyki na obiekty o bardzo dużym stopniu rozproszenia, takie jak wielozakładowe korporacje, inteligentne sieci itp. oraz skalowanie w pionie, a więc integrację z systemami do dziś utożsamianymi wyłącznie z zarządzaniem przedsiębiorstwem.
Co ważne, wydaje się, że dziś jesteśmy gotowi od strony technicznej do wdrożenia tej koncepcji w wielu zastosowaniach. Faktyczne zastosowanie wymaga jednak jeszcze przełamania bariery psychologicznej i – jak dla każdej nowości – obawy o ryzyko fiaska, tym większej, że mówimy głównie o eksploracji nowych obszarów zastosowań. Optymistyczne jest to, że choć przetwarzanie w chmurze jest rodem z biznesu, to daje automatyce możliwość ekspansji do tegoż biznesu i tym samym zwiększenia jej roli w zarządzaniu przedsiębiorstwem.
dr inż. Mariusz Postół, Instytut Informatyki Politechnika Łódzka
CE